Svelte and SvelteKit are amazing ( i say from a backend dev perspective). I’ve been saying much of what the article says since 2016, including that the majority of sites have absolutely no business being anything other than a static site. And that’s how I’ve always built mine. SvelteKit feels like building a static site without the compromises.

I use HTML5, css3 and vanilla js... haven't seen a web dev project in years that actually needed to be an application. for the odd moment where I need interactive controls htmx comes to the rescue. I've built a few actual web applications using both react and angular before and can tell you nothing is more amazing than not having to deal with npm anymore. don't get me started on downloading all backend state into browser cache just to change the color of a button ;-)

I hadn't even thought of that angle... damn. Thanks for the link.

The post How Functional Programming Shaped (and Twisted) Frontend Development from four days ago provides great broader context about the history and concerns. It ends with what this post seems to primarily concern itself with: The alternatives, improvements, innovation, and opportunities we may be missing / should evaluate.

A good companion piece to this article, is the Dead Framework Theory article, which discusses AI coding tools bolstering React's dominance.

Why couldn't they extend the server-side API to serve the content they wanted? The post opens with the words

When we architected an e-commerce platform for one of our clients

It implies they have control of the full stack, and yet they're not making use of this advantage.

I know they said its not an article of best practice, but holy shit they had to add an additional layer in there to optimize anything...

Not to be a stick in the mud, but treating a URL like a "sentence" will always be better in the long run. Unless you already have a flat structure, in which case carry on.

You can even add a caching layer later on if you find you need to scale your DB, but at that point its still going to be loads better than any "UX". Shit, you could even toss a redirect specific to your landing page, or just a rewrite at the routing layer. Sure, you lose the ease of adding them, but maybe it shouldn't be so easy.

/rant

What an absolute bunch of nonsense.

If that's were your performance problems come from, you are either a junior developer yourself or using some PHP-quality framework written by juniors.

The good news: we’re learning. The industry is rediscovering the platform.

They mention examples of such frameworks and technologies; listing them and adding hyperlinks: HTMX, Qwik, Astro, Remix, SvelteKit

I've known HTMLX, which I wanted to make use of and try out for a while now. Remix looks interesting [to me] too.

A very good (historic) overview and assessment.

Great article. The move back to more web standard-focused work has been a joy. I just used the <dialog> element, awesome. Vanilla JavaScript has improved with new APIs. WebComponents are nice, though they are more focused on creating elements on the fly.

With all this there has been an increasing appreciation of static pages - a large share of the web simply does not need backend logic at all. This makes development and deployment trivial, with superb ux performance.

React is an impressive piece of technology, and has its use cases, but as the article states "do not throw away the baby with the bath water."

The only constant is movement.

Great read! I'm mainly a React developer and I can confirm that I have never heard about the <dialog> tag before! Damn, I even use that shadCN Dialog mentioned in the article lol

Protip: (kinda half rant too) Join a general software consulting company. You will then have the opposite problem, you will be seen as ANYTHING dev. Whatever combination of os, language, framework and domain you have the least experience with, you will be picked for that project because you're available. The dice will be re-rolled every 6 months. Until then you'll be the Angular dev. Oh wait you didn't mention Angular. Tough luck. This is the protip, not the amateurtip.

Amateurtip: (kinda half joking) You don't need a job to be Vue or Svelte developer...

And when the opportunity comes to select the tech stack, or switch teams/jobs, having any hands-on experience (even if it was just the tutorial) will be a huge plus, compared to nothing. You will know better what you're talking about, and it proves that you are seriously motivated. (Of course, you can also mention your side-project to your colleagues once or twice.)

Excellent article.

the main reason is because people don't know about it

But you know about it now and you're still arguing against it.

it's an extra thing to remember for little benefit the "only" do a really useful thing that lots of people want.

The benefit you see in those tags is the same level of benefit that users who use accessibility features get from output and other semantic tags. But your argument seems to boil down to "I dont need accessibility features so i don't care about enabling them for ppl who do". That's very disappointing and continuing this debate seems pointless so i'm gonna stop here

You said output is useless

No I said it's not very useful.

There’s zero cost to using it instead of a div so the only reason not to use it is to purposefully screw users who need accessibility features.

No, the main reason is because people don't know about it, because it's an extra thing to remember for little benefit. Same reason other semantic-only tags like article get very little use.

only differ from div in styles

Err yeah the "only" do a really useful thing that lots of people want.

If output came with some nice styling and maybe animations... maybe a built in copy-to-clipboard option... then people would have used it.

Expecting all devs to test their sites with screen readers is unrealistic.

I disagree with this but its not what we're talking about. You said output is useless and I'm saying its obviously not. There's zero cost to using it instead of a div so the only reason not to use it is to purposefully screw users who need accessibility features.

All those other elements give some benefit apart from accessibility

Maybe for label but p and h1 - h6 only differ from div in styles, which is another argument in my favor. If you're willing to swap a div for one of those for visual users, swapping a div for output should be just as easy of a change.

All those other elements give some benefit apart from accessibility which is why they are universally used and output isn't.

Expecting all devs to test their sites with screen readers is unrealistic.

You can now jump to a CSS custom property’s definition from within the var() function in style rules.

Thank You!

Yes exactly. Which is reason enough to use it, unless you purposefully want worse accessibility.

You could make the same argument about p, h1 - h6, label, etc.

Developer Edition? What exactly are you getting in that that you aren't getting in the regular/stable release? I tried FF.D.E. once but I found it indistinguishable from the main release. 🤔

I will argue for standardization/normalization here though. If the change isn't significant enough or fundamentally needed to achieve something that need or REALLY want, why does it matter if it does catch on?

Like I would rather people make 100 useful things, than polish/refactor/tweak things a 100 times causing everyone to have to learn a 100 new UX changes (yes we are users of the frameworks and languages, though are just different UIs and how we use it is our UX)

You can do that with a div. Its only use is slightly improved default accessibility behaviour.

FF Dev is my favorite

Nearly every web app that uses an input calculates and displays some result based on those inputs. It's clearly useful.