Ask HN: Why did Frontend development explode in complexity?

Early react team member here. The popular react&#x2F;webpack&#x2F;npm stack is probably what the OP is talking about. It was popularized because the Instagram web team used webpack and npm in 2013 so we recommended it alongside react in the early days. I was TLM of the team when we made these decisions.<p>There are three main points I want to add to the conversation.<p>1. UIs actually have a lot of complexity. The number of states they can be in is often higher than what you see in other disciplines of software engineering. They also have to contend with managing data fetching over unreliable networks, including balancing bundle size. Additionally they are notoriously hard to test because “does this feel right to a user” is hard to encode programmatically.<p>2. The grass isn’t greener on the other side. I see a lot of people complaining about the needless complexity of the frontend stack but I don’t think they’ve worked in a modern backend engineering or data engineering project. Modern backend eng is a morass of kubernetes configuration, needless microservices and overuse of async queues, for example. Feels a lot like frontend in terms of accidental complexity. So I’d argue that this is less of a frontend problem and more of an industry wide thing (cynically, it might be a ZIRP thing)<p>3. With that said there certainly is needless accidental complexity in frontend and I am convinced content marketing is 100% to blame. An easy way to hire engineers is to create an open source project and write a blog post convincing people to use it. This is good for the company and good for the careers of the engineers who worked on it, but can cause people to needlessly complicate their tech stack if they can’t cut through the noise.

It&#x27;s artificially inflated and I&#x27;m seeing this in almost all areas, not just frontend.<p>Some of the projects I&#x27;ve seen could have been reduced in size multiple times with no effect on the outcome whatsoever. In one instance I rewrote a GUI app and made it 15 times smaller (!), that&#x27;s my absolute record to date.<p>Been wondering for years, so you need to actually be inventive to add unnecessary complexity, it&#x27;s not that it comes for free or because of incompetence (though that too of course). And a lot of the times it looks almost as if software engineers do it on purpose, sometimes very creatively at that.<p>Where is this coming from? Is it because we want our work to look important?

Some scattered thoughts:<p>Just today, I built a complex order editing form in vanilla Javascript with AJAX. It&#x27;s over 900 lines of Javascript where half of the code is state management boilerplate, painstakingly ensuring the correct effects are run when the user changes an order line&#x27;s quantity or picks another product. We currently can&#x27;t use libraries with our stack, so it was necessary to write it like this, but it made me yearn for the frameworks.<p>The frontend landscape isn&#x27;t more complex than it needs to be, it&#x27;s as complex as we need it to be. We take many things for granted in our modern stack. Sure, Javascript has come very far in many areas, but it also lacks many things that are regularly needed and the tooling covers for that. Things like state management, functional composition of layout and form validation are things that Javascript simply doesn&#x27;t (and probably shouldn&#x27;t) provide, and that&#x27;s why we have libraries&#x2F;frameworks for those.<p>I see many people bashing on Redux in the comments section. Redux can be overkill if you&#x27;re writing a single-page (like, actually one page) website, but as soon as you need to manage user credentials and state that needs to be persisted across many pages (think shopping cart), Redux becomes indispensable for me. Sure, you can use something like useReducer, but it doesn&#x27;t really compare once you add redux-toolkit to the equation.<p>I agree with the general sentiment about the npm ecosystem. Like with anything else, taking &quot;don&#x27;t reinvent the wheel&quot; to the extreme causes chaos because the entire world is not a monorepo and we have to rely not breaking one another (which fails often). My rule of thumb for whether I should reach for an npm package is &quot;can I write this correctly and with tests in an afternoon?&quot;. Things like arbitrary-precision decimals fail that test, but many others simply go into utils.js.<p>To summarize my thoughts and make myself a bit more coherent: The frontend tooling is as complex as we need it to be. Evaluate what you need and build your stack with that. Don&#x27;t join any cargo cults, both for and against framework use.

I think it&#x27;s generally caused by a few issues:<p>1. UI development is hard to do well. Throughout my career I&#x27;ve seen complexity explosions in C++&#x2F;Win32, C#&#x2F;WPF, and JS UIs so this isn&#x27;t a new phenomenon<p>2. It&#x27;s always easy to develop the correct UI in hindsight once all the requirements are known. When starting out it&#x27;s hard to know what will be needed or not and this leads to overly complex solutions<p>3. The browser as a platform has historically been painful to use due to a lack of good standard library<p>4. JS in particular has a low barrier to entry, so a lot of folks start there and learn as they go. This leads to picking the wrong tool for the job due to lack of experience

1- As @tgflynn mentioned: historical complexity<p>The web was made for publishing text, not making rich apps. But it turned out to be exceptionally good for publishing SaaS. So we continued to pigggy back on it. Working directly with the DOM is too verbose, hence nobody wants to touch it.<p>2- Service oriented architecture<p>When mobiles became a thing around 2008, normal MVC apps with some AJAX would not cut, because mobile phones needed their own UI. Hence REST based approach became more popular. Things like React and Angular (or Backbone and Knockout) filled that void.<p>3- UI is an evented runtime<p>I think of UI as a small Kafka because it needs to handle events (from the user, from the browser window, from OS etc). This makes managing state tricky. To manage this complexity, the community comes up with libraries like Redux. This creates a gap for developers working at a smaller scale. With a small app, you might not run into issues arising due to event management, you might not run into race conditions. But since big companies use a particular library, small companies start using it too. This adds to the bloat.<p>Is there a fix ?<p>I think so. But it will include developers thinking outside the browser (or maybe the browser starts thinking outside the DOM?). Libraries like Hyperview and DearImgUI exist and are being used in production. Games are a good example. A game engine can render a complex scene with 100s of moving entities at consumer grade hardware. At the same time websites suffer when rendering large list views.<p>At the end, FE is a political landscape. A large majority of developers and companies are happy with the current state of tooling. Unless an influential figure pushes for a better UI standard, we will continue to write React.

Because the browser nowadays is an &quot;operating system&quot; that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc. I haven&#x27;t done Windows development, but I assume browser-based development complexity will continue trending towards essentially the same complexity as developing e.g. a Windows program.

I think it&#x27;s something analogous to Jevons&#x27; Paradox.<p>Jevon&#x27;s Paradox, originally written about the use of coal, noted that as it become more efficient to use a resource, the end result was generally not that less of that resource was used, but in fact more.<p>I think the same thing has happened in frontend development: Tools which were written to make development easier have not had the effect of making it easier to do frontend development, but have made it possible for outside factors (product managers, customers etc) to demand ever more from frontend devs.

Why? I think mainly FOMO. When react was out with the blessings of Facebook people wanted to use the same library. Of course most people didn&#x27;t really care&#x2F;understand that their internal crud app for editing invoices wouldn&#x27;t need that complexity.<p>I think my answer should answer your second question: This kind of complexity is actually needed on some apps but these apps are a minority.<p>Programmers love shiny new things and most managers aren&#x27;t technically competent enough to lease them...

Unpopular biased opinion.<p>Frontend development is mostly done by people who are into visual things and less into logic.<p>Unlike backend engineering, where people working are primarily choosing technology based on logic&#x2F;merit and less by visual appearance.<p>This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing.<p>After some time frontend developers will find some new framework with a better landing page and move on to that.<p>And the cycle repeats.

HTML and CSS weren’t designed to be general-purpose GUI description languages. HTTP wasn’t designed to be a client-server GUI application protocol. JavaScript wasn’t designed to be a serious application programming language. And the continued evolution of those technologies hasn’t focused enough on substantially changing that state of affairs. For example, a lot of basic UI controls still have to be custom-implemented and custom-styled by each app. CSS layout and styling is still a byzantine minefield. The ecosystem of tooling and libraries and frameworks remains highly fragmented. A staggering amount of manpower is being wasted away in bespoke frontend development.

I would not say that Web UI is <i>that</i> more complex than desktop UI. In principle.<p>It is media that changed quite a lot - spectrum of devices that we need to show our UI on.<p>We had pretty much fixed 80x24 character terminals, then we had 640x480 pixel grids, sometimes 800x600 and more. But at that times you can still assume that pixel is presented to the user as a square of 1&#x2F;96 x 1&#x2F;96 of inch.<p>Such fix allowed us to use UI designs nailed down to pixels grids. That was time of flourishing WYSIWYG UI editors. Alice, designing her UI in Delphi (or VB) editor, can be sure that Bob will see it in the same way. Her cool 16px icons and bitmap fonts will make Bob and friends happy.<p>When we needed some &quot;extremely cool&quot; stuff at that time we were providing bitmapped skins. Remember WinAmp (<a href="https:&#x2F;&#x2F;skins.webamp.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;skins.webamp.org&#x2F;</a>)?<p>Time is passing by and we have now huge variety of devices with different pixel densities (96ppi, 192ppi, 300+ ppi) and pixel grid sizes - from watches to wall sized TVs. But we still want to show the UI on all of them in reasonable manner.<p>The solution is to change paradigm an so to use a) vectors for UI definitions and b) flexible&#x2F;adjustable UI definitions that are detached from pixel grids.<p>Web, as a UI platform, desperately needed vector UI with flexible layouts as the very same web page needs to be presented on all platforms|devices in reasonable manner. And so it was the first one that departed from fixed layouts.<p>So UI design have changed from simple 2D painting (physical brushes and canvas, paint.exe ... Delphi&#x2F;VB&#x2F;Glade IDEs) to procedural and rule (layout, style) definitions.<p>We speak now in quite different UI language and that&#x27;s what was changed really.

I disagree with the premise, things have gotten a lot simpler.<p>I think you need to make distinction between website and web application. The latter came later and is by definition a lot more complex, I assume this is mainly where the premise originates from.<p>But having gone through building websites with frames, tables, png&#x27;s for box shadows and border radius, jQuery and php based web apps, and having spend many days making my grunt&#x2F;gulp&#x2F;webpack config work and supporting IE, I can with great certainty say things have never been easier than they are now.<p>Now, is it necessary [to build webapps]; Yes. Usability expectations have gone up, the level of details and polishing has gone up, more interactivity, and more sophisticated visual elements. Webapp now do things native applications could not do back in the day.

I&#x27;m more of an ops and backend guy, but I used to do a lot of web development in the early days of the web - assembling HTML, a sprinkling of javascript, hand-rolled CSS and embedded styles. In a certain way it was very simple, but in another it was horribly complicated. Sure, the pages we built were simple compared to today, but the tools we had were extremely crude and building a large website required some pretty clever things to stay maintainable. After I started doing more backend stuff, I lost touch with the evolution of Javascript and its various frameworks and I believed everything had become very complex.<p>Recently, however, for fun I&#x27;ve been tinking with TypeScript and Vue and I have to say, it all seems way easier than how we did it back in the day. CSS seems far more reliable, HTML now has sane ways to lay things out, Typescript&#x2F;Javascript has evolved wonderfully, and these modern frameworks that isolate components from each other and bundle code, style and layout together are almost a pleasure to use. Sure, there are some concepts you have to learn, and there&#x27;s so much magic happening behind the scenes it&#x27;s terrifying. But I&#x27;m building stuff I would have spent days on in a matter of hours now and I have no idea what I&#x27;m doing.<p>What I&#x27;m noticing now though is that now that frontend development has become a lot more about coding and a lot less about knowing arcana, frontend coders seem to be going through growing pains that are a lot like backend coders have already gone through. For example, it&#x27;s funny to me to see discussions about how to handle components needing to access shared data. Should you pass the down down through the component hierarchy or have a single global data object that components can interact with, and I&#x27;m thinking, next stop, a dependency injection framework. I&#x27;m not sure I&#x27;m actually right about that, since I&#x27;ve only just played around a little bit. I&#x27;d be interested if others would agree with that assessment.

I recently transitioned to a &quot;full-stack dev&quot; role (using React on FE), and honestly, it is much _simpler_ than I expected. I had the opinion before that FE is lacking the breadth of BE development, but of course, without actual experience in the matter I might have missed something.<p>Now that I&#x27;m 2 months in, I still don&#x27;t see the complexity, actually, if anything, React makes stuff so much _simpler_ due to its leaning heavily towards FP (to me, the class-based approach of React seems more complicated than the hook-based, for example, deciding what `this` points to at any given time in Javascript is no small feat - with functions&#x2F;closures, you don&#x27;t have this problem). There is depth for sure, handling all the possible errors and edge cases requires care and attention, just like in the BE.<p>To me the only shock so far was how low level all the stuff is, I mean come on, we had Delphi in the past millenium already, creating a form with a text field and connecting it to a field in a data structure was a solved problem back then... a &quot;one liner&quot; if you will, now you have to independently manage the state and handle events for each field? Come on, there must be a higher level library that solves this!

I suspect a lot of it is historical. If you go back a few years there were lots of browser incompatibilities and many limitations in Javascript, CSS and HTML. To work around those difficulties and limitations many frameworks were created. Today many of the limitations of the basic technologies have been fixed but the frameworks are still here, though probably less necessary than ever. But once people have gotten used to doing things a certain way (for example using jquery instead of querySelector) they tend not to change.<p>This isn&#x27;t unique to web development. The same thing happened with C++ and Boost, for example, where gradually the language and standard library evolved to include functionality that previously required 3rd party libraries.<p>But I think far more work and money has been invested in web development than other areas, hence creating a bigger mess.<p>My impression is that the actual user experience of most web sites, including the big ones like Amazon, has improved very little over the last decade, so it feels like all the effort put into web technologies has, so far at least, not produced a lot of value.

Sure developers have a hard time handling all that HTML, CSS, Javascript and connections(DOM, etc.) between them, but I see a much bigger problem in browsers. There are actually only a few browsers and most of them are based on chromium(or Webkit). Why? Because web standards are huge!<p>Their complexity is so big, that even great programmers have a hard time creating browsers from scratch. The latest example of this is probably Ladybird[0]. Andreas Kling and others have worked on it for years(&quot;Just under 1000 days for a bunch of hackers to build a new JavaScript engine&quot;[1]) and they know it will require way more time to just catch up the Chrome[2].<p>A year ago I started to build SkyAlt[3], which doesn&#x27;t have anything to do with the web. It&#x27;s not just a browser, but also an IDE where you can create apps with few lines of code or just drag and drop stuff on canvas. It&#x27;s written in C and it&#x27;s only 25K LOC. Compiling takes a few seconds and binary is under 1MB. There are tons of features that need to be built, but I like its simplicity(relative to the web).<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;SerenityOS&#x2F;serenity&#x2F;tree&#x2F;master&#x2F;Ladybird">https:&#x2F;&#x2F;github.com&#x2F;SerenityOS&#x2F;serenity&#x2F;tree&#x2F;master&#x2F;Ladybird</a><p>[1] <a href="https:&#x2F;&#x2F;twitter.com&#x2F;awesomekling&#x2F;status&#x2F;1596783757125898243" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;awesomekling&#x2F;status&#x2F;1596783757125898243</a><p>[2] <a href="https:&#x2F;&#x2F;twitter.com&#x2F;awesomekling&#x2F;status&#x2F;1595387284035145729" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;awesomekling&#x2F;status&#x2F;1595387284035145729</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;MilanSuk&#x2F;SkyAlt">https:&#x2F;&#x2F;github.com&#x2F;MilanSuk&#x2F;SkyAlt</a>

mid-2000s I think it all started with the rise of AJAX and &quot;Web 2.0&quot;. In the beginning it was just sort of gimmicky for visual effects and experience and we were all scratching the surface of what browsers could do.<p>2006-2009 server side frameworks were in vogue but most were slow and sometimes memory intensive. In the pursuit of creating highly interactive experiences that also scale many of us were optimizing website architectures around cached components of varying vintage and write frequency.<p>By 2009 we were solving for performance + scale + interactivity challenges using client side rendering for highly interactive components. During that period I can remember doing isomorphic rendering of mustache templates in server side Ruby and client side Javascript.<p>2010-ish Node was starting to gain traction and lots of attention went to Javascript. I think post-2010 many were pushing web app architectures to more client side business logic as web browsers became more and more capable. Backbone.js, SproutCore (now Ember.js), Knockout.js and others were on the scene by then and I think most other frameworks are inspired or derivative approaches meant to solve for their shortcomings.<p>2014-ish I think everyone was pushing responsive web. Apps got fatter and needed CDNs now more than ever. Websockets start to gain maturity. Cloud-services really start to gain traction beyond EC2 type deployments.<p>2015-2016 is the inflection point where client side frameworks start to get stupid complex, i.e. I can no longer read the source code of a web page easily, simple read only sites have a loading screen and&#x2F;or need to download 1MB+ for reading a basic page.

The lack of objectivity around this is absolutely astonishing from a community such as this.<p>It exploded with complexity because frontend complexity exploded. Simple. Absolutely no people expected an &quot;API call&quot; from a frontend application 20 years ago, now people expect loading indicators on buttons (that make API calls) after pressing them.<p>Just have a look at the comments on the recent Standard Notes &#x2F; React Native post. <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34197613" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34197613</a>

On the web side you need to synchronize the DOM, the visual state (which is mostly related to the DOM), the user&#x27;s state, and the backend state using a protocol that&#x27;s stateless.<p>Really, the browser side stuff is the real PITA. It&#x27;s a hacked together piece of shit written by people who were too clever by half. And it&#x27;s designed to be used&#x2F;driven by less-than-skilled individuals.<p>But in the end one big problem is there aren&#x27;t a lot of ways to model a UI effectively. One given screen can have multiple states and behaviors that are state dependent, and the tools really aren&#x27;t there. How do you specify &quot;animation like x&#x2F;y&#x2F;z&quot; on a screen?<p>There are tools for designers, but they&#x27;re don&#x27;t really work when handing that off to development. What I&#x27;ve seen is people printing out prototype screens and annotating everything, but that&#x27;s obviously janky.

The question itself might contain a partial answer. If &quot;frontend&quot; and &quot;backend&quot; are assumed to be two completely separate disciplines, the architecture is going to reflect that (Conway&#x27;s law).<p>It&#x27;s possible that building a website as a wholistic product (ala Ruby on Rails) is inherently less complex because it eliminates an artificial boundary. We see backend teams struggling to build APIs and frontend teams struggling to consume those APIs. Many of the technical problems, communication overhead, and complexity seem to lie at this API boundary. Consider what if the software team (singular) just created HTML UIs directly from the DB and eliminated the middleman? I&#x27;m looking at things like HTMX and phoenix live view as a potential solution.

Frontend was always complex, being web, mobile or desktop apps. It is following similar cycles from decades ago. Winamp[1] in 1997 made their own UI using custom draw in Windows because those components and level of customization didn&#x27;t exist in the standard API. We can historically observe these cycles of complexity and technology changes only looking at Windows toolkits: Win32, MFC, QT, Silverlight, Windows Forms, WPF, etc.<p>But the other reason is that we don&#x27;t have stable tools and the right abstractions to build a UI&#x2F;UX for dummies so there is lot of reinvention.<p>Because nobody built a good UX&#x2F;UI for dummies that hides this vast complexity?<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Winamp" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Winamp</a>

People wanted applications and app-like behaviour in the browser. And browsers are uniquely <i>uneqipped</i> to deal with that:<p>- the core if the web has been, is, and will forever remain a system of displaying static text with a couple of images. You as much as look at it funny, and it needs to re-layout and re-render the entire screen<p>- there&#x27;s no standard library to speak of<p>- there are no standard widgets and controls to speak of (<a href="https:&#x2F;&#x2F;open-ui.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;open-ui.org&#x2F;</a> is twenty years too late)<p>- there are no easily accessible ways of handling state<p>- almost every single API that the web provides is either underngineered, or overengineered, or badly designed, or all of them together<p>- the web rarely provides a comprehensive and&#x2F;or a generic solution or an API. It&#x27;s a hodgepodge of one-off hacks often needed to cover deficiences in other hodgepodge hacks<p>So, to make the web even remotely app-like, you need to solve for all these issues, and that&#x27;s before you even start writing a single line of app logic.<p>And on top of that you have language evolution and people wanting to use features of tomorrow today.

This will be a posting, which either receives no to little responses or will have 256 responses within the next couple of hours :)<p>I am sure, there&#x27;ll be quite a few who&#x27;d argue that this is necessary complexity, but my take on this definitely is the latter - artificially inflated<p>But it&#x27;s not only <i>the web</i>. Same happened to Java in the 2000s and is currently happening to Android. Any mainstream Java job is more configuration of Spring containers with a bit of code glue sprinkled in-between than &quot;proper programming&quot;. As for Android, just follow a couple of Android forums where plenty of people complain about such complexity and <i>frameworks</i> changing &quot;by the minute&quot;<p>Aritifically inflated :)

In my teens, I could regularly churn out a small GUI program after school in an application like HyperCard, or later REALbasic (now Xojo). I remember writing a saved game editor for Psion Boy[1] which had an editable list of inventory items, fields for character stats, and buttons for saving and loading game files.<p>I have many more years of experience programming now yet I could not make the same program nearly as quickly. Fire up Xcode and then fumble with storyboards or SwiftUI or IBOutlets? Start writing functional React components on a Bootstrap grid with some live reload script injected into the browser?<p>Modern frontend tools enable improvements like accessibility, internationalization, cross-platform compatibility, touch screen support, etc. But they have really extinguished my excitement to build anything beyond the command line.<p>1: <a href="https:&#x2F;&#x2F;macintoshgarden.org&#x2F;games&#x2F;psion-boy" rel="nofollow">https:&#x2F;&#x2F;macintoshgarden.org&#x2F;games&#x2F;psion-boy</a>

Most of the answers here are pointing to things like inefficiencies, short-sightedness, and over engineering, but I&#x27;m not seeing the positive side.<p>The web is an incredible distribution channel. With decent engineering, anyone can make an app that has access to an enormous marketplace with very little capital costs.<p>The past 20 years of software have been dominated by this distribution model so it&#x27;s easy to take for granted, but compared to pre-web distribution that involved manufacturing and much larger differences in user platform, it makes sense that the world is trying to squeeze as much software as possible into this model.<p>With that comes complexity.

React must be used for all websites- no matter the cost, no matter the implications, no matter the practicality. How else will you hire any developers? They explode if not writing JSX.<p>If something doesn&#x27;t work out there is yet another react-centered solution to your problem. Server side react can probably fix it. Tailwinds can fix that other thing.<p>These websites must, obviously, be hosted on kubernetes clusters. They must also be behind three or more load balancers.<p>Never attempt to cache anything. Redux is managing state and state can&#x27;t be cached.<p>I realize you didn&#x27;t say &quot;React&quot; in your question.<p>redis has to be installed, even if not used.

Expectations have increased a lot in web development. When I first started working, web front ends for business applications were ugly. They were designed to do the job and nothing more. They might also be hard to use without a manual. These days the designs I get given look pretty and have simplified interfaces for the user. The designs never use native elements and often invent novel UX interactions.<p>Back when I started, the go to front end wasn&#x27;t a web app either. It was some GUI on windows which involved pretty much the same level of complexity as we have today on current web apps. So maybe the question isn&#x27;t really &quot;why did front end development explode in complexity?&quot; But really &quot;why do we expect front end development to be simple when asking for complex UX?&quot;

Because expectations have gone up and a developer can&#x27;t even take on coding some pages without prior input from some UX enginner who is likely assisted by some UI designer.<p>Because we don&#x27;t have just 1 or 2 desktop web browser mostly rendering text anymore.<p>We&#x27;ve got 3 or 4 major browsers that most managers want to support all, even though one has over 50% user adoption, and could be installed within 2 mins if not due to IT administrators locking everything in and shipping almost nothing to browse the web.<p>Each of those &quot;major browsers&quot; with their own same but not the same implementation for mobile, across many different sizes from tiny low rez screen to worry about to phablet&#x2F;tablet factors, that can rotate of course, so landscape and portrait please, packing videos, photos, and scalable graphics often within the same visible area.<p>One would think that&#x27;s enough headache to deal with, but fonts aren&#x27;t treated equals, and remain proprietary so text won&#x27;t be the same across windows, linux, OSX and android. No. You may pick one system font that is called the same so should be the same, but it isn&#x27;t actually the same, at least last time i checked it wasn&#x27;t.<p>Oh, and the highest speed consumer bandwidth out there is something like 400Mb&#x2F;seconds, and the lowest might well be a under 100kb. Both want the best possible, so full HD clip and MB pixels pictures for one, and low def steaming and scaled down pics for the other. And throw something in between to make the average bandwidth users also happy.<p>Oh, and since we got the cloud and aws is &quot;cheap&quot; demand super quick agile delivery of course. Co pilot and soon gpt codex will make it no-excuse to be late on those over optimistic estimates.

I get the impression making a web app was considerably more difficult for a solo developer pre-jQuery. For a while we had an explosion of choices, and ultimately things coalesced around React and similar paradigms. Meanwhile the per-capita productivity has been skyrocketing as increasingly sophisticated cloud services provide everything from raw key-value storage to turnkey caching and auth solutions.<p>Is it more complex than single-device programming? Perhaps, but the modern browsers represent a nearly universal platform with very low per-user complexity.

From an application manager&#x2F;solution manager perspective, I see 2 main reasons and a few smaller ones:<p>1. more and more complex UI. Things that used to be done in a native app are now in a browser, this has good and bad parts.<p>2. a lot of show off from the developers side going for overly engineered solutions. Nobody likes HTML+CSS and JavaScript anymore, if there is no cool framework with tons of tooling and dependencies than they are not happy. (yes, I know, flak incoming)<p>Other reasons are the complexity of dependency chains, the lack of security mindset by having hundreds of dependencies looking for a left-pad, the complexity coming from the testing of these overengineered and overly complex solutions, the move towards hybrid front end-back end management of state, rendering etc. There is also the overstretching of the frontend development role, now a fe dev needs to not just write the equivalent of HTML+CSS+JS but also containers, devops, CI&#x2F;CD, all that jazz.

&#x27;Backend&#x27; work has had longer to be refined.<p>Backend developers are much more likely to pass leetcode and algorithm questions and have decades and decades of material and languages to draw from. We don&#x27;t use 1st generation stuff to build anymore.<p>Once &#x27;frontend&#x27; (i.e. browser dev) has close to that much time to cook we&#x27;ll have a lot better experience with typed language support native in browsers and&#x2F;or a proper green threads.<p>I mean, just look at everything that came out of the past ~10 years alone: Coffeescript then Typescript, LESS, SASS, most bundlers, push notifications, webworkers hot reloading, websockets, webrtc, SSE, free&#x2F;default-on certs, all the component frameworks like bootstrap, tailwind, material ui etc...<p>While browsers have been around for a while, the ability to use the browser as a full-featured UI is pretty recent and most people working in this area seem to be pretty young.

Web 1.0 was very simple programatically:<p>1. user requests page<p>2. program generates page<p>3. user clicks on something.<p>4. * entire page is regenerated *<p>Javascript was terribly incompatible across browsers, so it was avoided. Then in 2004 or so, jQuery made it seem easy and desirable to do more than just regenerate the whole page when a user took an action. This introduced all the complexity you see today. React is just the apotheosis of a long sequence of tools whose purpose was to <i>reduce</i> the complexity introduced by jQuery (and &quot;Ajax&quot;).<p>One way to look at it.

The main reason is because we shoehorn complex apps&#x2F;ui&#x27;s into a browser that wasn&#x27;t made for it.<p>It&#x27;s not the UI is very complex , or that there are ton of frameworks with different maturity levels.<p>It&#x27;s because the browser and thus html&#x2F;CSS was made for documents.<p>If we made a &quot;browser&quot; made for apps, where we didn&#x27;t need to transpile to js, and didn&#x27;t need to cater for incompatible browser versions, but could concentrate on what really matters we wouldt have such a big problem

Several reasons:<p>1. Lack of skills. Front-end has evolved from web design. If people like to criticize software engineering as “not real engineering” then front-end is the farthest thing from engineering that exists in software engineering. One can see this in the programming languages, the code reuse (libraries, packages, etc), the tools and the attitude.<p>2. Too much ambition. At the same time I don’t think I’ve ever seen a community so driven by reaching their goals at any cost. Once apps kneecapped web sites the community had a major identity crisis which they solved not by doubling but by tripling down on HTML, CSS, JS and the like. Standards, common sense, performance, usability, privacy be damned. Because of point 1, the solutions they built were also just good enough to not completely fall apart. This is also why everything’s being rewritten in the web.<p>2. Too much money. Unfortunately companies like Google and Facebook made an immense amount of money ruining privacy for everyone and they could do this faster, better and out of sight with web apps. They poured money into web technologies like their lives depended on it (because they did) and in the end managed to squeeze a round peg into a square hole: the fundamentally mediocre web managed to displace more worthy technologies and entrenched itself.<p>Every few years some poor soul realises the reality of their professional existence and writes a blog post or comment asking something along the lines of “Why is front-end so terrible?”. But there’s too much money in the status quo, so they either get gaslighted, or subtly dismissed and the cycle repeats anew.<p>And that reality is that you <i>can</i> polish a turd. With enough manpower, motivation and money you can really make it shine. But underneath, it still stinks and people will figure it out. :-)<p>Note: I got out of front-end in the 00s and then out of back-end a year later. Since then I’ve watched this never-ending train-wreck with amusement and amazement, but also sadness when realising how many real apps are replaced by soulless Electron shells.

Back in the days of mostly static HTML, and maybe some simple JS for effects, you didn&#x27;t need much complexity in the Frontend. Most logic was in the backend. That logic has moved to the Frontend, and so has the complexity. Yes, Frontends are more complex than ever before. But at the same time, backends have never been simpler. Most backend devs just implement some simple CRUD APIs for the Frontend code.<p>The UIs also have become more complex. In early web apps, you submitted a form and got feedback only after submission. The expectations for modern web apps are much higher. Everything has to be evaluated as soon as possible, possibly while the user is entering it. Responses should show up immediately, so there is a lot of caching in the frontend. It all adds up.

Because complex applications are now delivered as web apps instead of as desktop applications, and these require complex tooling to maintain. Then everyone wanted to use the same tools in other areas (I guess), where it is probably not necessary in a lot of cases. You see similar trends elsewhere (e.g. cloud, k8s), perhaps CV building is the real reason.<p>Then again, a lot of the complexity is mostly optional these days. But knowing how to avoid it is tricky, given the amount of tutorials online that will happily convince you to use webpack, redux and whatever else that was made for bigger problems as if they should be used everywhere.<p>I don&#x27;t envy young programmers these days, the amount of stuff to wade through is just mindblowing.

&gt; Why did Frontend development explode in complexity?<p>The browsers became more capable (as someone said in another comment, they are effectively shooting for operating systems now), and more ambitious projects became possible. Consider such web apps as:<p><pre><code> - Google Maps - Google Docs - Google Meet - Youtube - Adobe Photoshop online - Figma (or Penpot) - Miro (or Mural) - Excalidraw (or diagrams.net, or lucid charts) - Slack (or Discord) - ...etc </code></pre> &gt; Is that complexity necessary or artificially inflated?<p>This entirely depends on the product. You need the complexity for some products; and not for others.

I agree it&#x27;s gotten too complicated. In my mind, the evolution has gone like this:<p>1) Plain HTML&#x2F;CSS, built using desktop tools like FrontPage&#x2F;Dreamweaver<p>2) Server-side scripts (CGI&#x2F;ASP&#x2F;ColdFusion) to dynamically generate HTML&#x2F;CSS. Javascript or VBScript for &quot;Dynamic HTML&quot;.<p>3) Javascript wins, VBScript dies. Javascript idiosyncratic between browsers. Flash fills niche for dynamic client UX that generally works on most browsers.<p>4) iPhone happens. Safari won&#x27;t support flash. Devices that do support flash or a subset have terrible battery life.<p>5) Javascript has matured. jQuery patches remaining cross-browser issues.<p>6) Server-side frameworks like ASP.NET, Ruby, PHP, NodeJS mature.<p>7) JS further matures. cross-browser without jQuery feasible, but binding to JSON is still clunky. Frameworks like Angular, Vue help with databinding and other common problems developing JS&#x2F;CSS&#x2F;HTML clients.<p>8) If you solve enough problems, you end up with a framework to build a complete client, transpiled from various languages (TypeScript, SASS&#x2F;LESS, some markup). Angular, Vue, React, and other SPA frameworks evolve further.<p>9) Some UX&#x2F;SEO&#x2F;perf issues with SPA approach. SPA frameworks evolve to support server-side rendering.<p>10) Static sites generated by frameworks reduce the need for server at runtime. Build the site and host on cheap CDNs<p>...and this is where we are now. As someone more used to ASP.NET + Vue&#x2F;Angular, I&#x27;m still having a hard time transitioning to server-side rendering, WebPack, etc. It just feels like too much ceremony and too many dependencies. I think the industry is waiting for some solution that is low-dependency, widely adopted, open. I haven&#x27;t found my perfect platform yet, but feel it looks like this: Put a few files in source control and very easily spin up sites that look ok by default but are easy to customize. It supports building sortable&#x2F;filterable grids,lists, and forms against some server API (REST&#x2F;GraphQL&#x2F;etc) with minimal code and and simplifies auth. It also has a rich ecosystem of components.

I&#x27;ve done frontend since IE6 was the major browser. Back then most of the time was spent using hacks to work around the limitations. No rounded corners, no opacity, no grid, etc. As it got easier, with better adoption of the web standards and better tooling, frontend-devs were able to do more. But I feel as REST and GraphQL got more adopted a lot of the complexity moved from the backend to the frontend. The frontend part is easy these days, but working with the backend is the hardest part of being a frontend developer.

Complexity is one end of the spectrum. Browser APIs for various stuff like animation, video, audio, webgl, etc is not that easy for developers to consume. Often most of these features have their own set of sub-complexities and concepts. For e.g. drawing&#x2F;animation on the canvas is relatively simple, than doing stuff with 3d animation; the latter involves lighting, viewer perspectives, etc.<p>And developers don&#x27;t need all of these browser features every time; much less for the same project. But from a framework POV those features need to be there. Because, as a framework developer you cater to a relatively wide developer profiles.<p>So far we&#x27;ve talked about browser APIs and how a framework seems to lend support to them. Building web apps are a whole different affair. When concepts such as optimization, and, page-load speed kick in you&#x27;d definitely think of tools that abstract away the common chore of such optimizations. Again these optimizations have their own set of options, and, hence complexity.<p>So today the whole affair may seem complex. But really its not artificial. There was a need and hence a solution. To anyone relatively new to web development all this might seem complex. And at some level, even we humans also unjustly decide we need to have some features because &quot;others are also doing it&quot;. This also increases complexity in maintaining those solutions.<p>Bottom line is, it is a relative illusion, and, it just echoes the state of modern browsers, and, modern web development trying to be vogue.

Consider how desktop apps have basically disappeared. They&#x27;re all in the browser now.<p>Also, ask yourself what the difference in UX is between serving templates vs. something like React. Are you not getting something in return?<p>There may be some artificial inflation but think about websites from 10 years ago.

A host of reasons but it&#x27;s my opinion that the calculus of what you can develop for what resources simply workout, and that math trumps the regrettable bloat that a portion of the population notices.<p>You can look at the complicated tooling of &#x27;23, the increasingly niche roles (&quot;React state management expert&quot;), the bundle sizes, the expanse of the browser spec and wonder how this trend is sustained, but there&#x27;s a flip side to all of this: it&#x27;s easier today than ever to develop well-utilized, sophisticated software with a team. That last part is important- since teams build most of the well-trafficked web applications out there it will be the limiting factor in economic equations. And all this specialization and bloat is conducive to concurrency (see Conway&#x27;s law [0]).<p>I&#x27;m reminded of an Economist article I read that asserted that better engineering often doesn&#x27;t solve a traffic problem since the pain of traffic will approach the threshold of what people will tolerate. People who don&#x27;t drive because of traffic start driving until the commute is nearly the exact same.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Conway%27s_law" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Conway%27s_law</a>

90% of small and medium apps could be redone with a simple UI toolkit that gives you a box of widgets and callbacks. I built a geoscience 3D application in the mid 90s with FLTK and it was the last time I made something UI based where I didn’t feel that the UI toolkit was getting in the way of getting the work done. Assuming a lot of complexity in anticipation is the wrong approach 99% of the time.

In my opinion the complexity is caused by the amount and the combination of technical choices, design choices, and process pipeline choices.<p>... Long story short is that a web app is cross-platform (browser) program and that very quickly gets quite complicated requirements. Of which security, dependency management and frameworks are a big part. Because you need to know about them, and how they work etc..<p>Long story &#x2F; ramble:<p>A simple static website can be as simple as a bit of HTML with CSS.<p>But when you introduce workflows and users it isn&#x27;t long before security comes around the corner. And that introduces a lot of complexity, which frameworks and packages help with. (Don&#x27;t roll your own)<p>So the security packages comes with typescript. Which makes you adopt typescript and adds a bit of complexity over JS. (But also typesafety! I&#x27;m a fan FYI)<p>And then you want the website work as a progressive web app, so you need a service worker. More complicated.<p>You then might want to add some sort of isolation of CSS, or use Sass or some other framework. To help with code re-use and avoid breaking things as the app gets larger. Also more complicated.<p>Then your PO says you need to have async workflows and let the user know when something starts and is done, with push messages. So you need a background worker and push messages.<p>And we&#x27;re not even talking about the technical issues, like not all browsers supporting certain API&#x27;s or certain styles. Or updates to package X breaking package Y, needing a package patch.<p>Not to mention keeping up with the evolving syntax and language capabilities. HTML, Javascript, Typescript, CSS, SASS etc... They all keep changing and evolving.

Because we took a platform for linked documents and grew it into a platform for applications. If the web were still documents, or if it started as a platform for applications, then it wouldn&#x27;t be as complex.<p>Another reason is that the languages and tooling to do these things are always easy to start and painful to master, leading to too many sort-of capable people dreaming about how to do it better.

Related question: what would the folks here recommend for someone that wants to keep the frontend “stupid simple” while not resorting to writing everything in pure HTML&#x2F;CSS&#x2F;JS?<p>I’ve heard mithril.js recommended before but I’ve yet to try it. I have experience with Angular, React, and a bit of Ember and the amount of code and “magic” involved is absurd.

JavaScript as an ecosystem and language became much more accessible than ever, with all the toolings and TypeScript, it&#x27;s easier to build abstractions upon abstractions; and people love to have their own version of abstractions. It&#x27;s human nature, it&#x27;s inevitable.

All I have to say to this is we recently rebuilt our admin tools application and the team responsible have been all backend &#x2F; devops engineers. Stack is React and GraphQL. Without having any real FE experience this team has been absurdly productive. Rewind the clock a bit and it would have been a nightmare. From this experience alone I can conclude that the complexity issue the OP is citing is mostly an illusion, assuming there&#x27;s someone around who can help guide tech choices at the beginning. There&#x27;s simply no way a team of non FE engineers could build this stuff so well, and so quickly, a decade ago.

It&#x27;s a combination of:<p>- Fast Fashion for web sites. Users are kinda like kids in a toy store, always jumping to the newest &amp; coolest &amp; shiniest things. <i>OR</i> - at least the suits making the calls are far-too-often convinced that they need the newest &amp; coolest &amp; shiniest web site, to compete for users.<p>- One-upmanship among young male web developers, who always want to be working with newer &#x2F; cooler &#x2F; yet-more-complex technology than the next guy. And how very convenient that newer, cooler, and more complex technology tends to pay far better, whether it&#x27;s needed or not.

I keep seeing this type of thing popping up. The short answer is because people are expecting more from the web.<p>What interests me is why are so many people perturbed by this. If I look through my bookmarks, pretty much everything could be server side rendered without any need for JS. It’s all stuff like HN or news sites. I wonder if the OP and others who have asked this before see the same thing: the consumer internet sites they most visit don’t need complex JS. But that doesn’t describe all sites. There are plenty that do require a lot of complexity.

* The increase in complexity is unavoidable as well as accidental (creep due to marketing). Some of it is necessary to address the increased sophistication of the web. Just compare what we can do today to what we used to do in 1996 with cgi and perl.<p>* It is not that native GUI libraries like Qt or SDL or GTK are super easy. GUI are event driven and composed and need to be in sync with the user wishes and as such have a programming model that is different from a top to down execution of instructions.<p>* The biggest challenge with the current state of front end development though is that there are no standards and no stability on a YoY basis. What I learned to do with PHP in 2005 is still valid. I can still use those tricks and whip something useful. What I learned to do with tables in mysql 3.x is still useful with mysql 8.x. However the world of Javascript frameworks is one of shifting sand.<p>What I learned with Javascript framework X.1 will be obsoleted by X.2 and will be obsoleted by X.3. No guarantees for time investment is challenge #1. angular 1.x -&gt; 2.x, Vue 2.x -&gt; 3.x are some examples that come to mind. Think of all the wasted effort. That is the killer. Humans are good at making peace with whatever crap is thrown at them. I do not think technology is the reason here. It has more to do with hype cycles and trying to catch developer&#x27;s attention in a competitive market with new buzzwords.<p>* There is a lack of simple tools like what visual basic used to do. Sure, everything is async and we are in an event driven world but frameworks could have provided a common core to enable simple use cases. bootstrap library is a case in point. I can get decent results with bootstrap without knowing the intricacies of css. However I am hard pressed to find a suitable Javascript framework.

Frontend is inherently complex and becoming more complex because we build more dynamic web apps. PM and designers don&#x27;t know what works and keep changing the product until they get something acceptable, which will also mean much more moving parts for developers until the product matures.<p>The complexity will stay and get bigger, we need to a way to control it and be able handle it.<p>The first step is to abstract frontend development (be it web, mobile, desktop or even VR) into concepts then introduce a system to build apps with these concepts.

&gt; Is that complexity necessary or artificially inflated?<p>Totally unnecessary in 99% of cases. There are outliers where this front-end&#x2F;back-end state division madness makes sense (i.e. gigantic apps managed by gigantic teams), but most web properties are not this big.<p>To be clear - the division of state between client &amp; server is where almost everyone is struggling. State management is usually the hardest part of any complex app. When you have 2 piles of it to worry about, you make life <i>much</i> harder.<p>In my view, the happy-path solution has been out there for a while. Frameworks that utilize a web socket (or similar bi-directional messaging abstraction) to directly relay user events &amp; DOM updates. This can eliminate nearly 100% of client-side state. If you keep the logical representation of all clients&#x27; views server-side, you will have a much easier time keeping things synchronized (because there will be nothing to sync except the session cookie).<p>I started this journey with Blazor (server-side), which really helped to solidify the concept and its pros&#x2F;cons. Now, I have a custom framework that achieves approximately the same outcome, but with much better alignment to my problem domain &amp; requirements. I add my middleware and work directly with HttpContext these days. Life is so much easier when you don&#x27;t have to deal with layers upon layers of opinionated indirections.

There&#x27;s a common pattern I&#x27;ve seen over and over. When people learn a new thing they tend to go through a creative phase with it. The first time I noticed it was in a programming class I took in school. We were learning in Pascal. (It was cute!) When we got to the lesson on changing output colors, for the next week it was like some unicorn barfed rainbows all over our screens.<p>People like to play. (Remember blink tag? Scrolling marquee?)<p>What you&#x27;re seeing in the JS Frontend space is (in my considered opinion) a combination of the effect of:<p>1) Lots of people learning to program by messing around with JS, and<p>2) Folks willing to pay people to mess around with JS.<p>So you have a volcano of creativity combined with a tidal wave of money...<p>The results were inevitable.<p>&gt; Follow up question : Is that complexity necessary or artificially inflated?<p>No, and yes. It&#x27;s not necessary (for the vast majority of sites) so it&#x27;s definitely (IMO) artificially inflated.<p>The good news is that you can end-run all the introduced complexity by using e.g. Elm lang ( <a href="https:&#x2F;&#x2F;elm-lang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;elm-lang.org&#x2F;</a> ), or just sticking to simple &quot;plain vanilla&quot; JS systems. The only reason to use something other than Elm is if you enjoy some other particular system (I hear good things about &quot;htmx&quot; <a href="https:&#x2F;&#x2F;htmx.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;</a> )

As I&#x27;ve said elsewhere, frontend development is limited only by the limits of human imagination, whereas backend development is limited by the constraints of backend systems. For example, there is an absolute answer to &#x27;what&#x27;s the most efficient big O runtime I can achieve for sorting this data set&#x27;. There is no absolute answer to &#x27;what is the complexity of drawing an aesthetically pleasing button and modeling its interactions to maximize user joy?&#x27;

Question 1: On average, yes, but not as much as people think.<p>Question 2: both?<p>I started my &quot;career&quot; with an internship job where i had to write deploy some cakephp+sencha extJS with windows server 2004 and IIS (~2013&#x2F;2014).<p>The frontend part were &quot;easy&quot; but tedious, it was tables upon tables, a bit of jquery just because, absolutely hideous css (i think at the end i added bootstrap twitter classes on Sencha extJS). the &quot;backend&quot; was handled a bit like today, with a bit of backend work in the &quot;View&quot; part of the MVC (because Sencha ExtJS). Hard to find bugs induced in this &quot;backend&quot; work, because the only tooling you had were the old devtools, the only documentation you had with the official one (and a bit of SO&#x2F;blogs, but not that much), and since typescript didn&#x27;t exist, you had a lot of weird type&#x2F;casts bugs.<p>I recently started a new job were i also have to do some short interfaces for my step functions, served by lambda (mostly). I had to learn react and typescript from scratch, and thought i wouldn&#x27;t be productive in months. I was productive after a week, and after a month could confidently say i&#x27;m fluent with React router and props, and passable with typescript (Complex union type threw me off for more time than i like to admit). I still don&#x27;t know if i understand ExtJS :&#x2F;<p>By the way: the documentation isn&#x27;t that much better now, with all the shitty blogs and stuff like &quot;tutorialpoint&quot; on google frontpage, but you can search code patterns through github and gitlab, and this help immensely.

For JavaScript, two main factors both driven by fairly mundane and well accepted SWE principles:<p>1) npm encouraged small, &quot;single responsibility&quot; packages&#x2F;libraries<p>2) developers are encouraged to never &quot;reinvent the wheel&quot;, leading to them to pull in these libraries without considering the tradeoffs<p>In other engineering disciplines people are taught to consider tradeoffs more than in software engineering.<p>The tradeoffs of depending on npm packages are:<p>1) You don&#x27;t need to reinvent the wheel, i.e. you can build very feature-rich applications at high velocities<p>2) Tracking, researching, integration, maintaining, and (for longer lived projects) migrating from package-A to package-B can cost way more time and energy than you&#x27;d initially think<p>3) Almost all packages are open source, so maintained in an ad hoc way by the contributors to the project. Even the biggest, most cohesive, well planned projects under the umbrella of tech megacorps sometimes fall into stagnation and maintenance hell. &quot;react-scripts&quot;, which underpins the de facto standard way to bootstrap react apps &quot;create react app&quot;, hasn&#x27;t had a patch version released since Facebook pivoted to the Metaverse.<p>Answer to follow-up:<p>No, you can absolutely write modern, feature-rich front-end applications without any dependencies. You&#x27;ll spend significantly more time writing lower level code allowing you to render your data into some kind of view, manage form inputs, app state and routing, but if you&#x27;re disciplined and determined it&#x27;s totally possible to do.

Regarding frameworks: Things like frameworks have utility in large scale web applications where you need to manipulate a lot of data on screen on the fly. Using the right framework for the right thing can make development and maintenance fat cheaper and faster.<p>That said, using a framework because other companies are using frameworks is definitely an unnecessary layer of complexity, and most websites don&#x27;t need to be using React or the like.<p>Regarding UIs and Designs: companies want their sites to look nice and so they hire designers who may or may not be trained to design for the web. Print design and web design are very different disciplines. You can end up with really strange and poorly performing sites when a design doesn&#x27;t match up with the reality of browser rendering.<p>Regarding sites that have huge payloads: this is almost always a product of management&#x2F;marketing input, and payloads end up ballooning when someone says &quot;can we just add an X pixel&quot; or &quot;can we try this one new piece of tracking software.&quot; Is the complexity there necessary? Probably not, but when multiple stakeholders have say, this is probably going to happen.

My theory and personal opinion.<p>In the past, we didn&#x27;t have complex UIs, we did, but we dealt with them differently. For example, in the era of forms and limited Ajax, keeping the DOM synced with the state took a lot of work.<p>The complexity we see today results from different ideas of how to deal with that _synchronicity_.<p>Keep in mind that there&#x27;s no way to do it natively; the only way to do it is to manually keep the state in sync. The complexity we see today results from the abstractions people have created to accomplish that, e.g., jQuery, Sammy, Backbone, Knockout, Angular, Ember, React, Vue, Svelte, etc.<p>Enterprise and FAANG required optimizations for different reasons, scale, collaboration, distribution, etc. Programmers wanted to use paradigms to represent things and apply optimizations on the web, and JavaScript wasn&#x27;t enough. So, they created CoffeeScript, Flow, TypeScript, ReasonML, etc. These tools became popular in the FAANG, wrote posts about them, then people of all industries adopted them.<p>To use all these cool tools, people created bundlers—each with its configurations, patterns, and philosophies—gulp, Rollup, Webpack, etc.<p>At this point, the web skyrocketed in complexity from the days of HTML, CSS, and JavaScript when one of the complex tasks was to make rounded corners with images and cool layouts with tables. Of course, you can still build complex UI without these tools and use JavaScript alone, but you will end up abstracting your patterns and paradigms into reusable bits.<p>Additionally, some developers attempt to use as little JavaScript as possible; one great example of a complex UI trying that is <a href="https:&#x2F;&#x2F;sourcehut.org" rel="nofollow">https:&#x2F;&#x2F;sourcehut.org</a>.

It didn&#x27;t. It just moved to the web. User interaction Is lots of edge cases.

My conspiracy theory of choice is that all these big front end frameworks have been developed and heavily funded &amp; pushed by (primarily) Google and Facebook specifically to make it so people are forced to run client-side JavaScript to get even the most basic functionality in every website, this ensuring tracking and ad code can get delivered.

Alan Kay thinks the internet and TCP&#x2F;IP is awesome - but the web is horrible. He&#x27;s coming from the small-talk world where you have an incredibly powerful environment that&#x27;s self enclosed.<p>He sees the browser and javascript as a step back to technology that was developed in the 1970s.<p>The dom+javascript just isn&#x27;t as powerful and so every attempt to improve shows some defect that a good plurality doesn&#x27;t like and then they redo everything over again.<p>We&#x27;re basing everything on a language that was originally functional but was disguised as an OOP language because some executives thought JAVA was the next big thing. We&#x27;re forcing a document object model to be a human interface model.<p>We&#x27;re stuck in this local maxima of power and functionality and all these attempts won&#x27;t work because they&#x27;re incremental. We need a quantum leap about what we think the human interface of the internet should be - and it shouldn&#x27;t be the browser.

The Barrier (tm) has lowered substantially. Let&#x27;s be honest guys, it is really hard to hire an engineer whom understands the virtues of modern system, and how simply you can work out the most complex logic with it.<p>It is possible to make beautiful, simple frontend systems today using React and a handful of k8s microservices, just the man who does it is invisible. It is possible to keep integration cost practically free, but these men who keep it are sought with fire. It is possible to use our tools just how they were designed to be used, avoiding bad and worst patterns, but only few of us mastered our tools.<p>You just need to hire one engineer if you are not and engineer and you didn&#x27;t walk their shoes for decade and hope for the best of luck. The Javascript and React are not strict tools at all, so they will allow a lot of people to fool you into thinking they are too good.

NPM is the Instagram for developers. They produce mostly wrapper packages around standard APIs in order to get some fame. It would be much better if they teach people how to achieve basic stuff without already-baked-in APIs.<p>I&#x27;d assume that 80% of the available packages are completely unnecessary, i.e. &quot;I need to set a cookie ... let&#x27;s download this NPM package&quot; or &quot;I need to make two AJAX requests in order to fetch some JSON ... there are two more NPM packages&quot;<p>I&#x27;m writing happily spaghetti code, use PHP, SQLite, Vanilla JS, HTML5, server-send-events, cron jobs and bash scripts to create fast and useful web applications.<p>Last note from today: I saw a tutorial on YouTube how to auto-generate a .m3u playlist for a folder containing hundreds of MP3. It involved of course downloading NPM packages, create a NodeJS cli script etc.<p>My 3-second solution was this (built in tools coming with almost every OS)<p>#!&#x2F;bin&#x2F;bash ls -1 *.mp3 &gt; playlist.m3u

I&#x27;d say this is the result of huge investment bubble in IT companies, where nobody cared enough of efficiency of workforce.<p>Everybody seems to care of hardware efficiency, because it&#x27;s very measurable. For example, if CPU is overloaded, an extra virtual or dedicated machine costs a lot, or a daily script works 10 hours and may result in serious troubles -- everybody gets bothered.<p>But if you add complexity and devs must work a month instead of 1 week on a simple task -- this passes under the radar, because devs unlike CPUs are busy 100% time always. That projects start to take longer, probably gets attention, but many just considered hiring an extra guy.<p>This probably lead many to consider heavy and complex projects, like Airflow, worthy -- because the costs were not considered seriously, and apart them, the selling point (configuration with some clicks, and launching a task by a click), was in a favorable false dichotomy.

Most of the state of application used to live on the backend but now that has transition to the frontend. Dealing with the state of application is difficult because of edgecases and side effects, React can handle many different domains mobile, tv, and website. Of course development will be more complex with more target domains.

At first, only devils used JavaScript. Then jQuery&#x2F;AJAX&#x2F;Web2.0 made it permissible for it to be used for good. Then Apple killed Flash. Clients and employers still demanded fancy web sites that weren&#x27;t just hypertext and images. Browsers still only supported JavaScript. Node and npm enabled front-end devs to build and share. All the tiny problems that front-end devs used to deal with, like minor browser incompatibilities, were papered over with layers and layers of abstractions until they naturally ended up with frameworks like React&#x2F;Vue&#x2F;Angular. Then the cart came before the horse, and there has only been incremental progress since then because JavaScript is still JavaScript, and the ecosystem is too big to escape.<p>Anyone who tries to avoid the complexity of the existing front-end tooling soon finds themselves reinventing many many wheels.

Most of it seems about resolving the tension between javascript, peoples opinions, the DOM, and the role of the server.<p>Also there&#x27;s the whole fractal of tool chains, transpilers, frameworks, libraries and design patterns that exploded out of people manipulating DOM strings to do something to a webform and feeling yucky about it.

I started my Web Dev career in 2005, around the time &quot;Web 2.0&quot; started to pickup steam. It was (In my recollection) really the beginning of the Web Application model. Users were starting to expect web pages to do more, and be more than &quot;click a link, go to another page&quot;<p>I&#x27;m certain any developer from that era has a story about writing tools to make their own life easier. Prototype and jQuery were popular as they abstracted a lot of the obnoxious stuff you had to do over and over again.<p>And the story goes on from there. The complexity is a story of trying to simplify for the developer, and then trying fix the costs of the overhead from those simplifications.<p>As for your second question. It&#x27;s not necessary of course, but if you don&#x27;t use these frameworks and tools, sooner or later (I think) you&#x27;re going to be engineering a solution yourself.

There are a lot of great answers here, I&#x27;ll just point out one thing that I think is important.<p>It feels like a lot of the complexity around frontend development comes from managing and maintaining state, particularly between different components. State management is easy when you just have a single JS script embedded in HTML. But when you decide you want a structure that is more class-like where you can reuse components, it&#x27;s suddenly incredibly difficult to share state between components and ensure changes (no matter the source) are propagated reliably and are also properly reflected in the DOM. You have this whole other layer in HTML that is awkwardly and haphazardly bound to the JS side which just makes things so much more complicated to the point where React makes its own DOM instead.

There are two reasons I can think of:<p>1. The most popular front-end frameworks (e.g. React and Angular) are created by large orgs which naturally leads to extensive codebases as they’ll need to have many use cases.<p>2. Every new and shiny front-end framework is good for job security since having it on a resume makes you more hireable. I suspect it’s also why some developers practically force startups to switch their front-end codebase to the next shiny framework - resume padding.<p>As a solo dev I wasted a few years using (and hating) these new frameworks for my Django projects because it’s what everyone was recommending.<p>Then it hit me when I realized that they were meant for large dedicated front-end teams to increase their productivity. If you’re a solo developer, they actually hurt your productivity.<p>That’s why I’m so happy with htmx. I can get my sanity back!

Because business cares about business and moves too fast to get it right or waste time on values, and by the time enough people might object the network effect or inertia or tech debt or whatever you want to call it has become The Way It’s Done and nobody can stop long enough to fix that.

Because the web distribution model for apps is extremely cost efficient. This has caused exponential growth in web app development. To support this, frontend frameworks have grown almost exponentially as well. Every corporate app is a webapp nowadays. This wasn&#x27;t the case 10 years ago. When we talk about web development, we are now not just talking about websites but about apps as well. So the industry has changed significantly.<p>UIs always have been complex btw. A lot of different states, and keeping backend and frontend in sync is hard too. So many edge cases need to be considered, orders of magnitude more than in the backend. The UI is also your first line of defense against unexpected user input.<p>Summarized: (1) app distribution has shifted to the web, (2) UIs are complex

From where the web started to now, the complexity makes sense. There were tons of browsers all implementing html, css, and javascript with their own quirks not to mention their own additions. For example, the father to all modern live websites, XMLHttpRequest is a Microsoft invention that was originally intended for Outlook web mail.<p>Honestly, it&#x27;s more of the speed of design that drove the complexity. Everyone had some specific niche that they picked up and due to the volume of demand for web development there was bound to be many different approaches tried.<p>Eventually, that&#x27;s going to mature down to a few different standards. That&#x27;s already happening with web browsers, for practical purposes we have three current browser engines today, down from who knows how many.

Anwering Q1: a number of reasons, the most important being: 1) programmers&#x27; immaturity, we&#x27;re always looking for new toys; 2) excess of venture capital fuelling too many new projects, opening space for new stuff to be used instead of the old, stable and boring ones; 3) product&#x2F;design people asking for increasingly insane UI frills, influenced by trends started by big tech&#x27;s products.<p>Q2: it depends. If you think of what users <i>need</i> and pay for, yes, it is HUGELY inflated; if you think of the actual requirements we receive, maybe it&#x27;s not that inflated -- at least part of this complexity is needed in order to build such truckload of eye candies.<p>It&#x27;s so disheartening to see such a gigantic waste of effort. But that&#x27;s the current state of our field.

I started a project in October. Spent part of November and through December building prototype frontends to decide which way to go - the whole next &#x2F; nuxt type debate, looked at svelte and Laravel. Finally came to the conclusion that since I was using Django for the backend anyway, there really wasn’t anything that couldn’t immediately be done just as well with Django templates. Sure, maybe at some point I’ll need to integrate some other frontend tools, but by that time I will have tested market fit and I will have customer feedback that tells me if I actually need something different for my UI. All of these front end frameworks add a ridiculous amount of complexity and <i>brittleness</i> for unclear advantage.

Shitty ducktape-y standards (most notably JS that was initially designed in 10 days). But it still became the standard for x-platform SaaS UIs: point your browser to a URL and go!<p>So a lot was demanded of these shitty standards (HTML, CSS and JS) and in oder to push them to the max a lot of &quot;frameworks&quot; emerged helping you with that. First jQuery, then Knockout, ..., React, ...<p>&gt; Is that complexity necessary or artificially inflated?<p>I&#x27;d say it&#x27;s organically inflated: no one did it on purpose. Every one tries to make it simpler.<p>I&#x27;m a big fan of Elm, which GREATLY reduces the complexity or browser apps... for me.<p>And still I prefer server-side-rendered if possible (or I have to manage the state on both ends, which also increases complexity).

Complexity in software typically comes from codebases made for multiple teams. When you have multiple teams, this is unsurprisingly a benefit. When you don&#x27;t, you typically get one team pretending to be many, and the needs of the other personas will be guessed, not known.<p>Web frontend work starts at a disadvantage because of the css&#x2F;html&#x2F;js divide. If you actually have distinct designers&#x2F;authors&#x2F;coders, it works as designed. If you have a small team, it doesn&#x27;t. To the typical disasters that we are all used to and have probably been responsible for.<p>The best symptom of this, to really demonstrate, is when you don&#x27;t know what tools a contributor needs other than a text editor.

Frontend development happens at the tail end of long pipeline of requirements gathering by product and design folks.<p>To meet the requirements foisted upon them, frontend devs tend to gravitate toward tools and frameworks that allow for maximum flexibility. And greater flexibility comes with greater complexity.<p>If you looped in frontend devs earlier in the requirements gathering phase, you might be able to (drastically) simplify a lot of the frontend work (e.g. &quot;if we design this UI flow slightly differently it will require way less development&quot;), but I understand this goes against most of the software development best practices which are currently en vogue.

Browser capabilities exploded dramatically as well as hardware, this is why we have Figma and virtual machines running in the browser. So the answer to this question seems obvious to me. It would be odd if UI complexity stayed the same.

I think the principal reason is the browser now has sufficient features, broadly deployed, that we swung back towards thick client architectures. So the frontend gets more complex because it’s doing more. It’s not the first time in the history of computers that this happened.<p>Personally, I’m a grumpy backend developer, I don’t like it. I’m doing a side project now where I’m trying out old school server side templates (Jinja2 in rust, compiled using Askama ) with a little JavaScript to make it so I can replace parts of the page via Ajax calls. It’s so light and so fast, I’m really enjoying it so far. Pretty much all the state is on the server.

Because browsers don&#x27;t support server-side declarative views natively yet. FE development wouldn&#x27;t even be a thing if web servers could respond with something like<p><pre><code> &lt;script&gt; const [count, setCount] = useState(0); &lt;&#x2F;script&gt; &lt;template id=&quot;counter&quot;&gt; &lt;div&gt; &lt;p&gt;You clicked {count} times&lt;&#x2F;p&gt; &lt;button onClick={() =&gt; setCount(count + 1)}&gt; Click me &lt;&#x2F;button&gt; &lt;&#x2F;div&gt; &lt;&#x2F;template&gt; &lt;counter&gt;&lt;&#x2F;counter&gt;</code></pre>

Too many different platforms to support which causes engineering issues.<p>For web, you need to support multiple browsers and infinite number of screen sizes.<p>For mobile, you need to support iOS and android and multiple different OS versions and screen sizes.<p>You also want to minimize platform-specific code, which often causes you to roll your own way of doing things. From an engineering point of view you don’t want your code based to diverge, which would cause supportability issues and&#x2F;or lengthen and complicate developing new features.<p>It’s basically a nightmare for any moderately successful company that doesn’t want to alienate any customers.

Frontend development has risen as an alternative so that it&#x27;s much easier to not program for native frontend system but instead hiring &quot;fullstack&quot; developers and or purely frontend developers. The complexity of these frameworks correspond with applications that are either web first and or electron based. The complexity is necessary in certain situations but at this time it is very artificially inflated because of the fact of ease of hiring and that most people and or frameworks that propagate by word of mouth or just following what others in the industry do.

There are a lot of salient points made in this thread, but one other aspect is that frontends are the end of a dependency chain, that is roughly like pipelines-&gt;databases-&gt;middleware-&gt;webservers-&gt;frontend. The tail end of such an architecture can be more easily change, because less depends on it, usually the only thing is the user&#x27;s eyeballs. In that situation, more variety proliferates because there aren&#x27;t as many constraints. Less constraints usually translates to a diversity of approaches, which is what we see in the frontend world.

Transpilation.<p>Imagine if TypeScript&#x2F;JSX was available native in the browser requiring no transpilation step, and we dropped support for any package requiring some exotic transpilation.<p>You could easily step through your entire codebase first and thirty-party without battling source-maps or minified files.<p>Libraries that required adding a compilation step and a complex dev server would be shunned. Having this compilation step in place means it&#x27;s easy to just pile on tons of functionality, import hooks, AST transformations, etc. which causes the complexity.

I think the natural evolution of programmers is to become more capable of building complex systems until you reach the realization that just because you can build it, doesn&#x27;t mean you should. You then think hard about how to build as simple system as possible. The front-end space hasn&#x27;t historically struck me as filled with a lot of grizzled systems programmers that have learned this lesson, so we get what we have today. Eventually they will learn and thinks will start becoming more minimal.

The shift from thin client to fat client forced the frontend to deal with greater state, sync and cache issues. The build ecosystem has multiple steps and langs. The visual fidelity and complexity of UI makes it difficult to test requiring us to deal with e2e testing with new tools.<p>All that to say this: we wanted cutting edge language features, beautiful UI and didnt want the page to flash white when we did something so we stopped switching pages and handled state on the front-end. Not sure it was all worth it tbh.

1. Browsers evolve but the JS ecosystem is competitive so instead of using the brain power to find a common solution to problems we end up with a grid of benchmark of frameworks about how fast it refreshes. I still see job description mentioning Redux while you don&#x27;t need it 99% of the time or even never.<p>2. Frontend dev is actually Blog&#x2F;Video&#x2F;Trend based development. Simpler tools exists but yeah.. I guess there is a market that feeds on this complexity.

In many cases it&#x27;s probably not necessary. There&#x27;s a lot of low hanging simplification fruit available in at least two areas:<p>• Internal&#x2F;enterprise apps. Instead of writing a full web app write a desktop app using one of the many new frameworks for it and connect directly to your database. Use views, row level security and other RDBMS features to implement declarative ACL logic, and stored procedures as a thin RPC layer when necessary. Benefits: eliminate the whole web tier, no SQL injection (users log into the db as themselves), no load balancers (client side can fail over between replicas), use non-JS languages over the whole stack without transpilation, give users ultra-low latency UI without lots of work, feed output of your SQL library direct to the UI toolkit, no browser compatibility bugs.<p>• Eliminate mobile&#x2F;web duplication. Use Jetpack Compose&#x2F;Kotlin Multiplatform&#x2F;Flutter&#x2F;etc to bring your mobile app to desktop and keep all the frontend codebases synced.<p>If we assume by frontend you mean exclusively web apps, complexity seems to have come from several places:<p>1. A desire to use something better than JS (typescript, coffeescript, kotlin, whatever).<p>2. HTML5&#x2F;JS&#x27;s failure to provide a components model leading to it being layered on top with npm, webpack, react, etc.<p>3. A desire to eliminate state-management related bugs via FP techniques.<p>4. A much wider recognition that latency is important, causing practices that were once routine to be now officially frowned upon and creating piles of complexity through optimizations.<p>5. Assumption&#x2F;desire that websites will work on mobile&#x2F;tablets, even if a native app exists, causing a lot of work for responsive design.<p>6. Lack of anyone other than Google incentivized to really improve the platform, causing an explosion of tiny GitHub projects that each seek to solve a micro-problem which then get cobbled together into ad-hoc per app &quot;frameworks&quot;. Compare to the Apple stack, the Microsoft stack, the Android stack, the Java standard library etc where a lot more stuff comes out of the box and they try to solve app development end to end.<p>The question of whether this complexity is necessary is always relative. Many apps have a captive user base who are much more sensitive to feature throughput than looks or how quickly the app loads. Things like server side rendering+rehydration are just a distraction there but they often come along for the ride due to the industries preference for using FAANG freeware over buying platforms that could then be more tuned for the customer need.

&quot;If all you have is a hammer, everything looks like a nail.&quot;<p>Frontend frameworks like React are used everywhere. For real web applications like Facebook, they totally make sense. But for a lot of other projects, they don&#x27;t because those projects do not have a complex UI&#x2F;UX and so the framework adds more complexity than needed.

I still do a mixture of jQuery and whatever I learned from modern JS. I totally missed the boat on everything else. I still render server sided, and rarely run into any issues.<p>I can simulate any kind of asynchronity with the server trough websockets or boring but effective polling.<p>It works for me, yet all job offers I see are looking for react or whatever Devs with rails experience. It&#x27;s like JavaScript totally took over.

I think the Frontend is mostly what gets promoted by Sales and Marketing when selling the product. The complexity results in trying to exactly meet what they request, or give them enough to talk about being new in the product. Performance improvements for the most part can only take up a few lines. New features, on the other hand, can take up countless pages if needed.

I think it is artificially inflated. The web took off to such a degree that that is where all the high paying jobs were. So people came over from other places and brought their complexity with them and imposed it on web development. The fact that you now have to have a build system to create a website is like something taken straight from application development.

It&#x27;s actually quite elementary and obvious if you have been in the market long enough: from websites it shifted to web apps, which have a different type of and higher complexity. Beside that, also the websites got more complex, as a wider range of people started to use them, as well as different types of devices, languages, purpose and so on.

I&#x27;d love a web based framework that worked as well as VB or Delphi worked 30 years ago. Is that really asking too much?

I&#x27;m not planning to join the &#x27;artificially bloated vs. necessary&#x27; debate, but<p>i think the web platform is a very open platform. Sure, there are highly complex toolchains for the web, but you are not obligated to use them. If you want to, you can use vanilla JS (if at all), raw WebGL and even Wasm.

Tech companies get a lot of subsidies (directly and indirectly) so they develop inefficient practices. When people don&#x27;t have profit and loss incentive, where incentive means they are not removed by the market due to losses, human psychology tend to favor bigger, complex things.

This might be a bit of a stretch but I believe native mobile apps is what triggered complexity in web apps. The bar was raised and users were expecting performance and experience equal or better than native mobile apps.

&gt; Follow up question : Is that complexity necessary or artifically inflated?<p>Is Javascript&#x27;s complexity necessary or artificially inflated? Modern frontend development boils down to a bunch of abstractions on top of Javascript.

A lot of complexity is coming from big corporations producing frameworks and methodologies optimized for huge (bloated) teams &#x2F; codebases.<p>The reality is that most teams in the world are not huge and never will be.

I don’t think react valued simplicity. It didn’t have an official store for years and still lacks CSS solutions out of the box but it seemed to be the only way to do components so people used it.

The main reason is easy “to plug and play” various tools, i.e react, websockets, graphql, webpack etc. That’s not related to frontend only, but kubernetes devops are also crying from complexity.

Unpopular opinion: Because people started thinking it&#x27;d be a good idea to treat the browser like an operating system instead of an ardent renderer of interlinked hypertext documents..

To summarize my experience, state is hard, phones got introduced as a target, and browser code became fun to write.<p>Is the complexity artificially inflated? It depends on the app you want to make.

Because many devs now specialize only in frontend and many succumbed into new ideologies of what is right - like using React and Webpack instead of seeking simplicity in design.

Developers are smart people who enjoy solving complex, interesting problems. If you give them a simple problem, very often they will find a way to make it interesting.

first v8 for speed then node.js - it allowed to do complex code generation stuff to happen on backend and on one side erase some incompatibility problems, on other to just do stuff that wouldn&#x27;t be possible if JS was <i>only</i> run on frontend.<p>We also got faster machines that could handle the buckets of garbage average JS framework asks browser to do and internet speed that made 2MB JS blob the norm and not something you&#x27;d be fired over.

I think the better question is why haven’t we made front end development toolkits less complex (by pushing a lot of the complexity into the browser itself)?

for most libraries, I think people in core teams cause it. eg react is destroying the potential of hooks more and more with each release. and it&#x27;s weird that no one of them said, &quot;what are we doing right now, does this stuff really have to be this complicated&quot;, but I guess that&#x27;s exactly what open source development culture is today. we know best and you should use it.

Has anyone else reached the point of annoyance where they feel that moving to egui + WASM makes more sense?<p>At least the app won&#x27;t be married to the browser.

My answer is market demand:<p>1. users demanding (whether unknowingly or not) better ui, quick updates<p>2. developers demanding “make it for me” tools<p>3. Companies “demanding” engineers to stand out

People realized they were being easily replaced by puppy mill dev bootcamps - skilled members of the market responded, the rest is history.

Because the people with the least experience choose what tech to use, or they get paid to use a specific tech.

IMO it&#x27;s because the bar has gone up, especially from customers.<p>10 years ago, your social app didn&#x27;t need to have sub-second response time worldwide while collecting literally everything about user journeys to drive engagement and serve ads, thwart DDoS via scraping or client-side crypto mining attempts, be compatible with mobile and desktop browsers, or be insanely visually appealing and deal with even bigger markup and stylesheet languages that, again, must seamlessly work on mobile and desktop. you didn&#x27;t really need to have a mobile app that communicates well with frontend.<p>Also, consumer internet bandwidth, disks, and computers are way faster and cheaper now in the US and Europe than it used to be (and even in developing countries with the proliferation of Starlink). we have facebook machines AND PHONES running m2&#x2F;a15 Apple Silicon that rivals workstation-class compute at a fraction of their CPUs TDPs. So customers will demand more because they can demand more.<p>Could we collectively just stayed frozen in 2013 or 2010 when life was simple and browsers weren&#x27;t operating systems? sure. but clearly the push for more things is working as every tech company is worth more than they used to be back then, even after accounting for today&#x27;s climate.<p>TL;DR: capitalism?

people expect complicated features

i think, in order:<p>1. the mainstream adoption of AJAX<p>2. node + node development community (top 5% of node&#x2F;npm contributors - also Google see 4.)<p>3. agencies trying to sell over-engineered BS to their clients<p>4. Chrome&#x2F;Google<p>5. influx of non-CS&#x2F;nerds into FED (commoditization of knowledge, process and perceptions.)

It feels to me like we are heading towards unifying our tools.<p>Look at Vite &amp; Rome for example.

Because http stateless And preserving state was not intended by design

Because it is often closer to actual business logic.

To sell new end user computer?

just use svelte for SPA XD it&#x27;s just like normal html with autoreactivity

because people didn&#x27;t learn properly how to build object oriented code with objects. instead they made up the excuse that it&#x27;s implicitly complicated when in reality they just aren&#x27;t very good at factoring

Failure to stop and consider how much of it can be pushed to the backend.

I think because of NodeJS. All modern toolings are built upon NodeJS.

XKCD 927 - Standards - <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>

I&#x27;m going to attempt to give some fact- &amp; data- based answers, as there seems to be too much ideological axe-grinding in (many of) the existing responses (as is, unfortunately typical on HN it seems, when discussing Front End Development). Even if my attempt seems...boring? (And sorry for the length; hopefully it makes up for that a bit in quality...?)<p>HN: &quot;Why did Frontend development explode in complexity?&quot;<p>Answers:<p>0) It&#x27;s not ONE thing--it&#x27;s a combination for forces&#x2F;trends&#x2F;factors...<p>1) The underlying technologies have become more complex (at least CSS and JavaScript have, but much less so w.r.t. HTML). For example: Flex layout, Grid layout, calc(), variables, etc., in CSS. Async&#x2F;await, destructuring assignment, import(), optional chaining, spread operator, yield, ...more in JavaScript.<p>2) Customers and Users &#x27;see&#x27; something that looks complex (whether inherently or accidentally), using Web technologies, so they are increasingly conditioned to expect that any application (regardless of complexity) can be build&#x2F;delivered using Web technologies. A few examples, off the top of my head: <a href="https:&#x2F;&#x2F;www.figma.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.figma.com&#x2F;</a> <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;</a> <a href="https:&#x2F;&#x2F;www.onshape.com&#x2F;en&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.onshape.com&#x2F;en&#x2F;</a><p>3) HTML is--egregiously--impoverished! Quick, when was that last time you saw a non-trivial LOB application (or even most CRUD applications) that did NOT need some sort of data-grid style presentation? Well, luckily we have the HTML5 data grid control for that...oh wait, F** me! And then there&#x27;s less common needs, like a &#x27;tree control&#x27;. Or more common needs like: a robust dialog control (with proper focus mgmt., etc.). To PROPERLY implement (documented, rigorously tested, styleable, i18n support, accessibility support, DOM attributess, JS API exposure, and on and on) just one of those is weeks, even months of work. Sure, if you&#x27;re only creating something for your own project, you can take short-cuts. But how much effort--and complexity--has been foisted, collectively, on Web application Developers, because the BROWSERS don&#x27;t have a complete control set??? Arguably, the HTML control set is not much richer (except in styling) than what one could do on a 327X terminal; which is 1960s-vintage technology!<p>HN &quot;Follow up question : Is that complexity necessary or artificially inflated?&quot;<p>3) Short answer: YES.<p>Long answer: as the technologies mature (whether the built-in troika of HTML&#x2F;CSS&#x2F;JS; or the add-on stacks), and as Developers become more experienced at delivering applications with &#x27;Web stacks&#x27;, what I&#x27;ve experienced is that some of the accidental complexity is decreasing. But certainly FOMO and RDD, and similar self-serving imperatives are a factor in having artificial complexity. For example now that &#x27;legacy&#x27; browsers are no longer a concern&#x2F;constraint for many projects, the complexity of Babel, and Webpack are often no longer needed. Or, at worst, can be replaced by more: modern, simpler, and generally performant tools.<p>Example: <a href="https:&#x2F;&#x2F;vitejs.dev&#x2F;guide&#x2F;why.html" rel="nofollow">https:&#x2F;&#x2F;vitejs.dev&#x2F;guide&#x2F;why.html</a><p>Also consider the madness which is the global namespace + cascade approach of CSS to selecting where&#x2F;how styles get applied. There are (? were) benefits to this approach when CSS was exclusively being used for a relatively small number of styles that needed to be applied, consistently, to a large number of pages (i.e., via a rel link to a SHARED stylesheet). But those days are LONG gone! There have been numerous attempts to address that madness, traditionally via naming conventions, for example: <a href="https:&#x2F;&#x2F;en.bem.info&#x2F;methodology&#x2F;naming-convention&#x2F;" rel="nofollow">https:&#x2F;&#x2F;en.bem.info&#x2F;methodology&#x2F;naming-convention&#x2F;</a> <a href="https:&#x2F;&#x2F;www.keycdn.com&#x2F;blog&#x2F;oocss" rel="nofollow">https:&#x2F;&#x2F;www.keycdn.com&#x2F;blog&#x2F;oocss</a><p>But those approches are (IMO) tedious; and experience has shown they are not scalable, on multiple axes (application complexity, project longevity, team size, experience level diversity).<p>So Developers added tooling, such as SaSS, to attempt to overcome the weaknesses of CSS for large&#x2F;complex projects. That&#x27;s been at least a partial success. BUT, at the cost of additional complexity in the tooling and build chain. Maybe even having to have an additional language run-time for some tooling like that!<p>Just having two &#x27;newish&#x27; features of CSS: variables, and the calc() operator can potentially reduce a lot of the traditional usage of things like SaSS. In some cases, the need for tools like that goes away completely! That&#x27;s a win, for reducing artifical complexity.<p>Another example is the strict scoping of style selectors in Vue&#x27;s single file components:<p><a href="https:&#x2F;&#x2F;vuejs.org&#x2F;api&#x2F;sfc-css-features.html#scoped-css" rel="nofollow">https:&#x2F;&#x2F;vuejs.org&#x2F;api&#x2F;sfc-css-features.html#scoped-css</a><p>Just that one feature alone, completely eliminates the traditional CSS madness, but without the weakness of the conventions (like BEM and O-OCSS), and with minimal (and pre-configured&#x2F;included) tooling.<p>CLOSING THOUGHTS: state management is still very complex; at least for non-trivial, and at least moderately interactive applications. In my experience (and I was designing, and implementing, complex GUIs _long_ before the Web was a thing), at least some of that state management is necessary (inherent), for those non-trivial &amp; interaqctive applications. The best we can do is to research and investigate, and try-out various approaches to minimizing the _accidental_ complexity that our state management approach&#x2F;library&#x2F;etc. adds to the inherent complexity.<p>I&#x27;m somewhat adverse to making recommndations on specific technologies, but I&#x27;d suggest that Developers who are contemplating a Web applicatiion with demanding state managment needs take a look at the following state managment library:<p><a href="https:&#x2F;&#x2F;tanstack.com&#x2F;query&#x2F;v4&#x2F;docs&#x2F;react&#x2F;overview" rel="nofollow">https:&#x2F;&#x2F;tanstack.com&#x2F;query&#x2F;v4&#x2F;docs&#x2F;react&#x2F;overview</a><p>Comment: it addresses a LOT of the pain points that many Web Developers&#x2F;Projects encounter. Moreover, I&#x27;ve had some very positive experience with the predecessor project to this one (i.e., React Query). N.B. If you&#x27;re going to be using: Vue, Svelte, or Solid.js (i.e., NOT React), then make sure to click on the drop-down menu in the UL corner of that page!

&gt; Is that complexity necessary or artificially inflated?<p>100% inflated and ego-based. How do I know? After years of struggling to understand the increasingly complex front-end space, I decided to build my own full-stack framework [1] to check my own opinions weren&#x27;t left-field.<p>Here&#x27;s the harsh truth: it doesn&#x27;t need to be as complex as it&#x27;s made out to be. Not even close. I can speculate as to why (ego, job security, etc) but ultimately the punchline is that all of the APIs and a lot of the code under the hood are pointless Rube Goldberg machines.<p>People don&#x27;t want to hear that because they&#x27;re invested emotionally in a lot of these tools, but from direct experience doing multi-year research and building of a framework, it&#x27;s all a scam.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick">https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick</a>