JavaScript as the wrong tool for the job
Though Matt Rickard, in his post 'Why Is the Frontend Stack So Complicated?', doesn't explicitly say the problems mentioned are specific to using JavaScript as an application development language, it really does seem the case. I also think he more or less answers the question posed in the title. My answers to that, based on experience and observation, can be summarised as:
- There's way too much crap in the UI layer, largely for superfluous things, and mostly for the sake of it.
- A lot of developers are using abstractions of JavaScript for everything. They even use it for server-side code, and become unstuck when they can't differentiate between what should be the controller layer and what should be the UI layer.
- This JavaScript/React thing is based on a stack of things that were invented for static sites, not for Web applications. This is one reason why it's preferable to develop software that generates all the site content on the server before it's returned to the client browser.
I've been doing Web site development for twenty years, and Web application development for around half that. Since the days when we were admonished to use JavaScript sparingly, in fact. Data layers aside, I'll typically use .NET for the backend, with a combination of jQuery, AJAX and partial views for the view layer. On the rare occasion I'd use something like Chart.js. That's all I've needed to build highly efficient applications, with clean interfaces, that do what the clients wanted.
A minimalist approach saves a lot of trouble. What do the controller and UI layers of the application actually need to do? What's the minimum amount of work needed to get the software to that state?
My limited experience with Node.JS and other things around that hasn't been great. Sure, we can build applications with it, but each package is a dependency, and that leads to multiple problems when there are hundreds of them. Other developers need to download, install and mess around with them to get the project running locally. The packages need to be upgraded regularly, with nested dependencies sometimes causing everything to break. Code sometimes needs to be debugged and modified to work with an upgraded package. We get hammered with warnings each month from vulnerability scanners...
I should address most the problems Rickard mentions.
Import systems: When a package manager is needed to manage a large number of dependencies, that's a sign that we're using too much JavaScript. If a similar application was developed using .NET, there'd be just a handful of compiled .NET assemblies and three or four .js files hosted or delivered by a CDN.
Layers of minification, uglification and transpilation: Well it is what it is. If we're at the point of needing a package manager, all that code really should be minified and otherwise compiled as an act of mercy for the users (and their browsers).
Directory structure: Same cause as for the above problem. If there's so much crap in the UI, it's going to become a project in itself, with its own directory structure. On that point, maybe its worth questioning the wisdom of having a dedicated UI developer working on the UI layer as if it's a distinct project.
Different environments: Obviously this problem also arises from an inability to distinguish between what should run on the server and what should run in the browser.