<i>We need to know the purpose we’re trying to serve, and only then can we build something that admirably serves that purpose—even if it isn’t exciting to build.</i><p>I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much; certainly it's there in other areas of programming, but it is not quite as prevalent. There seems to be a very strong "if it's not new it's bad" sentiment[1], and as a result, the amount of churn is also extremely high. What's so "exciting" about doing more with less?<p>As an aside, it is good to see that this article is completely readable without JS.<p>[1] I've received comments from "real web developers" that some of the JS I've written is "not modern enough" --- despite it working in more browsers and being over an order of magnitude less code than their proposed "proper web development" solutions. They are correct, I am not a "real web developer", but when I write JS it's usually because I have a problem to solve and don't have any other choice.
Complexity in JavaScript is not a code issue, it's a UI issue. Complicated UI's necessitate frameworks, not developers. When a website hits a certain level of UI interactions, I arbitrarily say around 10 per page, then HTML/CSS/"A sprinkle of JS" becomes unsustainable. Shipping 400kb of React isn't ideal, but to manage your complexity it is responsible.<p>Let's say your page has the following:
- Custom form validations
- Custom styled <Select> tags
- Forms that should show full lifecycle on submit without page refresh (form accepted, form error, sometimes API's return a 200 that is actually a failure :-/ )
- Inline editing of some user data.
- Badges based on your users activity.
- Notifications of new items.
- Navigation styling that is JS powered in some way, or un-achievable or kind of a schlep with CSS (maybe the links are API powered :-/ ).
- A table with sorting/filtering
- Drag and drop reordering
- Some type of chat window<p>Now let's increase complexity and say all those things respond in some way to changes in the other things.<p>I've built that page. That page is no longer a website. That page is an app and apps need structure.<p>The developer alone didn't decide the page needed all that. Chances are the business thought doing everything on one page made a strong business case. The UX team backed it up. The developer maybe agreed because they want a challenge.<p>There's no way this trend abates until complicated UI's fall out of fashion.
> Most layout issues JavaScript packages attempt to solve, like box placement, alignment, and sizing, managing text overflow, and even entire layout systems, are solvable with CSS today.<p>This paragraph has surprising links. "Managing text overflow" links to Shave, a library for truncating multiline text[0]. Last time I checked, CSS was capable of truncating single-line text, but could not truncate multiline text (the line-clamp rule is still not universally supported). The first link in that paragraph is to a flexbox polyfill, and obviously, there's a reason why people use polyfills.<p>[0] - <a href="https://www.npmjs.com/package/shave" rel="nofollow">https://www.npmjs.com/package/shave</a>
This all started with angular imho. There was a time when structure, layout and logic were more cleanly separated. Angular blew this up with <ng-xxx> tags (which was a step backwards towards PHP imho) and this has been driven forward by other frameworks since. It surprising to me how so many people can talk about shadow dom but can't name any of the HTML5 apis or even more than a few tags and what they do (much less anything about CSS3).
These are valid concerns and fortunately there are already examples of potential solutions being developed:<p><a href="https://svelte.technology" rel="nofollow">https://svelte.technology</a><p>Not saying this specific framework is going to be a success, but so far it both:<p>- Is mostly "batteries included".<p>- Indeed does create pretty small bundles.
Benchmarking on low-end devices to prove your point is situational at best in my opinion. For example if you work at a luxury ecommerce brand, you can assume that most users who actually are going to buy something are going to be using a flagship model device.
At first glance, I thought it was yet another 'do not use JavaScript at all because it is too bloated while ignoring all real world use and claiming everything can be done by css' click bait article. But this article actually considering real world use, making the point valid instead some silly useless statement. And it also does provide some useful suggests and making its points strong.
Probably the best article of this kind I saw recently
Here is a "Real World" comparison of Front End Frameworks, which includes payload size.<p><a href="https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075" rel="nofollow">https://medium.freecodecamp.org/a-realworld-comparison-of-fr...</a>
As i realized, the difference between a website and a web app is that, a web app is also a state machine. A website is stateless.<p>So, if your state machine is complicated, the web app is also complicated. As it's so hard to modify even a small portion of a mess.