We're at a beautiful point in web development where browsers are finally unified on open standards, and we're all too locked into these outdated JS frameworks to take advantage of it.

I perceive the main problem to be how hard it is on the implementing developer's side - only megacorps can make functional web browsers. That's a huge problem.

It's still the same as it was 10 years ago, we can't wrap our head around a solution that works for all browsers, hence, we can't just make the language concise, let alone change it fundamentally to solve the more actual problems of front end development. And then, if frameworks don't have to fix a language in their own way, we can get something real going. In any case, I just can't wrap my head around the discrepancy as to why-the-fuck-still.

(Otoh, programming has changed since our youth time. Back then we programmed for one local, now we do it for thousand remotes. Latency penalties turned upside down literally, storage is faster than SIMM, ui is slower than FDD.)

Since web 1.98a* we stopped to look at program as a whole and separated it into frontend and backend. That was a key point that allowed so much divergence and frustration. It may sound crazy, but we need new, more low-level browser (don't even call it browser, it is a network layer) that could seamlessly connect single heterogenous app on two network endpoints, since no one really cares about underlying protocols anymore. Leave www rot in browser and make internet apps great again. All good tools from '95 are still here.

* you cannot call something 2.0 until it has at most 2-3 generic and mature ways to do everything.

If we had good and stable solutions, new libraries and tools would have a very difficult time to get traction, just for the sake of being new and doing things different.

The javascript stack today is a reflection of the complexity of the problems it needs to deal with.

We can still use jquery and write code directly on script tags of html page, zero tooling problem and complication. Most front-end developers don't do that anymore because it does not solve the problems for developing complex web applications.

A clear winner may one day arise and dominate and simplify the stack, but it's also a possibility that the complexity and multiplicity of the problems the front-end deals with don't sustain one clear winner.

It’s still too low-level. We shouldn’t be writing div over and over with different interacting class properties. Something like SvelteKit’s level of frontend/backend integration feels 5 years too late.

Ultimately it seems like the web ecosystem gets trapped in local maxima (“put JS in everything!”) and really seems to avoid actually creating useful, productivity-enhancing primitives. And that comes from loving the trinity of web tech so much you cannot imagine life without them.

Instead, they think the problem is stuff like:

* developers are not using enough of the design pattern lore developed for use with static manifestly/class-y typed languages like Java

* JavaScript is terrible because you have to think about `this`, because wat, because prototypes, because the aesthetics of another language are better, etc

* mutability or missing functional purity

* the type system isn't type-y enough

* CSS is terrible

* how do you know if you're a real developer if there isn't a build step

* do you even modern bro

And you can route around these problems by switching languages. WASM to the rescue!

I suppose we'll get the chance to find out to what degree those are really The Problem With Development.™

Web development is a pain. Web developers have to deal with at least five separate technologies to get anything non-trivial to show up on the page. HTML, CSS, JS, server-side language, persistent store. Each one brings its own config languages or preprocessors, maybe some kind of build system, and, of course, mo' tech mo' problems as they say.

(An aside: I think select2, specifically, is really beautiful and an absolute pain to actually use with any other framework in real usage)

There's some truth to the argument that JS development is merrily rediscovering development methodologies pioneered decades ago:

1. "Yay! With RequireJS I can do real dependency management!" 2. "Did you see that article on how to do conditional breakpoints in Chrome dev tools?" 3. "Using type annotations in the Closure Compiler let you add some kind of type checking!"

All that said, it is getting better:

1. Always use a linter. JSLint if you wanna cry, JSHint otherwise. 2. Callback spaghetti in JS is equivalent, in my mind, to cryptic one-line pointer arithmetic in C/C++. It's a symptom not of the language itself but of the programmer's hostility to future maintenance. 3. Declarative widget-y tech is the future of web front-ends: between AngularJS directives and the evolving Shadow DOM specification (to name two), we're moving in the re-usable component direction.

We're never going to throw out JS. Ever. Every browser vendor would have to simultaneously switch to some staggeringly amazing technology all at once as well as convert all the old browsers as well. It's not going to happen.

JavaScript, if measured by installed runtimes, is the most popular, wide-spread language on the planet. Count the devices in your home that can run JS. That's its true strength, I think.

Too many people pumped into a tight space of the frontend development are creating in there another copy of the whole infrastructure while limited by the tools that weren't designed for that.

Unfortunately, because the web is serious business, all of that complexity became the standard for the entire ecosystem.

Just using HTML/CSS/JS is considered either regressive or niche. It's called "vanilla js" which only shows how utterly locked in to the enterprise paradigm javascript has become, when what should be the default needs its own genre identifier to differentiate it from "the norm."

How can such a phenomenon even exist, without programmers falling over themselves to create a development ecosystem with compilers and multiple language paradigms? The best answer I can come up with is that the history of web development is rooted in a culture that cares only about product design, user experience, and making a million dollars fast. It took a long time for systems programmers to get interested enough to provide the perspective of, well, a systems programmer.

It could be argued that not rocking the boat, and just accepting JS as the standard unconditionally, helped the web succeed. I don't agree with that. I don't see how having a good execution environment in the browser in 2004 could possibly have hurt the web.

And then you have compile-to-js languages like Typescript, and the entire paradigm of "javascript as bytecode" which, for all of their benefits in adding safety, also added exponential complexity. Frontend frameworks with their own unique paradigms that generate HTML and CSS entirely in JS, and ignore the separation of concerns the web is actually built around.

All of these have their place and their value, but the fact that "vanilla JS" is coming back as a trend might be a sign that things have strayed a bit too far in the wrong direction.

As an application delivery platform, web technologies certainly are a serious problem. They're literally decades behind the curve in many respects.

A big part of this is the classic problem that tools built for one purpose (presenting hypertext documents with some light interactivity) have been repurposed for something completely different (web apps) because they were what was available, not necessarily what was good. This goes for HTML and CSS of course, but also for JavaScript. Even with the improvements of recent years and the much better runtime environments provided by modern browsers to execute the JS code, it's still a relatively weak language for writing non-trivial applications, and the community is still following numerous practices that we've long known to be unwise and learning lessons that the rest of the application programming world figured out many years ago.

A textbook example is that in JS world, "unidirectional data flow" in modern UI libraries is treated as some sort of amazing new idea. SmallTalk was using the same fundamental principle in MVC in the 1970s. Many variations have evolved in desktop applications since then, dealing with a variety of practical lessons learned from experience with the original concept.

In JS world, it's considered a big new feature of recent years that you can now write code in multiple files, import what you need from one file in another in some standardised way, and thus break your application down into manageable parts for development but ship a single combined "executable". Again, most major programming languages created since at least the 1970s have supported modular design, in many cases with much better support for defining clear interfaces between the modules than JS offers even today.

In JS world, having discovered the concept of modular design and libraries relatively recently, naturally we're now seeing state-of-the-art build tools that use "tree shaking" to import only the code actually needed from one module in another, instead of bringing in the whole module. Dead code elimination has been a bread and butter feature of optimising compilers since... Well, you get the idea.

Next week: Stability and standards are useful things, data structures and algorithms matter, standard libraries with good implementations of data structures and algorithms are how you combine those things to make the everyday requirements easy to meet, and if much of software development is about managing complexity then routinely pulling in minor features from an ecosystem that exponentially increases the number of transitive dependencies you have to manage probably isn't a smart move.

It's not just JS, though. The layout engine in browsers was designed to support HTML documents, reasonably enough. Unfortunately, that means laggy performance in web apps that keep regenerating a large amount of page layout information because of that heritage. A great deal of effort has been spent in recent years trying to work around that fundamental weakness, with varying degrees of success.

Likewise the CSS formatting model were designed around those documents, and again is quite limited in even basic layout needs for an application UI. Some of the bleeding edge changes are making that slightly less painful, but there are still a lot of awkward interactions.

It is true that much of the modern web seems to have been taken over by spyware and ads. I'm afraid that's what we get for having a culture where a lot of people want all their content and services for free, and until we fix that culture we're probably stuck with the ads (and will probably see a variety of laws in the coming years to fight back against the technical victory of ad blockers). But this definitely isn't the only reason the web of today is bloated and slow.

Personally I think the focus for web technologies should be deprecating old things and being very judicial about adding new things. New things that get added have to be maintained by all browser engines effectively forever, and this is part of why every browser engine is a huge multi-million dollar per year endeavor just to maintain. Meanwhile, a lot of features being added to browsers don't necessarily justify all of this cost. Layout engines are unmanageably complex already. CSS is unmanageably complex already. I think adding even more stuff is hardly the solution, but rather, we need to figure out how to actually utilize what's here better before we can actually come up with successors. Rather than adding more scoped CSS and CSS modules junk, I'd rather just have improvements to CSS-in-JS. Maybe some targeted new APIs that make it easier to implement these features in the browser, not entire new paradigms that require implementing hundreds of thousands of new lines of code that will have to be maintained indefinitely. Likewise for web components: the concept is fine, but every browser has to maintain all of this forever, and all of the edge cases that come from it; will it yield so much benefit from what exists today? Will it actually stop people from shipping megabytes of Javascript, or could they have already stopped doing that if they really wanted to, and all this will do is mop it around a bit? A large node_modules folder disappears when a web app disappears. A large Chromium source code checkout only continues to grow larger effectively forever.

WebAssembly though, gets a pass from me, because it's far more than "Web", but the Web part adds a lot to the overall package. It's just a win all around.

There is more money in building products and coming up with workarounds than there is in improving the environments we all have to work with. There are also too few smart people in the world available to keep up with demand for both activities.

Instead of 10 people keeping IE up to date with modern JS language features, we had millions of people people trying to come up with and use genius solutions (Babel anyone?) to transpile and polyfill their code backwards. Instead of 4 people adding support for ES Modules to Node.js years ago, we have have many thousands of people trying to work out WTF to do on their own.

The solution is not to freeze technology in its currently deficient state and to be content, that attitude on behalf of environment maintainers is how we ended up here in the first place!

JS will be "mature" and infinitely more productive once basics like modules are implemented in all servers and clients. It will get better eventually.

That's a rather negative view, and I don't think it's entirely realistic. I am involved with multiple long-running web projects that have been using things like (real) MVC architectures and single-page applications since long before any of these trendy JS frameworks existed. The projects have been built using sound software development principles and usually a small number of carefully chosen supporting tools and libraries. They are still doing their jobs just fine, and they have stood the test of time in terms of maintainability.

The only people I meet who have an aversion to these modern JS frameworks are front-end devs who refuse to learn them or server-side devs who hate javascript.

Please consider that there is at least one more option, which I imagine applies to many of the older readers here. Some of us have seen before the rapid evolution of an ecosystem as a programming language takes off, and we simply don't buy the hype.

We saw the arrival of Java, with all its garbage collected wonder. Then we saw the nightmarish descent into over-engineered hell that followed.

We saw the arrival of Boost for C++ and the potential of community-developed, peer-reviewed libraries. Then we noticed that in 2014, C++ still doesn't even have basic features for working with filesystems or rendering a simple UI as standard.

We saw the evolution of very dynamic "scripting" languages like Python and Ruby into widely used server-side languages for real applications. Then we saw people trying to maintain those applications a few years later, when they weren't prototypes any more and when quality and performance mattered.

More recently, we've seen front-end web development shift toward JavaScript and move away from the likes of ActiveX controls, Flash plug-ins and Java applets, as language support became more consistent across browsers and some real effort went into improving performance. Today we are also seeing the inevitable explosion of the surrounding ecosystem as JS becomes a tool for building more heavyweight software, signalled by the arrival of vast numbers of different automation tools and libraries and frameworks.

But with the cynicism of the industry veteran, we also see that many of these new tools will do 80% of a job easily but make the last 20% much more painful. We know that some are merely short cuts aimed at people who now work in front-end development but whose backgrounds aren't necessarily in programming and who haven't yet developed their general software development skills in that way; there's nothing wrong with that, of course, but such tools have no (or negative) value to those who have moved beyond the level where they are helpful. Most of all, we know that five years from now, as the ecosystem evolves standards and consolidates, it is highly unlikely that most of the currently trendy tools will still be as effective and well maintained as they are today, but that like the five-year-old projects some of us work with today, someone will still have to maintain those projects after all the hypesters have moved on.

This doesn't mean that we somehow refuse to learn new technologies. It just means that if I can see what looks like a fire, and it feels as warm as I expect when I get close enough to examine it, I'm not still going to jump in for a few minutes just to see if it's really as hot as it looks because I read on a web site somewhere that all the cool kids were doing it.

Now get off my lawn. :-)

Shared frameworks and libraries do help significantly with this but the fact that they still undergo substantial churn tells me they haven't completely solved the problems they address. When's the last time you needed to drop down into Assembly to fix your JavaScript? Probably never—you can operate at that higher level, which lowers barriers to entry and increases productivity for developers. (Put your hand down, you wonderful machine code hobbyist, you.) In contrast, we still "drop down" from web app components into JS/HTML/CSS all the time.