The stack is not te problem, the problem is people using the incorrect tools and doing over-engineering.<p>React and others are simply a tool to pass the logic to the client. Useful in situations like apps that can run almost completely without the server or it can manage the offline situations.<p>All the related tools are only optional things to improve something:
• transpilation for older browsers
• talwindcss to manage the styles -if you are a lot of people-
• redux or others to manage the application state<p>For other kind of applications, you can continue using the same pattern where the server has the main responsibility of generating the entire view.<p>In my case, I’m quite happy using htmx and avoiding frontend frameworks because usually I don’t develop offline apps.
I see a couple of things.<p>1) Some front end needs and/or frameworks were developped by companies having a scale and pool of talent justifying the needs for new tools tailored to their use cases (extreme audience = need to address many user specificities + pool of talents means the best brains on this planet invent something: doesn't help in coming up with a trivial solution). React, Flutter, AMP.<p>2) During the zirp, coming up with some great tech was also a way to attract talents. Using such tech was (is) a way to be part of that group too. There is a trend effect. I am wondering whether complex front end tech stacks are justified when you can't hire the best talents and when you need to work faster to keep in business.<p>3) Micro service all the things leads to using API's everywhere which leads to have consumers everywhere including your front end. Coming back from this could mean using simpler apps and dropping some of the front end complexity.<p>Probably more :)
The front end is where the greatest leverage to control user behavior is. Therefore, demand to add features there is also the strongest.<p>Recall that what got investors excited about the Web in the 90's was inline images. They didn't respond to hypertext, but they were looking for a next thing after "multimedia" and saw opportunities. Next thing you know, they were writing thought-leader articles about "push content", imagining the TV-ification of the Web.
It is rather simple why: Frontend is not linear programming, most backend actions are single-flow (on A do B), in frontend at any point the user can interrupt things, which calls for state management.<p>Most backend applications are stateless and state management is outsourced to a database which does the heavy lifting. So the complexities are in scaling. Maintaining a complex frontend application is akin to maintaining a complex caching layer in front of your database.<p>The tooling hell doesn't help of course, but I wouldn't say it is the main reason.
>> Why Is the Front End Stack So Complicated?<p>Because it's always morphing. Once upon a time, it was only desktop. Then it became mobile. Then the browser added "features" and websites want that "feature". Video. Animation. Accessibility. Wasm. Then where do we hosts websites? I used to be a desktop in a closet, then it became dedicated, containerized, serverless, server-side, client-side, monolith, micro-arch. Information morphs, too. Tracking, telemetry, A/B testing, search, session state, data storage, AI.<p>Where do we go next?
It could have something to do with REST not meaning what you think it means.<p><a href="https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/" rel="nofollow noreferrer">https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...</a>
Computer-to-human interaction is vastly more complicated than computer-to-computer interaction. System complexity can be bounded by well-defined rules. UI needs to account for different screen sizes, input methods, human error, changing trends, even psychology.
Part of it is flash going away too soon before there was a viable replacement for rich us experiences and it’s taking some time to make that happen (and then some).<p>Things have been quite brittle and requiring constant updating, or more than seems reasonable. Many devs don’t know a better or simpler time.<p>There seems to be some emerging options, whether it’s the livewire type technologies, or the most recent new curves that libraries like svelte, flutter, alpinejs and more have taken, providing most of the bang with less overhead.
The real sad reality is that the web is just too archaic, it was never design with "apps" or even multimedia in mind.<p>We tried to move past this by going peddle to the metal with Javascript, and now we are slowly realizing that, while we can do this, there are major scaling issues.<p>And so now the hot new thing is things like svelte.<p>Rinse and repeat.
And honestly at this point I'm more and more leaning towards dart + flutter might be the future or maybe something else with strict unified standards and is design with apps and multimedia in mind (like what flash was partially).
I don't understand why so much of the static web is a mess of javascript anyway.
So many pages can be served as static content that I don't understand why they need javascript at all<p>Whatever happened to the interest in static site generators a few years back? It seemed like we were finally going to move away from heavy javascript just to show some text and images, and yet the javascript seems to be getting ever heavier.
One of the reasons is that users' expectations of UX rised with 1-2 orders of magnitude in the last 2 decades.<p>Whereas the platform (the web) and the languages (HTML, JS and CSS) do not offer a cohesive answer to those expectations. It's all just bits and pieces of improvement here and there.<p>Often the frameworks that aim to solve this use abstractions over these languages and APIs (e.g the DOM, routing). And these abstractions (ts, jsx, react, css-in-js, tailwind ...) are not a cohesive unit and bring back the same/more friction that's inherent to the web - 3 languages trying to play with each other) - ...<p>... But this time with even more "parts" and abstractions.<p>Web technologies weren't designed to build web apps. And since a re-design/rewrite is off the shelf, we're content with small improvements that add improvements but also increase friction.<p>We do need to rethink this.
Because using the web as an "app platform" is a hack. Manipulating HTML with JavaScript to achieve app-like functionality is a hack.<p>JS, along with other things, was bolted on as an afterthought, because HTML had too much momentum for people to stop and consider a proper way to have sandboxed, portable applications, which is what WASM seems to be, after all this time.<p>And when there's a quirky platform underneath (HTML + JS), people invent a million opinionated ways to achieve the same thing, because there's no single right way to do it. And each comes with it's own quirks.
I've been using Rust and WASM for my latest front-end project, and I think this setup is a viable alternative to commonly used JS frameworks for those willing to put in some effort to ramp up on new technology. Addressing the concerns from the article:<p>"No universal import system" - Rust has it's own module system and Cargo is used for managing dependencies, no need to worry about different module systems.<p>"Layers of minification, uglification, and transpilation." Just compile Rust to WASM file for the browser, same as using any other compile target.<p>"Wildly different environments." Something that you'll still need to deal with. Some runtime dependencies are system-specific (code running on the browser usually needs access to Web APIs, and JavaScript, code running on the server can't access WebAPIs but can access the system clock and filesystem. Sometimes separate libraries or separate runtime configs are needed (e.g. configurable time source)<p>"Overemphasis on file structure." Not a problem for imports, but you may still have file structure dependencies things like CSS, image resources etc.<p>"Configuration hell." Pretty much non-existent once you have your Rust compiler setup locally.<p>"Development parity." Just use trunk: <a href="https://trunkrs.dev/" rel="nofollow noreferrer">https://trunkrs.dev/</a>, to watch, build and serve, config is minimal.
The reliance on nodejs which lacks a standard library. It lacks a built in build process. It lacks a built in lint/format process. It lacks a built in test runner (although I believe this isn’t true anymore?). It did have a module import process, but it was so badly implemented (or maybe it lacked it in the beginning?) that despite nodeJS being the standard, most people are still using require JS.<p>I don’t know which, if any, nodejs alternative will succeed it, but if say Deno were to do so, the stack would be immeasurably simpler.<p>Right now, hopping between 2 different JS projects both of which do the exact same thing, means you may have to learn completely different build processes, completely different minting rules, completely different typescript compilers, completely different module import syntaxes/formats/configurations, completely different test runners, test description languages, etc. completely different standard libs (one may have lodash while the other is importing individual functions from npm), etc.<p>Heck, even your nodejs may not be nodejs but rather could be yarn, pnpm, etc<p>I believe nodeJS’s decision to essentially outsource all basic functionality while the JS ecosystem figured itself out was a huge reason for its success, but now that many things are more established, it’s causing a lot of unnecessary complexity.
I have a customer that uses Vue. It's much easier than React but still not easy enough. The complication as usual is the state management. There are prop local to a component and a global state. Computed values and "real" values. There are different ways to update those values some as easy as to assign to this.property and some complicated calls to functions somewhere else. Again, compared to React there is less time lost in boilerplate and puzzles, but it's still too much given that often all I want to do is equivalent to<p><pre><code> this.parent.aList.push(item)
</code></pre>
or<p><pre><code> globalState.customersList.push(item)
</code></pre>
Ideally I'd write it in JavaScript instead of using an API. I would accept<p><pre><code> globalState(customerList, "push", item)
</code></pre>
if calling a function of the library is the only way to trigger the UI update code.<p>Edit. I add an extra nuisance that could be solved by a better and more straightforward syntax<p>I have to work with code like this<p><pre><code> store.js:
import * as model from './modules/model'
component.vue:
import { mapState } from 'vuex'
computed: {
...mapState('model', ['model']),
}
this.$store.dispatch('model/method', {...})
</code></pre>
which calls "method" defined in "model" and which is very convoluted compared to what we are used to in other languages<p><pre><code> import Model from `store/model`
Model.update(args)
</code></pre>
If often think that framework and library authors don't try hard enough to build tools with simple interfaces. That reminds me about Erlang/Elixir handle_call/handle_cast.
Well most of it is for backward compatibility I guess so your newest frontend can still run in a browser as old as internet explorer by changing a few Babel settings.<p>Some of it is to optimize the code delivery so you're sending just the bare minimum source code and not wasting user's bandwidth.<p>Of course if you had just one newest browser then you could do away with most of it but at the end of the day you have to make sure your frontend can run everywhere including mobile devices, hence the complexity.<p>The amazing part is ever since vite has been on the scene a lot of it has been abstracted away. There is no need to even compile anything during dev which has been a game changer.
Because most websites are apps not hypermedia (text with links to other text).<p>Not only are they apps, they’re networked apps with the necessary remote process calls (APIs) and all the added complexity that entails.
A somewhat sobering post explaining the background behind all this complexity. It is very easy to rant against complexity on its own, but respecting the background that lead to it - that requires nuance, history and a bit more words.<p>That said, one of the major problems is that there is no clear explanation for these boundaries in the tooling and code. Yes, you can `npm install lib` and unless it is documented in readme, it won't be obvious will this run in node only or in web too.
I’d say because it evolved rather than was designed. Layer upon layers of tooling designed to work around the deficiencies of current browsers.<p>Then browsers improve but now you’ve got all that legacy stuff in there.<p>Plus of course some silly corporate is still on internet explorer 3.0 or whatever
Because there was a basic set of primitives that could give rise to almost an infinite number of possibilities. Multiple paths and iterative forces leads this to a very diverse and thriving evolutionary landscape. It has become gloriously messy.<p>It would be interesting if those studying biological evolution could see how much of their techniques, theories, and predictive abilities could apply in this realm.
This article is similar to <a href="https://deno.com/blog/node-config-hell" rel="nofollow noreferrer">https://deno.com/blog/node-config-hell</a><p>What I did, is I removed all linters, like eslint, prettier etc, because they did disagree about syntax. Point is to make to code minimal change, that fixes something, or adds some feature. Not that most commits would be about fixing syntax.<p>I also merged all branches to one main branch, because merging between branches did take a lot of time.<p>What if there would be no build step? DHH has some nice ideas about that:<p><a href="https://world.hey.com/dhh/you-can-t-get-faster-than-no-build-7a44131c" rel="nofollow noreferrer">https://world.hey.com/dhh/you-can-t-get-faster-than-no-build...</a><p>Let's make progress towards less complicated stacks.