I still fail to see why we should not use Javascript for everything.

> "That is the great thing about web technology. It isn’t clean or well designed by a long shot — but it is extensible and it can learn from many products built with it."

That _was_ the great thing about web technology: 'worse is better', but it is no longer an aspirational goal. As a developer I need a well-designed web to build on, and these modern frameworks are doing exactly that.

> If we do everything client-side we do not only need to deliver innovative, new interfaces. We also need to replicate the already existing functionality the web gives us. A web site that takes too long makes the browser show a message that the site is not available and the user can re-try. When the site loads, I see a spinner. Every time we replace this with a client-side call, we need to do a lot of UX work to give the user exactly the same functionality.

There is no "Loading" spinner anymore on a well-built JS-heavy application. Good frameworks (React, Ember with FastBoot) use Javascript on the server to send a fully rendered HTML to the client. That works. And they rehydrate this HTML with JSON data and client-side logic so that any further JS interaction is smooth and can be done using the conveniences of the framework.

But if were to follow the gist of what the article is trying to tell us, we should instead be rendering HTML using typical server-side technologies, and use progressive enhancement to add dynamism in the client. This is not a good solution: we have to duplicate rendering logic on both the client and server using two completely different stacks. It is a lot of cognitive load, needs duplication of effort, and is a maintenance nightmare.

A better solution is to simply render everything using Javascript, and remember that Javascript is no longer a client-side technology. Use the same Javascript to render contents both on the server and the client and rehydrate the rendered HTML transparently on the client.

I also disagree with the author's implied assertion that people who use conveniences like SASS do it more because of incompetence in wielding CSS. The kinds of abstractions CSS promotes are selectors, specificity, and cascade. They are not the kind of abstractions one needs to build a maintainable and reusable body of code. We programmers know what they are: variables, modules, objects, control structures, expressions.. SASS provides some of those missing pieces: variables, mixins, conditionals and expressions. In fact SASS pushes CSS closer to a programming language than CSS is, and that is a good thing.

The article closes on this note:

> A lot of our work on the web goes pear-shaped in maintenance. This is not a technology issue, but a training one. And this is where I am worried about the nearer future when maintainers need to know all the abstractions used in our products that promise to make maintenance much easier. It is tough enough to find people to hire to build and maintain the things we have now. The more abstraction we put in, the harder this will get.

I'm as close to an abstraction-hater as the next person. But there are good abstractions and bad ones. Mutating DOM directly using spaghetti Javascript? That is just no abstraction. Once we understand the rendered view as a function of state, then it makes sense to have abstractions based on that idea (like one-way or two-way data binding).

The need for training is not a point of contention. But assume we have competent developers working in good faith, and they still find it hard to write well-maintainable code for the web, then it has to be something else that is broken. Having used these newfangled frameworks for a while now, I do think that is very much the case. Anyone should be able to put together reasonably written web-apps without being masters at the craft, but it has so far been hard, not because of people, but because of tools.