[coolhand2120]

Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely.

I run sites that serve hundreds of millions per day and we pour a ton of resources into these projects. We're trapped in a framework (react) prison of our own creation. All failures are those of complexly. Highly coupled state machines with hacked, weaved, minified, compiled, transpiled, shmanzpiled etc. into unreadable goop in production. Yes I know source maps, but only when needed, and they are yet another layer of complexity that can break - and they do. How I long for the good old days before frameworks.

Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.

[crystal_revenge]

I'm also from the before times, and still think one of the major issues with all of this is that we've decided to build a global application ecosystem by hacking stuff on top of a document format.

HTML was supposed to just a slight markup layer to make it easier to transit and render text documents, likewise that's all HTTP was designed for. The ratio of text-to-markup should be fairly high (I'm sure today it's less than 1). But for some reason (probably the initial ease of publishing globally) we decided that the future of application development should be to entirely reinvent GUIs to be built on top of this layer. If you look under the hood at what React is doing, we just have decades of hacks and tricks well organized to create the illusion that this is a rational way to create UIs.

Imagine a world where we decided we wanted to create applications by hacking Excel documents and Visual Basic (being from the before times, I had seen attempts at this), or have every app be a PDF file making clever use of PostScript? When one remembers how ridiculous it is to attempt to do what we have collectively done, it's not too surprising that a website can require megabytes of JS to render properly and, more importantly, to allow reasonable development processes allowing for some organization of the code base.

[deergomoo]

Yup, the web is a thoroughly mediocre application platform†, but the world’s best application distribution platform.

†I know this claim will rub some people the wrong way, but if you compare the capabilities of web tooling to build rich application UIs against desktop app tooling of even 20-30 years ago, there’s no comparison. The web is still primitive, and while JS and CSS are improving at a good pace, HTML is almost frozen in carbonite.

[a99c43f2d565504]

Are you implying there exists a better way of making UIs that just hasn't taken over the world for some reason?

I also don't like the state of the web.

[lmm]

But you don't have to learn "framework after framework". Realistically, at a well-organised organisation you learn React and that's it. You don't worry about the compilation and minification and what have you, because you have a working build system that does the build and does the source maps, and you have a culture that fixes these things if they break or become flaky.

As someone who stepped away from web for a while and came back to it a couple of years ago, a straight React or Next.js application is so, so much nicer to work with than old-school webapps were. It feels like the web has finally been dragged kicking and screaming into a world of regular software development best practices. JS isn't the best programming language but it's a proper programming language and it does the job, I'm continually baffled that people would rather contort themselves with the sub-Turing tarpit of CSS and what have you instead of just using some libraries, writing some code, and actually solving their problems in what's usually an objectively easier and better way.

[_heimdall]

Why would a language meant to focus only on styling need to be Turing complete?

[mikebelanger]

>Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.

I feel the same way. React and Angular (well an earlier version of Angular) were made prior to ES2015 being mainstream, so I do think they made sense to use when they were initially created. Since then, I've become burned out from the constant churn of new frontend frameworks to learn. Even within the world of React, there's different ways of writing components, and different state managers.

[hdjrudni]

I wanted to refute the "the constant churn of new frontend frameworks to learn". If you just stuck with React since 2015, they've only had 4 major versions since then and every ver they deprecate only a few things and then you have a full release cycle to migrate to the new hot thing. It's probably the best upgrade paths of any of the libs I work with.

But you're not wrong about there being many ways to write components and manage state.

And RSC is a mess. But thankfully you can keep pretending that doesn't exist.

[klabb3]

> But if I'm being honest post query selector frameworks don't have a strong cost benefit argument

To me the killer app in the modern world is reactivity, ie making views that update in response to changes in the data model. To manually create listeners and do differential updates, and manage removal and teardown of event listeners etc, is akin to doing manual memory management. We used to do that with jquery sometimes, and it’s the most error-prone thing you can do. It’s a stateful shithole.

Once they manage to find a way to modularize components in a way that is largely view-declarative, I would be happy to crawl up on the surface of vanilla JS again, but not before. It’s simply missing functionality, imo.

[_heimdall]

Reactivity features are helpful, but in my opinion they're only helpful in a problem that largely shouldn't exist.

For a vast majority of websites out there state largely lives on the server. Reactivity is only helpful when the state reacted to is client side, and for that most sites that's only going to happen when we decide to keep a duplicate copy of state in the client rather than rendering on the back end where the state lives.

I get the desire for smooth transitions, optimistic rendering, etc. Those goals lead to endless complexity and bugs when the actual source of truth lives elsewhere.

How a site is build becomes way more simple when we stick to keeping HTML rendering where the state lives even if that means making UX tradeoffs.

[aidos]

At 100s of millions I’m assuming you have something closer to a static site than an application?

[coolhand2120]

It's a popular non-netflix/google video streaming app that you've maybe heard of. HTML5 apps/sites/whatever are just part of our supported clients. All clients are supported by a largish SOA. All of the HTML clients are indeed sites, SPAs on a CDN to be more specific, and not "apps" but this is the sickly nomenclature our industry has adopted. But I really should have called them sites if I want to motivate others to do the same, thanks for the correction.