Link tags: frameworks

Escape Velocity: Break Free from Framework Gravity — Den Odell

React is no longer just a library. It’s a full ecosystem that defines how frontend developers are allowed to think.

Real talk!

Browsers now ship View Transitions, Container Queries, and smarter scheduling primitives. The platform keeps evolving at a fair pace, but most teams won’t touch these capabilities until React officially wraps them in a hook or they show up in Next.js docs.

Innovation keeps happening right across the ecosystem, but for many it only becomes “real” once React validates the approach. Which is fine, assuming you enjoy waiting for permission to use the platform you’re already building on.

Zing!

The critique isn’t that React is bad, but that treating any single framework as infrastructure creates blind spots in how we think and build. When React becomes the lens through which we see the web, we stop noticing what the platform itself can already do, and we stop reaching for native solutions because we’re waiting for the framework-approved version to show up first.

If your team’s evolution depends on a single framework’s roadmap, you are not steering your product; you are waiting for permission to move.

The only frontend stack we should talk about

Explore the platform. Challenge yourself to discover what the modern web can do natively. Pure HTML, CSS, and a bit of vanilla JS…

A (kind of) farewell to the web – Web Directions

We’ve arrived at an industrialised process, one that’s like an assembly line for applications. Frameworks like React have become the machinery of that assembly line. They enable us to build efficiently, to build at scale, to build predictably. But they also constrain what we build.

But what aren’t we building? What new kinds of experiences, what new kinds of applications, what new kinds of interaction could we create if we were deeply exploring and engaging with the capabilities of the platform? I don’t know, because we’re not building them. We’re building what the frameworks enable us to build, what the assembly line can produce efficiently.

Collectively, as an industry and as a profession, consciously or not, we’ve chosen this maxima that we’re stuck on. We can build what React or Vue or Next or name your framework/library enables us to do.

I share John’s despair at this situation, but I don’t share his belief that large language models will save us.

I Built the Same App 10 Times: Evaluating Frameworks for Mobile Performance | Loren Stewart

A very, very deep dive into like-for-like comparison of JavaScript frameworks. The takeaway:

Nuxt demonstrates that established “big three” frameworks can achieve next-gen performance when properly configured. Vue’s architecture allows competitive mobile web performance while maintaining a mature ecosystem. React and Angular show no path to similar results.

And the real takeaway:

Mobile is the web. These measurements matter because mobile web is the primary internet for billions of people. If your app is accessible via URL, people will use it on phones with cellular connections. Optimizing for desktop and hoping mobile is good enough is backwards. The web is mobile. Build for that reality.

Is it Time to Regulate React? – David Bushell – Web Dev (UK)

React exists as a profound perversion of the web platform. React has failed upwards to widespread adoption because it provides a “developer experience” that bypasses the hard parts. Like learning HTML, or CSS, or JavaScript. Even learning React itself is discouraged; that’s for adults, you should use meta-frameworks. React devs are burdened with multi-megabyte monstrosities before they’ve written a single line of code. You cannot fix “too much JavaScript” with more JavaScript and yet React devs are trained to npm install until their problems become their users’ problems.

Default Isn’t Design

Framework monoculture is a psychology problem as much as a tech problem. When one approach becomes “how things are done,” we unconsciously defend it even when standards would give us a healthier, more interoperable ecosystem. Psychologists call this reflex System Justification.

The explains a lot about React-driven front-end development!

When a single toolset becomes the default, we don’t just prefer it, we build narratives that justify it. And that’s when a tool quietly becomes a gate or even a destructive force.

React Won by Default – And It’s Killing Frontend Innovation | Loren Stewart

React is no longer winning by technical merit. Today it is winning by default. That default is now slowing innovation across the frontend ecosystem.

Hack to the Future - Frontend - Matt Hobbs

Put the kettle on. This is a long one!

Matt takes a trip down memory lane and looks at all the frontend tools, technologies, and techniques that have come and gone over the years.

But this isn’t about nostalgia (although it does make you appreciate how far we’ve come). He’s looking at whether anything from the past is worth keeping today.

Studying past best practices and legacy systems is crucial for understanding the evolution of technology and making informed decisions today.

There’s only one technique that makes the cut:

After discussing countless legacy approaches and techniques best left in the past, you’ve finally arrived at a truly timeless and Incredibly important methodology.

It’s time for modern CSS to kill the SPA - Jono Alderson

SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.

Use modern server rendering. Use actual pages. Animate with CSS. Preload with intent. Ship less JavaScript.

How to Make Websites That Will Require Lots of Your Time and Energy - Jim Nielsen’s Blog

1. Install Stuff Indiscriminately From npm
2. Pick a Framework Before You Know You Need One
3. Always, Always Require a Compilation Step

JavaScript broke the web (and called it progress) - Jono Alderson

Semantic HTML? Optional. Server-side rendering? Rebuilt from scratch. Accessibility? Maybe, if there’s time. Performance? Who cares, when you can save costs by putting loading burdens onto the user’s device, instead of your server?

So gradually, the web became something you had to compile before you could publish. Not because users needed it. But because developers wanted it to feel modern.

Everything’s optimised for developers – and hostile to everyone else.

This isn’t accidental. It’s cultural. We’ve created an industry where complexity is celebrated. Where cleverness is rewarded. Where engineering sophistication is valued more than clarity, usability, or commercial effectiveness.

Why Silicon Valley CTOs Are Secretly Moving Away from React | by Coders Stop | in JavaScript in Plain English - Freedium

“We’ve stripped React out of our highest-traffic user flows and replaced it with vanilla JavaScript using small, focused libraries for specific needs,” said the CTO of a streaming service. “Our page load times dropped by 60% and our conversion rates improved by 14%.”

Close to the metal: web design and the browser

It seems like the misguided perception of needing to use complex tools and frameworks to build a website comes from a thinking that web browsers are inherently limited. When, in fact, browsers have evolved to a tremendous degree

Stop Using and Recommending React - Lusitos Tech Blog

I can’t recommend React to any project or customer anymore.

Using almost any other modern alternative, you will save time, money and nerves, even if you haven’t used them before.

Don’t stick to technology just because you know it.

Ten years ago today I coined the shorthand “js;dr” for “JavaScript required; Didn’t Read”. - Tantek

Practice Progressive Enhancement.

Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.

All content should be readable without scripting.

If it’s worth building on the web, it’s worth building it robustly, and building it to last.

AI is Stifling Tech Adoption | Vale.Rocks

Want to use all those great features that have been in landing in browsers over the past year or two? View transitions! Scroll-driven animations! So much more!

Well, your coding co-pilot is not going to going to be of any help.

Large language models, especially those on the scale of many of the most accessible, popular hosted options, take humongous datasets and long periods to train. By the time everything has been scraped and a dataset has been built, the set is on some level already obsolete. Then, before a model can reach the hands of consumers, time must be taken to train and evaluate it, and then even more to finally deploy it.

Once it has finally released, it usually remains stagnant in terms of having its knowledge updated. This creates an AI knowledge gap. A period between the present and AI’s training cutoff. This gap creates a time between when a new technology emerges and when AI systems can effectively support user needs regarding its adoption, meaning that models will not be able to service users requesting assistance with new technologies, thus disincentivising their use.

So we get this instead:

I’ve anecdotally noticed that many AI tools have a ‘preference’ for React and Tailwind when asked to tackle a web-based task, or even to create any app involving an interface at all.

Build for the Web, Build on the Web, Build with the Web – Web Performance and Site Speed Consultant

If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.

Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).

1. Opt into web platform features incrementally
2. Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
3. Write code that leans into the browser, not away from it

I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.

Moving on from React, a Year Later

Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to. The server doing something useful is a requirement for building an interesting business. The client doing something is often a nice-to-have.

There’s also this:

It’s really fast

One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.

Lived experience

I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.

Knowing CSS is mastery to Frontend Development — Anselm Hannemann

Anselm isn’t talking about becoming a CSS wizard, but simply having an understanding of what CSS can do. I have had similar experiences to this:

In the past years I had various situations where TypeScript developers (they called themselves) approached me and asked whether I could help them out with CSS. I expected to solve a complex problem but for me — knowing CSS very well — it was always a simple, straightforward solution or code snippet.

Let’s face it, “full stack” usually means “JavaScript”—HTML and CSS aren’t considered worthy of consideration. Their loss.