Big ol’ Ball o’ JavaScript | Brad Frost

Backend logic? JavaScript. Styles? We do that in JavaScript now. Markup? JavaScript. Anything else? JavaScript.

Historically, different languages suggested different roles. “This language does style.” “This language does structure.” But now it’s “This JavaScript does style.” “This JavaScript does structure.” “This JavaScript does database queries.”

Big ol’ Ball o’ JavaScript | Brad Frost

Tagged with

Related links

A Rant about Front-end Development – Frank M Taylor

Can we please stop adding complexity to our systems just so we can do it in JavaScript? If you can do it without JavaScript, you probably should. Tools shouldn’t add complexity.

You don’t need a framework to render static content to the end user. Stop creating complex solutions to simple problems.

Tagged with

Pivoting From React to Native DOM APIs: A Real World Example - The New Stack

One dev team made the shift from React’s “overwhelming VDOM” to modern DOM APIs. They immediately saw speed and interaction improvements.

Yay! But:

…finding developers who know vanilla JavaScript and not just the frameworks was an “unexpected difficulty.”

Boo!

Also, if you have a similar story to tell about going cold turkey on React, you should share it with Richard:

If you or your company has also transitioned away from React and into a more web-native, HTML-first approach, please tag me on Mastodon or Threads. We’d love to share further case studies of these modern, dare I say post-React, approaches.

Tagged with

HTMX Is So Cool I Rolled My Own! – David Bushell – Freelance Web Design (UK)

Call it HTMLX or call it Hijax, what matters isn’t the code so much as the idea:

Front-end JavaScript fatigue is real. I’m guilty myself of over-engineering JS UI despite preferring good old server templates. I don’t even think HTMX is that good but the philosophy behind it embarrasses the modern JavaScript developer. For that I appreciate it very much.

Tagged with

Churn

This is a good description of the appeal of HTML web components:

WC lifecycles are crazy simple: you register the component with customElements.define and it’s off to the races. Just write a class and the browser will take care of elements appearing and disappearing for you, regardless of whether they came from a full reload, a fetch request, or—god forbid—a document.write. The syntax looks great in markup, too: no more having to decorate with js-something classes or data attributes, you just wrap your shit in a custom element called something-controller and everyone can see what you’re up to. Since I’m firmly in camp “progressively enhance or go home” this fits me like a glove, and I also have great hopes for Web Components improving the poor state of pulling in epic dependencies like date pickers or text editors.

Tagged with

Web Development Is Getting Too Complex, And It May Be Our Fault — Smashing Magazine

The idea of needing a framework for everything has been massively oversold.

Premature optimisation is the root of all evil:

Trying to imitate their mega stacks is pointless. Some might argue that it’s a sacrifice we have to make for future scalability and maintenance, but we should focus first on building great sites for the user without worrying about features users might need in the future. If what we are building is worth pursuing, it will reach the point where we need those giant architectures in good time. Cross that bridge when we get there.

Tagged with

Related posts

Switching costs

The enshittification of React …which was already pretty shitty for users.

HTML web components

Don’t replace. Augment.

Multi-page web apps

A question via email…

Suspicion

Responses to my thoughts on why developers would trust third-party code more than a native browser feature.

Trust

I’m trying to understand why developers would trust third-party code more than a native browser feature.