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!
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.
Websites are like a canvas. You have complete freedom to design them the way you want. But unlike a painting, not all people will view your site the way you want. This article discusses how Responsive Web Design (RWD) evolved.
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:
- React frameworks finally mature
- We get a glimpse at container queries
- WASM explodes
- The monolith makes a come back
There’s the predictions. Click through for the Jay’s reasoning.
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…
What the what is DivOps?! That’s the question Jonathan Creamer is here to answer. In so doing, we cover the past, present, and future of frontend tooling.
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.
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.
Hyperapp claims to be twice as fast as React, weighs in at 1.8KB, and renders interactively in ~10ms.
Hyperapp is a modern VDOM engine, state management solution, and application design pattern all-in-one. once you learn to use it, there’ll be no end to what you can do.
Filed under: zero-minutes-since-last-frontend-framework
So you are building a client-side web app for that next big project and wondering: “Which router should I use?”. Here is the thing: you don’t need any, and you will understand why shortly.
Why is static the future? How do you define “static”? Read this deep dive from Josh Comeau to find out…
The term “static” can be a little overloaded, and occasionally a little misleading. Here’s how I’d define it:
“A static website is a website where the initial HTML is prepared ahead of time, not dynamically generated by a server on request.”
When you make a request to this website, for example, Netlify serves pre-generated HTML to you. I don’t have a Node server dynamically rendering HTML documents on-the-fly.
Mint has all the tools you need to write error free, easily readable and maintainable applications in record time.
To button or not to button…the button element is “actually really cool”…
Harry Roberts writing on CSS Wizardry:
One metric I feel that front-end developers overlook all too quickly is Time to First Byte (TTFB). This is understandable—forgivable, almost—when you consider that TTFB begins to move into back-end territory, but if I was to sum up the problem as succinctly as possible, I’d say: While a good TTFB doesn’t necessarily mean you will have a fast website, a bad TTFB almost certainly guarantees a slow one.
Even though, as a front-end developer, you might not be in the position to make improvements to TTFB yourself, it’s important to know that any problems with a high TTFB will leave you on the back foot, and any efforts you make to optimises images, clear the critical path, and asynchronously load your webfonts will all be made in the spirit of playing catchup.
Typescene is a robust front end library written in TypeScript: strongly typed, no dependencies, no nonsense. It’s really great for desktop-like (or mobile) applications, not so great for blogs and other content. It isn’t backed by some major corporation, not even a startup, but it’s been built by me: one developer on a mission to build a no-nonsense dependency-less framework
The author’s journey is noteworthy, but if you’re mostly wanting to know if this particular framework speaks to you, jump directly to its list of goals.
My big concern is at the bottom of that technology pyramid. The lowest common denominator of the Web. The foundation. The rhythm section. The ladyfingers in the Web trifle. It’s the HTML. And it is becoming increasingly clear to me that there’s a whole swathe of Frontend Engineers who don’t know or understand the frontend-est of frontend technologies.
Solid rant with a nice list of resources at the end. 👌
Rich kicked the proverbial hornet’s nest yesterday. After you read his 10-point post, stick around for the comments, many of which rebut one or more of those points. I’ll weigh in on #3: Platform Fatigue
Every time we add a new feature to the platform, we increase that complexity — creating new surface area for bugs, and making it less and less likely that a new competitor to Chromium could ever emerge.
What’s the front-end equivalent of a micro-services architecture? A micro-frontends architecture of course. This approach makes a ton of sense, though in my opinion you will definitely want to have an internal components library and some cross-frontend coordination so your UI doesn’t degrade into a series of disconnected, disjointed experiences.
It’s hard to argue against the benefits stated by author Cam Jackson:
Micro frontends are all about slicing up big and scary things into smaller, more manageable pieces, and then being explicit about the dependencies between them. Our technology choices, our codebases, our teams, and our release processes should all be able to operate and evolve independently of each other, without excessive coordination.
Front-end developers are often in a position of trying to interpolate between a (static) design and the (dynamic) needs of a product. When something comes up that isn’t quite covered by the design, what should you do? In an ideal world we could have a conversation with the designer, but the world is rarely ideal, so it’s useful to have at least a sense of good practices to apply.
This article is great because it keeps it simple - just four straightforward principles. As author Anna 4erepawko Mészáros says:
Will this help you create shiny beautiful designs? No. Will this help you create great, clear and comprehensible designs that everyone can easily understand and interact with? Absolutely.
Why use Uniform?
React Hooks 😍
Use of uncontrolled components
Integration with pickers, dropdowns and other libraries
It is 2019 and we need to make a decision about GIFs. GIFs take up a massive amount of space (often multiple megabytes!) and if you’re a web developer, then that’s completely against your ethos!
If your goal is to improve your website your loading performance, then a GIF needs to be yanked! But then how do you have moving pictures? The answer is a video. And in most cases, you’ll get better quality as well as almost 50-90% size savings!
AV1 videos give us smaller file sizes and better quality?! There must be a catch…maybe…read on to find out.
This means Flutter is now on mobile, web, desktop, and embedded systems. What surprises me is how dedicated to Dart Google seems to be, despite community malaise and the success of TypeScript.