Javascript should not be used for everything

Interesting:

One of the great things about JavaScript is that you can do everything with it: you can do computations, you can create HTML, you can dynamically style elements, you can manipulate images, play and create music, video, and nowadays do all the HTTP work of an app, too. JavaScript is not only the leatherman of the client-side web any longer, it now took over the server, too.

That is also one of the terrible things about JavaScript. Just because you can cover all the parts of an app with it, doesn’t mean you should. Not everybody who groks it, knows how to create a beautiful app experience, and those who know how to do that, don’t necessarily grok JavaScript. Living proof for that is the vast amount of “JavaScript developers” who are totally lost without jQuery. And you have “CSS developers” who need Bootstrap to start with and sooner or later will manipulate element.style in their JavaScript when it isn’t needed as it is neither dynamic, nor problematic across browsers. The same goes for the server. Just because you use JavaScript doesn’t mean you’re free of security concerns or your server will perform magically.

…Why not analyse what went wrong? Why not question if the move to fully client-side rendering really is a great step, or if it just appears to be one as it makes it easier for a certain company to release a certain product at a certain time. Twitter back-tracked once before, this can happen to anyone else, too.

Fact is that a lot of stuff on the web is the result of a lot of weird, non-technical decisions we’ll never hear about.
People used shortcuts to make a certain deadline. Ninja Rockstar developers applied a great state-of-the art new paradigm without documenting their work before getting hired by the competition. Maintainers added more things without understanding the structure of what was going on as they never had a proper handover. Who cares? Move fast and break things! But, hey, let’s never, ever, blame the great innovations we made to fix the lame platform we try to build on and benefit from its user numbers. Always blame the web and its slow innovation cycle.

…When Etsy announces their switch to SCSS to make their styles more maintainable the finding should not be “SASS beats CSS”, but it would be interesting to learn what lead to over 400,000 lines of CSS in over 2000 files for an actually not that complex site in the first place. The article is very interesting and shows some great differences in people dealing with code:

CSS enthusiasts love the fact that CSS doesn’t stop executing when it encounters errors — it just skips them, which allows, for example, for browser prefixes. For Etsy, this was an issue, as it was impossible to pin-point where things went wrong in the CSS. Instead of digging, people just wrote more CSS with a higher number or selectors to overwrite existing styles. I love that the article also mentions the dangers of SCSS, and especially @extends allowing for the final CSS to bloat again. It doesn’t mention the gains that came from switching to SCSS, all it explains is that now they are thinking properly about how to write the styles for the product to avoid bloat.