Ask Me Anything: Front-End Edition

Cole Turner
Cole Turner
13 min read
Cole Turner
Ask Me Anything: Front-End Edition
Blog
 
LIKE
 
LOVE
 
WOW
 
LOL

What questions would you like to ask a Software Engineer about Frontend Web Development? I will try to answer your questions submitted through the form below.

Asked by Glenda.

This is a great question because in recent years the number of languages and frameworks has cascaded across software engineering, including front-end web development. Browsers have become more than a portal to the internet, they've become platforms that power many cross-platform applications.

The first step is exploring what you want to do with programming. Building native applications will limit you to a few languages that work with those operating systems. Domains like Machine Learning, AI, and Data Science - they all have their own common languages. On the other hand, the basics of web development are HTML, CSS, and JavaScript.

I would start there. The fundamental concepts and building blocks in these languages will give you a compass for evaluating different frameworks. As developers, we provide inputs to a framework, which does its magic and renders outputs to HTML, CSS, and JavaScript. It's not impossible to skip over the fundamentals and dive directly into a framework, however, it's easy to get lost if one does not understand how the inputs are translated into outputs.

Once you have a strong baseline in web development, picking a framework is a lot like throwing darts at a map. You can't really go wrong. A lot of people say jQuery is a waste of time to learn in 2020, however, it's still used very commonly in websites today. It wouldn't be my first choice and I would not spend a lot of time becoming an expert in jQuery. On the other hand, frameworks like React, Angular, and Vue are also ubiquitous. There are plenty of other choices too, so the question is - how do you choose?

If it's your first framework, just pick one! Choose one that makes sense to you and how you think about your web application. In time, you will become an expert in that framework and you'll have a sense of whether you want to stick with it. You may find yourself wanting to explore other frameworks, and I highly recommend trying a few out before committing to one long term.

Over time, your choice in the framework will likely be influenced by other reasons. A good reason to use a framework is that it's what's required for a job. Another good reason is that the framework is ubiquitous and has a large community built around it. Community support is really important to me, because when I encounter a problem it's likely to have been solved before. Having to code everything yourself can be a burden on your productivity.

I've been using React since 2014, and in 2020 it's still my choice for frameworks when building interactive user interfaces. It has a large community behind it, plenty of already-solved problems, and has excellent integrations in the web development ecosystem. If you're looking for a recommendation, that is my preference. That being said, it's worth repeating that whatever choice you make will be a fine and valid option.


Asked by Perpetual Education.

Where JAMStack tooling really excels is that it abstracts away most of the tooling and build process and provides sensible defaults. For those who don't know, JAMStack is JavaScript, API, and Markup. Pages are generated at build-time, statically compiled and distributed from a CDN. It's a really great option when you want a separate front-end and back-end.

But it's not for every use case. When a page takes longer to build than it takes to serve, or if there are too frequent updates - for example with real-time interfaces like chat or comment sections - then having a static front-end makes it difficult to integrate with. In those cases, you may need a dynamic front-end with a CMS.

For example, my personal website (cole.codes) - I migrated to JAMStack. It was a great choice because it's not a real-time interface. When I publish posts, I am okay waiting a minute for them to go live. It's still faster than how my previous site deployed, and there are other advantages in the build, preview, and ship pipelines.


Asked by Hemant

Hemant asked whether beginners should practice first or learn about them and start using them in the field. I am going to make an assumption that this question is oriented around career development.

To start, you don't need to know everything to get a job, even it appears that way. You should be applying for jobs regardless if you fit 100% of the criteria. Many integrations are learned on the job, what helps is understanding the bigger picture.

Before you start using a library - try to understand the bigger picture through the end-to-end flow. Create a document or a flow chart to map out what happens when a user types www.mydomain.com into the browser. Where does their request go? How does their browser get a response? Once you have a bigger picture, it becomes clearer when and where to use other frameworks like JTW, OAuth, or Payment Gateways.

When you're trying to learn a new pattern or framework, I recommend starting with something that has a lot of community support behind it. Choosing one where there are a lot of contributors and users means that when you're stuck - you'll have more access to help.

Follow along with the getting started guides, build something small. But do it on a project that you care about. You're likely not going to enjoy setting up authentication on a Todo app unless it sparks your motivation. And when you've finished doing that, do it again. It's like watching a season of television - I always learn something new on the second time around.


Asked by Thabiso Ngwenya

Anytime there is a breakthrough in Machine Learning technology, or a new library comes out - our industry sees a small spike in blood pressure because we think ML models will replace developers. If all a developer had to do was write some basic HTML and CSS, maybe a button or form - that could be true.

But that's also true today with no-code solutions like Webflow or Squarespace. These haven't taken away from web developer jobs, they've only made web publishing more accessible to those who were already writing basic HTML and CSS.

I want to say you'll always have a web dev job if you can do just a little more than that, but I can't predict the future. However, I can say that even these companies still need software engineers to build their products, and build websites for those products.


Asked by Anonymous

I worked with Angular.JS (v1) for a few years when it was the new kid on the block, and I loved it. Since then I haven't kept up to speed so I can't answer specifics about Angular and how it's evolved.

At the end of the day it's a framework. Every framework has its tradeoffs and usefulness. For corporate development, I absolutely recommend a framework - whether that's Angular, or React, or something like Next.JS. Frameworks bridge the gap between developers working in teams, and frees up that time spent investigating what normally belongs to a framework. I've tried to roll my own framework before - I don't recommend inventing your own framework.

I can't say whether you should use it or not - I can only tell you that I chose React in 2015 and I've been satisfied with that choice. Both frameworks have great community support, and that's what's important to me. When there is a great community behind a framework, that means I spend less time inventing solutions that other developers have already solved.


Asked by Richard

Such a great question for freelancers and contractors. Hosting on behalf of the client can be a great source of additional, passive income. In the past when I did contract work, I would include a retainer clause which would mean that I would provide bug fixes, maintenance changes, and hosting for a monthly cost. That can be packaged at per-hour maximum rate: for example $150 for two hours a month. You set the rate depending on how much you believe the client will use those two hours. In this case, you're charging not only for your time but also your availability.

I will offer this clause on different terms to each client - depending on whether they can host it themselves or if I want to continue working with them. If the freelancer can offer the retainer without the hosting, that's generally an advantage for the freelancer because that means there is a two-tiered support system, where the hosting is supported by the provider instead.

I generally recommend always having a web server (or use a free serverless host such as Vercel or Netlify) for demos and staging. You should never hand over the files until you have payment in hand.

If you want to learn more about freelancing, interactions with clients, and more - I've written a guide on the lessons I've learned as a freelance web developer.


Asked by Anonymous

Totally! When we look at the various CSS problems, in addition to the ones in the question, we find some common themes. As a language, CSS is so robust and has grown over the years, and there's no single way to do CSS. Most often the standards you will be following are adhering to some kind of framework, but I will get to that in a minute.

As far as how to write elementary CSS, the truth is that there is no single set of standards for how to author CSS. Google publishes a style guide if you are looking for inspiration - and if you're in the learning stages I recommend using MDN's guides to CSS. Most of what you will find while learning through these resources will be heavily curated in order to guide you using common style guide principles.

If you're ever stuck wondering which properties use, look for examples on GitHub, or StackOverflow. When you are searching - it's usually better to look at examples posted in the last three years, or five years; they will be most up to date with CSS standards.

There are also methodologies about how to structure your CSS, such as BEM or Atomic CSS. These methodologies come with their own set of principles, you can learn what some of those are here.

Earlier I mentioned that most of the time, the standards you will follow will adhere to a CSS framework. Most of the time, when you're working on a web app, Software engineers will use a CSS framework to do most of the heavy lifting. Over the years I've worked with frameworks like Bootstrap, Pure.CSS, and most recently Tailwind CSS. You can learn more about CSS frameworks here, to help you decide when you need one.


Asked by (Beau)

I love this question because I have faced this issue many times in my web dev days. Variable backgrounds are so difficult to work with because they can wash out the white text.

Here is the example that OP shared with me:

Example of variable backgrounds with text.

My favorite technique is to extract a foreground color from the image (for example the yellow from the duck). From there I will calculate the color contrast for the text and use either white text for dark backgrounds or black text for light backgrounds. This is what I'm doing on my website, except I am pre-specifying the base colors:

Example of color contrast using a dominant color

If you prefer something more subtle, without a lot of pop, then the Sheep and Moose examples here are a great start. I like using a transparent black background, for example "rgba(0, 0, 0, 0.85)." This ensures that the color contrast is significant enough to at least meet Level AA accessibility requirements. This does tend to feel more conventional, and so we can play around with it a little and go for something a bit bolder:

Example Text on Variable Background - Bold Labels

This can work really well with a sophisticated, modern design! If you want to apply a similar technique, check out this guide for How to Create Accessible Complementary Colors.


Asked by (Beau)

Everyone assumes that when a JavaScript developer must know all of the APIs. I've been working with JavaScript for about 15 years and I still Google things _all the time_, and lean on MDN heavily when I need to use browser APIs. The important aspect is knowing what APIs to seek out, and recognizing how they fit the needs.

What haunts me about JavaScript? Besides the typical quirks (precision, type coercion), I've leaned so heavily on frameworks over the years - moving from jQuery to React. Whenever I have to write vanilla JavaScript, I realize that it's a muscle in itself. For example, I am so used to writing "className=" that I have to catch myself when I'm writing vanilla HTML.

There's also a beautiful nightmare to JavaScript being a universal language that runs on client and server - each piece of code requires a deep understanding of how it's running when it involves mixed server-only or client-only APIs. It's too easy to use an API that's only available in one context but not the other. I really love how Next.JS has intertwined the two, I wrote this website with it and haven't run into that blunder yet.


Asked by Anonymous

This is a great question! Symbols feel a lot like regular objects, and why wouldn't we just use strings since they work as expected? A JavaScript symbol is a special object that has a unique reference, no two symbols are the same (except when using Symbol.for to search for existing symbols). Symbols really help in libraries and module API. We can use them to expose identifiers that don't collide with other values in the application code. Symbols are also used sometimes for prototype (Symbol.iterator for example) and metaprogramming.

Learn more about JavaScript Symbols from Cole Turner.

Photo by Jon Tyson.

 
LIKE
 
LOVE
 
WOW
 
LOL

More Stories

Melt of the Day: Brisket, Muenster, & Grilled Onions

2 min read

You can't go wrong with brisket. This recipe uses Snow's BBQ, Texas Monthly's #1 Pick, and grilled onions for the perfect brisket and grilled cheese melt.

Lessons Learned in Freelancing

12 min read

If you want to become a freelance web developer, these are the lessons that will help you have a great time working with clients and being effective.

See more posts

Read it before anyone else. Subscribe to my newsletter for early access to the latest news in software engineering, web development, and more.