Frontend Icon

Frontend

Front End is the programming and layout that people see and interact with.
68 Stories
All Topics

Josh Comeau joshwcomeau.com

The end of front-end development

Josh Comeau:

Over the past few months, I’ve spoken with lots of early-career devs who are getting more and more anxious about AI. They’ve seen the increasingly-impressive demos from tools like GPT-4, and they worry that by the time they’re fluent in HTML/CSS/JS, there won’t be any jobs left for them.

I couldn’t disagree more. I don’t think web developer jobs are going anywhere. And I’m getting pretty sick of the FUD? being spread online.

So, in this blog post, I’m going to share my hypothesis for what will happen. Things are going to change, but not in the scary way people are saying.

JavaScript deno.com

The future (and the past) of the web is server-side rendering

What’s old is new cool again. Here’s Andy Jiang, writing on Deno’s blog:

In the past 10 years, the median size for a desktop webpage has gone from 468 KB to 2284 KB, a 388.3% increase. For mobile, this jump is even more staggering — 145 KB to 2010 KB — a whopping 1288.1% increase.

That’s a lot of weight to ship over a network, especially for mobile. As a result, users experience terrible UX, slow loading times, and a lack of interactivity until everything is rendered. But all that code is necessary to make our sites work the way we want.

This is the problem with being a frontend dev today. What started out fun for frontend developers, building shit-hot sites with all the bells and whistles, has kinda turned into not fun. We’re now fighting different browsers to support, slow networks to ship code over, and intermittent, mobile connections. Supporting all these permutations is a giant headache.

How do we square this circle? By heading back to the server (Swiss basement not required).

He goes on to talk about isomorphic JavaScript frameworks and Deno’s offerings in this space. But hey, you don’t need all that fancy stuff to do SSR. All you need is a programming language that can render HTML (this is almost all languages) and a server…

Josh Comeau joshwcomeau.com

The frontend developer's guide to the terminal

This guide by Josh Comeau is Josh doing what Josh does so well: taking complex/arcane/technical topics and making them approachable & fun for his audience.

It takes years of practice to become a terminal guru, but here’s the good news: we can take a shortcut. We don’t really need to know 98% of the stuff you can do with a terminal. If we focus on the most-important critical fundamentals, we should be able to become comfortable with the command line in a remarkably short amount of time. ✨

That’s what this blog post is all about.

Practices gomakethings.com

SPAs were a mistake

Chris Ferdinandi:

For years, a trend in our industry has been to build single-page apps, or SPAs.

With an SPA, the entire site or app lives in a single HTML file. After the initial load, everything about the app is handled with JavaScript. This is, in theory, supposed to result in web apps that feel as fast and snappy as native apps.

Today, I want to explore why that’s nonsense. Let’s dig in!

I built one of the first big SPAs (remember Grooveshark?), but I’ve shied away from them ever since. I do think there are cases when they make sense (Trello and GMail come to mind), but overall I think too many people chose the architecture too many times because it was the it thing to do vs it was actually the best decision for their circumstance.

Heck, even Chris’s disclaimer of ‘when SPAs make sense’ section at the top is easily defeated by our Turbolinks implementation. But I digress… read this post it’s a good one for sure.

forsigner github.com

Fomir – a schema-first library for building forms

Why create another form library? Here’s what Fomir’s author says to that:

I have tried many form libraries, like redux-form, formik, final-form, react-hook-form… None of them suit my taste. I would expect a forms library with these features:

  • Using schema
  • Easy to update form state
  • High Performance
  • More abstract

Fomir create form by passing a form schema which is a JSON tree. the form schema is very flexible, you can create any form by the schema.

I could see this as especially useful for form builders and similar tools where you’re providing a graphical way to build forms because your backend would just have to emit the correct JSON and let Fomir take it from there.

Finnian Anderson finnian.io

Hotwire in the real world

There’s lots of info out there about building a simple app with Turbo, but there’s very limited content about architecting apps, scaling or building anything that’s not simply a blog.

In this post, I go into details about building a real production app with Hotwire and what we learnt as a team, plus some of the things we don’t like and the problems we bumped into.

Changelog Interviews Changelog Interviews #467

Connecting the dots in public

Today we’re joined by Shawn “swyx” Wang, also known as just “swyx” — and we’re talking about his interesting path to becoming a software developer, what it means to “learn in public” and how he’s been able to leverage that process to not only level up his skills and knowlege, but to also rapidly advance his career. We cover Swyx’s recent writing on the light and dark side of the API economy — something he calls “living above or below the API,” his thoughts on Cloudflare eating the cloud by playing Go instead of Chess, and we also talk about the work he’s doing at Temporal and how’s taking his frontend skills to the backend.

Rust github.com

Seed – build your frontend in Rust

Seed is a Rust framework that uses an Elm-like architecture to help you build fast and reliable web apps that run on WebAssembly. Here’s why you might want to use it:

Seed allows you to develop the front-end with all the benefits of Rust, meaning speed, safety, and too many more things to count.

The Seed templating system uses a macro syntax that makes Rustaceans feel right at home. This means linting, formatting, and commenting will work, and it’s all in Rust. This is opposed to a JSX-like syntax that relies on IDE extensions to improve the developer experience.

Seed has a batteries-included approach. This means less time writing boilerplate and less time installing dependencies.

And a few reasons why you might not:

  • It’s newer. It’s harder to find support outside of Discord.
  • WebAssembly is newer with less support. Browser compatibility is at 92.9%.
  • Pre-built components are rare. You will likely have to roll your own components such as date pickers.
  • No server-side rendering yet
  • You may prefer other Rust frameworks like MoonZoon or Yew.

Rach Smith rachsmith.com

I completely ignored the front end development scene for 6 months. It was fine

Wise words from Rach Smith:

What I’ve learnt through experience is that the number of languages I’ve learned or the specific frameworks I’ve gained experience with matters very little. What actually matters is my ability to up-skill quickly and effectively. My success so far has nothing to do with the fact I know React instead of Vue, or have experience with AWS and not Azure. What has contributed to my success is the willingness to learn new tools as the need arises.

Shruti Kapoor Medium (via Scribe)

The story of PayPal's adoption of GraphQL

From Shruti Kapoor on PayPal’s technology blog:

We started our GraphQL adoption journey by building our checkout experience. We saw tremendous benefits in adopting GraphQL when our checkout app built with GraphQL became our guiding light.We built more apps, provided infrastructure support, launched a public GraphQL API, and provided trainings and learning materials across the company. We also set up a standards body, provided a GraphQL tools fanny pack, and built sample apps to help teams get started.

Today, GraphQL is being used by several production apps across PayPal. It is now a default pattern to use GraphQL for building new UI apps. Many existing apps are in the process of migrating to GraphQL.

JavaScript github.com

Solid – a declarative JavaScript library for creating user interfaces

Solid… does not use a Virtual DOM. Instead it opts to compile its templates down to real DOM nodes and wrap updates in fine grained reactions. This way when your state updates only the code that depends on it runs.

Solid takes a lot of cues from React, but sets itself apart in that it doesn’t use a Virtual DOM. Here’s what Michel Weststrate had to say about it on Twitter:

Not a revolution, but really solid (pun) evolution; clean component model, really efficient run-time model, deeply embedded reactivity. Definitely think it’s worth giving it a shot in fresh new, limited scope projects!

Josh Comeau joshwcomeau.com

An interactive guide to CSS transitions

If you want to learn about CSS transitions, this explainer from Josh Comeau is a great start.

This tutorial is meant to be accessible to developers of all experience levels. It can be thought of as “CSS transitions 101”. That said, I’ve sprinkled in some interesting and obscure tidbits — no matter your experience level, I bet you’ll learn something!

An interactive guide to CSS transitions

Chris Coyier CSS-Tricks

Servers: cool once again

Chris Coyier rounding up recent frontend moves (by Basecamp and React, specifically) back to server-side rendering techniques of old:

So: servers. They are just good at doing certain things (says the guy typing into his WordPress blog). There does seem to be some momentum toward doing less on the client, which I think most of us would agree has been taking on a bit much lately, which asset sizes doing nothing but growing and growing.

Let’s push those servers to the edge while we’re at it.

I agree. Servers are cool. Clients are cool, too. But so are servers.

Browser London Icon Browser London

Frontend predictions for 2021

Predictions are always fun, especially when we can look back and see how wrong we were. Here’s Browser London’s Jay Freestone laying out where he thinks the frontend is going in 2021:

  1. React frameworks finally mature
  2. We get a glimpse at container queries
  3. WASM explodes
  4. The monolith makes a come back

There’s the predictions. Click through for the Jay’s reasoning.

JavaScript eng.lyft.com

How Lyft is migrating 100+ frontend microservices to Next.js

The engineering teams at Lyft were facing some serious issues:

we were running into headwinds trying to maintain our own frontend platform — an internal set of Webpack configurations, ESLint libraries and framework code — and finding ourselves bogged down troubleshooting cryptic build errors and generally finding our productivity sapped by such support requests. Because codebases began to diverge (as they do in microservice architectures), our developers found the task of upgrading to new versions of our frontend platform to be time-intensive and frustrating.

With over 100 frontend services and nearly as many frontend engineers, it was clear something needed to be done in order to ensure that our platform was maintainable for Lyft’s growth.

With a team that large and the freedom to spin up a new microservice whenever the need arises, it must be terribly difficult to fend off divergence in coding architecture, style, tooling, and dependencies. Unless you unify everyone one a common foundation. A framework, if you will…

Tom MacWright macwright.com

If not SPAs, what?

Tom MacWright shared some concerns for SPAs place in the modern web and followed it up with a post sharing suggestions to use instead.

The SPA pattern (Single-Page Apps), I tried to define, was about the React model, which also covers, to a large extent, the model of Vue, Angular, and other frontend frameworks.

Like any critique, it begs for a prescription and I didn’t give one, other than gesturing toward server-side frameworks like Rails and Django. But I think there are some trends starting to form. I had queued up some time to really dive into the frameworks, but things like walking in parks have taken priority, so here’s just a grand tour.

Chris Coyier CSS-Tricks

The widening responsibility for front-end developers

Chris Coyier:

This is an extended version of my essay “When front-end means full-stack” which was published in the wonderful Increment magazine put out by Stripe. It’s also something of an evolution of a couple other of my essays, “The Great Divide” and “Ooops, I guess we’re full-stack developers now.

This is a lengthy, sprawling piece on the evolution of frontend development by someone who really gets the web. It also has its own art-direction and design so you’ll want to read it onsite vs in an Instapaper-alike.

Player art
  0:00 / 0:00