Why is modern web development so complicated? - <AUTHOR> https://www.vrk.dev/2019/07/11/why-is-modern-web-development-so-complicated-a-long-yet-hasty-explanation-part-1/ <comment><USER2> The answer to "why is ___ so ___?", is very nearly always best when phrased as the question, "what was supposed to stop __ from __?" The answer is nearly always...nothing.

There was nothing, technologically or organizationally, preventing web development from becoming so complicated, such that websites whose desired functionality would be satisfied by static html are now several meg of thousands of lines of javascript on top of a few dozen included libraries. There was nothing preventing that. Therefore, it happened.

Developers don't really feel like pointing out, "you should get rid of me and just pay for someone to do html". Managers don't really feel like pointing out "the project I'm managing doesn't really deserve a team of developers, you should take them away from me." The designers don't feel like pointing out "all we really need is to put this well-formatted text on a page with the company logo on the top and one or two image files, and that will communicate the information just fine, you can get rid of me." The even-higher-ups don't really feel like pointing out "I don't need to hire all these people, you can take this VC money and return it to the original investors". The VC's don't feel like pointing out, "there's not really a use for this much money in the tech world right now, so you can just stick it in a bank account and wait for a real need."

So, it doesn't happen, because there was nothing to prevent it.

<comment><USER3> I would add one word to this:

> There was nothing _anymore_ preventing web development from becoming so > complicated

The early web was much simpler because of the resource constraints of the 90s and early 2000s. Pages only started serving 10 MB of JS when browsers got to the point where they could chew through 10 MB of JS at a barely acceptable pace.

Also:

> Managers don't really feel like pointing out "the project I'm managing > doesn't really deserve a team of developers, you should take them away from > me."

As a techie watching corporate politics from the sideline, this was a particularly depressing insight. I used to wonder why big companies require 50 employees to do the work that small companies need 10 employees for. I do not wonder anymore.

<comment><USER4> Resources are allocated to their constraints. You spend as much money as you have, as much time as you have, you hire as many people as you can afford, and so on.

It may be because people don't think on an absolute time scale but rather a relative one; if you make 1 million in revenue and you only have 3 employees, you might feel like you should hire more. What happens if you start making one billion in revenue?

Read Bullshit Jobs by David Graeber if you haven't already.

<comment><USER5> Also known as "Parkinson's law".

Also the name of the little funny book where you will find the origin of "bikeshedding".

More pleasant and timelesd a book than "bullshit job", IMHO.

<comment><USER6> What's the full title of the book? I searched on Amazon and there are a few titles containing "Parkinson's Law". Thanks.

<comment><USER7> [https://www.amazon.co.uk/Parkinsons-Law-Pursuit-Progress- Bus...](https://www.amazon.co.uk/Parkinsons-Law-Pursuit-Progress- Business/dp/0140091076)

<comment><USER5> Yes that one indeed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Because it had to play catch up to native apps feature wise due to demand, while building upon a base that wasn't intended for that, while serving the same app to literally thousands of different environments and expecting it to work perfectly.

Thus, growing pains and overly complicated frameworks/plugins/other bits slapped together to address the core issues which ballooned the complexity. But we all knew that.

What's more impressive is that things are getting less complicated. Browser monoculture, while bad for the freedom of the web, is going to simplify things radically. Only having to target rolling releases for Firefox and Webkit? That's a dream from a cross-plat support side. Also javascript is actually pretty good now. Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build. I've been making static sites with them recently and it feels so much cleaner than going with a React or other component library approach that uses a vdom. The HTML is readable again, and there isn't any needed compilation step or crazy npm dependencies.

While it will never be as easy as it was back in the mosaic days, web dev is simplifying.

<comment><USER9> _" What's more impressive is that things are getting less complicated."_

Over what timeframe? While it certainly had its own issues, the HTML5/jQuery pairing easily fit into your head. Notwithstanding the benefits, React, packers, routers, and the 10 other things you bundle, is a cognitive load. Doesn't help that the routers and 10 other things don't come with React, and so, choices vary across teams.

<comment><USER10> The statefulness of jQuery is a massive cognitive load.

<comment><USER11> This is far from obvious and is almost never convincingly exemplified.

<comment><USER12> It should be totally obvious if you have written or tried to reason about a jQuery codebase that is larger than, say, one thousand lines of code, especially with multiple event listeners reading from and writing to the same pieces of state.

<comment><USER13> Having done this many times, my main takeaway is that storing state is what the DOM was designed to do and it's faster than a virtual DOM.

</comment></comment></comment></comment></comment></comment><comment><USER14> It doesn't have to be complicated, if you get support from above.

A few weeks ago I launched a new web site for a health care company. HTML, PHP, CSS, and MySQL. No frameworks. No javascript. No garbage.

It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on.

The company administrators, doctors, practitioners, etc... are so happy with the new no-nonsense site that they raved to the parent company about it. The parent company's IT department looked into the site, asked me some questions about it, and yesterday I was been asked to do the same type of cruft-free rebuild of three other sites that the company owns.

Not buying into the framework-of-the-day hype just landed me job security for the next two years.

<comment><USER15> Did you consider that the next developer might well come along and post a similar comment:

> It replaced a site that was pretty much a home-grown PHP framework written > by a single developer. Random mixed logic in templates, hard to update CSS > and a poorly designed 'not-an-ORM' ORM.

Not to say that your rewrite is like that, but one man's garbage is another man's treasure.

<comment><USER16> And here's the trick to not building shit software: don't build shit software. It's a crude way to put it, but the reality is that you can build bad websites in any framework (including old PHP stuff and new JavaScript hype). You can also build good websites in any framework.

It depends way more on the organisation or team developing it than on the libraries you use.

<comment><USER17> The trouble is that "don't build shit software" isn't actionable advice on how to avoid building shit software. For someone seeking to be a more skillful web software engineer, there's no information there.

<comment><USER18> This is fundamentally because our industry is built on opinions, not standards.

You talk to one software engineer, and they'll say, "that's built in PHP, so it sucks; it should have been built with npm, obviously." Then you talk to another and they say, "I can't believe they built that with npm, the package management system is just terrible and the whole mess is bloated and there have been a ton of security issues. They should have used a static generator instead." And on, and on, and on.

Now compare this to a mature industry with real engineers who are able to say things like, "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year."

That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Nobody's bothered to do that work. We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects.

This is absolutely shameful IMO, and the reason why I cringe a little inside whenever I see the words "software engineer".

<comment><USER19> Likely in that other industry the engineer built 100+ other basically identical items that are two or three orders of magnitude less complex and where all the costs and techniques are pretty well known.

Also, those mature industries routinely overrun by millions of dollars and months or years, event though they are dealing with a fraction of the complexity and the costs and techniques are well known.

Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries", on top of astronomically complex systems, and estimate it with an accuracy of 5 to 10 days and a few thousand dollars.

<comment><USER20> > Software is the only industry where you are asked to build systems that have > never been built before but that are more complex than anything ever built > in the history of "mature industries"

I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge.

<comment><USER21> > I have a feeling that some SpaceX engineers would have something to say > about this after one of their rockets lands on a floating barge.

That is because you are ignoring/left out the critical last part of the phrase you quoted: "and estimate it with an accuracy of 5 to 10 days and a few thousand dollars."

This is particularly relevant because this is a direct response to the following:

> We can't even accurately estimate the cost of a complex project given our > choice of tools, let alone talk about costs and ROI with different > toolchains for the same projects.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Because, Webpages have become complicated. Suddenly, you have all this interactivity going on, which you didn't have a decade ago. We went from a series of simple hyperlinked inter-connected webpages to all these popups shoving onto our face, useless fake computer bots pretending to be tech- support and finally big co. tracking every single click, every pixel of your mouse movement. The web has come a long way to support all these.

One of my clients was an airline. He asked if we could track the usage stats of his in-flight entertainment system (just stats, no PII). I thought about it and said yes. Even I was amazed I said because a decade ago it wouldn't be possible. I got it done with service workers (because flight wi-fi isn't a 100% always on connection).

It was a boon for me because I made a lot of money on that project and I needed the money. It's also a curse because every browser has all these invisible code running behind the scenes whether you want it to or not.

I miss those days where everything was just a bunch of tables and default system font-powered webpages with plain blue links. No CSS, no popups, just html and pure content.

<comment><USER23> > I miss those days where everything was just a bunch of tables and default > system font-powered webpages with plain blue links. No CSS, no popups, just > html and pure content.

You mean like HN? You 're not missing it. The old web never left. It's still here to catch all the misguided cloud walkers when they fall.

<comment><USER24> My thought exactly.The web is now a place to sell. That means you will have variations for all sorts of people.

</comment></comment></comment><comment><USER25> Webdev isn't complicated. Its actually pretty simple. Because its simple, you can use the extra time you saved to solve complicated problems. Which then brings it back up. When the platform makes THOSE problems simple, you just move on to solve other more complicated problems.

Basically, developers can support complexity <x>. No matter what you do to simplify it, you'll always push toward <x>, just getting more value out in the process. If you don't, your competitors will.

Also, even the most complex rollup/webpack/react/redux/styled- component/npm/blah/blah/blah setup has nothing on the kubernetes/kafka/databases/queues/whatever infrastructures of the world.

It just turns out that while your little pet project that cuts every corners to get something working has little on software development that requires everything to line up, be fast, reliable, comply with all the laws and regulations, and scale once your company grows and you suddenly have hundreds or thousands of people that need to work on the same stuff.

One thing to add: some people actually like setting stuff and optimizing infrastructure, build processes, setup, and pushing it to its limits. So development stacks quickly get optimized for a very common way to staff organizations: have a team that handles all the setup and infra, and a bunch of teams that build on top. So when you try to have 1 person or 1 team do everything, it feels like too much.

</comment><comment><USER26> Webdevs tend to suffer from an inferiority complex, that they are not considered "real" developers by the rest of the community. So they have responded by making the simple things they do monstrously complicated to try to prove something to the C++ guys, who simply don't care, until they try to use the dumpster fire that is any modern website, that is. Then it has the opposite of the intended effect!

Someone else mentioned SPAs. I 100% guarantee that no user in the world ever wished for their "back" button not to work as they expected.

Calling themselves "full stack engineers" is another symptom of this.

<comment><USER27> Who is considered a "real" developer these days?

<comment><USER28> The person who is writing their own game engine and doing everything from the ground up. They haven't shipped anything yet. They're five years into this with a few more to go.

<comment><USER29> With kickstarter campaigns and medium blog insights.

</comment></comment></comment></comment><comment><USER30> It's complicated because the bar in terms of user experience went up (or so they say) and now everyone wants a SPA. Because of this you now have a generation of devs that only knows how to build SPA. I'm actually thinking to move some stuff from Django to Gatsby/React setup just because everyone knows React, and a lot of our new devs don't know Django/Python.

<comment><USER31> "Everyone wants a SPA" is such bullshit. GitHub used to just load for a hundred milliseconds and then show me everything I needed; now it loads for a hundred milliseconds and shows me a spinner while it does another roundtrip for some javascript, then parses and executes that giant truckload of code, then does _another_ roundtrip to get the JSON or whatever describing the data I actually want to see, then executes its boatload of javascript to update the DOM. Reddit is the exact same story; in the time it used to take to show the content, it now manages to load a spinner. Facebook also just spends the first few hundred milliseconds loading loading indicators. YouTube too.

Browsers are awesome at rendering HTML. They render each element the instant just the necessary bytes have crossed the wire. Browsers can't help you if you need to first load the HTML, then load the scripts, then load the complete giant JSON blob from your API, then add the elements to the DOM.

I'm in Norway, with high ping to the US. My ISP isn't the most reliable all the time. That nice server you have 0.01ms ping to, where you can't notice the difference a few extra roundtrips makes? Well, each roundtrip might take an extra few seconds for me.

<comment><USER32> The worst example I can think of right now is: GMAIL..

God it went downhill lately. It can take 20 seconds on a decent machine for it to load all the shitty plugins i dont even need but still block me from using a mailbox..

Loading "html only" version is pretty much instant and has everything I need to use the demn mailbox..

<comment><USER33> Wow, I had this exact thought the other day. I loaded the page, and just sat there and watched this animation on the screen. "What is it doing" was all I could think. All I need it to do is load the subject line of the first however many emails in my inbox. It can't be that complicated.

</comment></comment></comment></comment><comment><USER34> I'm not blaming the tools, but too often, at least (for me) based on multiple interactions with various devs/engineers - yes, sometimes on Twitter :) - tools are proudly spoken of as a proxy for quality product. That is, I'm using the latest wiz-bam shiny new object tool so the users of the product must be overjoyed.

Nah. Nobody cares. I think that bears repeating...Nobody cares.

My mum has __never__ said to me "I love React" or "Isn't Bootstrap the best." But she __has__ complained to me about a site/app being buggy, confusing, difficult, etc. I've said the same to myself too many times to count. I think we all have.

A couple months ago, I read an article about (frontend) tools and how important X, Y and/or Z are. The author's product had a repo on GH. There were 700+ issues. All I could think was, "Apparently those tools have given his team a false sense of security. Looks like they've bitten over more than they can chew." I filed the article under: Just because you can, doesn't mean you should.

Years ago, I remember reading an answer on Quora (when Quora still mattered) that included:

"A fool with a tool is still a fool."

I don't think I'll even forget that line. It's so true. I'm not against tools. I'm just not in favor of those who claim tool X, Y or Z is a panacea.

<comment><USER35> You see that everywhere. In my field unless a dedicated statistican was a coauthor, chances are they picked the wrong test to use for significance. And if you look through their past papers you might find that they only use that one test that they always run, despite whether or not its relevant for their data.

In any field you can find people putting blind trust in tooling without knowing how the tool works or what its even intended for.

<comment><USER34> It's like anything else...

A solid idea well executed will beat a great idea poorly executed.

Sure, we all love to learn new things and/or push the envelope. That's what side projects are for. But when such things come at the expense of "the product" with a real user base than something as gone wrong.

"I love dealing with fast-moving things that are broken," said no user ever.

</comment></comment></comment><comment><USER36> Web development sucks precisely because we use a document markup language, a document styling language, and an interaction scripting language to build _applications_. It was bad enough when we just used this mess to make _user interfaces_.

If you've ever written or worked on a classical desktop application, you'll know what I mean. Since (at least) the 90s there have been visual UI builders and geometry management tools that allowed you to easily define a responsive user interface and connect widget events with calls to back end code. With the advent of CSS Grid and Flexbox, we finally have two decent geometry management tools--it only took 20 years. Except I can't use them yet, I have to support terrible old browsers (like IE7) that are embedded in customer applications.

We've been involved in reinventing a pretty, zero-config version of X-Windows, and we're only about 60% of the way done. How much further would we be if we didn't insist on building it in a hopped up word-processor?

<comment><USER37> I've been feeling this way for years. Web browsers were meant to show mostly static pages, not pages trying to dance around as full blown programs.

</comment></comment><comment><USER38> These "i hate debugging wandering pixels" and "i don't want to figure out why my css doesn't work" opinions sounds like they come from people who aren't really front end developers; like they come from the kind of dev who would sit and complain about the frontend devs on their company, thinking that they're a lower class of people.

I've been working on the server- and client-side of the web for about 10 years now, and I can't recall running into these "wandering pixel" issues they talk about in the past ~4 years.

Frontend development is not just about building a cute website for grandma anymore, and that's why it's complicated. We're passing more responsibilities to the browser, and we have to care about performance when doing work there, and that's why it's complicated. Writing performant software for an unknown machine is hard, and that's why it's complicated.

<comment><USER39> > they come from people who aren't really front end developers

I think web frontend development transitioned from "acceptably complicated" to "way too complicated" some time around that time the first person wrote "Front End Developer" on their business card.

<comment><USER38> Software Developer who mainly works in the frontend is too long. I do agree that calling yourself either backend or frontend is not great.

<comment><USER39> What I meant was, initially there were frontend designers and backend developers (because there was no code on the front end at all).

</comment></comment></comment></comment><comment><USER40> I think the default should be: Don't use any JavaScript if you don't have to. And if you have to, use it responsibly.

Recommended reading:

\- "Responsible JavaScript: Part I" by Jeremy Wagner ([https://alistapart.com/article/responsible-javascript- part-1...](https://alistapart.com/article/responsible-javascript-part-1/))

\- "A JavaScript-Free Frontend" by Matt Reyer ([https://dev.to/winduptoy/a-javascript-free- frontend-2d3e](https://dev.to/winduptoy/a-javascript-free-frontend-2d3e))

Disclaimer: I'm from Germany, but have a 6-y/o Android phone and live in a rural area with poor EDGE connectivity (~50kb/s). Most "modern" websites don't load/work for me.

<comment><USER41> javascript rules, and you can't build truly interactive sites without it (try to build a refine-as-you-type search bar with just html and css).

Here's my hot take: JS is good and has made the web better.

<comment><USER40> Here's my hot take: Instead of waiting 20s for your truly interactive site with refine-as-you-type search bar to load, which, when finally loaded, will lag so much on my mobile connection that it is just plain annoying, I will use your competitor's site which loads within 1s and has a plain old <input> field for search.

Not every site needs to be truly interactive. Not every site needs JS. Unless you're building a 3G+ or desktop-only web experience, use it responsibly.

<comment><USER42> And everytime I want to change anything at all or see updated data, I'll have to reload the page. JS has objectively made the web better.

</comment></comment></comment></comment><comment><USER43> Simple answer: Because the stupid hipsters try to change a simple concept of a state machine into MVC hell.

More complicated answer: The weak side of the open source world is that it attracts a lot of developers with big egos who think that their fancy solution to a situation without problems is the best one. And they all compete with their too big egos and complicate our open source world.

Real answer: too much memory, this causes people to come up with too complex systems as there is hardly a limit to their dreams, real inspiration comes from dealing with limits. That is why programs from yesteryear are often so good when looking at what they do within their constraints.

</comment><comment><USER44> I'll tell you why it's so complicated, but first let me update my 8,000 node_modules for my single page Hello World app

<comment><USER45> This is such a lame meme. A community built an entire distributable developer toolchain from the ground up, in a completely modular fashion, and then get lambasted for it existing on disk.

Or maybe non-JS developers are just upset that they had to wait for Docker to be invented to do it themselves.

</comment></comment><comment><USER46> I don't know, but I do know I would rather fix a race condition on a multithreaded application than figure out how flexbox works or even understand all the different parts of the DOM.

<comment><USER47> Heh. I kinda felt: "hey, I agree with that", so I started asking myself why. What's the difference? Somehow, it looks like the difference is that on one side you have a very complicated problem but in a potentially well defined and bounded environment, and on the other you may have "smaller" problems, but on an environment so vast and complex that's kinda impossible to assert that you are doing things "properly". There are so many parts always changing at the same time!

<comment><USER48> For me, having come from robotics/digital imaging/signal processing and now doing web dev, I feel exactly this. My old problems were far more technical, but I could always form a complete mental model of what was happening.

Now I feel like I have little hope. I'm under the foot of 117 leaky abstractions which all have their own opinion as to how things should work. It's near impossible to peek too deeply inside, so I just try shit until it works and then attempt to figure out why.

Some of my happier moments are when I get to add to one of our older sites that use server side generated pages. Even then though... not the same as debugging an errant pixel.

<comment><USER49> And the documentation is written by fanboys who are marketing it more than they are documenting it.

<comment><USER48> Yeah, it's really hit or miss. I enjoyed my 320 page manuals written by cynical, hardened, life-worn EE's.

</comment></comment></comment></comment></comment><comment><USER50> Web development is complicated because it is no longer web development. It's application development. And nontrivial applications are, by definition, complicated.

<comment><USER51> People forget that "front-end development" is just "client development" which isn't simple nor trivial on any platform.

</comment></comment><comment><USER52> I would argue that web development is less complicated than it used to be for the same quality of output. We now have source maps, debuggers, bundlers, more powerful languages, apis and a narrow range of browsers to hit with all that.

So now you can be more expressive, target more browsers easily, have greatly simplified script loading and module management, much, much better debugging tools, with less effort.

The tools make it easier for you to be a good developer.

Good web development was never easy.

</comment><comment><USER53> In my free time I try to create some desktop apps. It's my free time, so I decided not to spend time learning Qt or other older solutions for desktop apps and go with the Electron.

I'm too stupid for Electron, though. I wasted many hours trying to debug weird errors which I never know if are caused by Electron itself, bundlers, npm modules not compatible with it or anything else like division between main/renderer process. I just can't grasp it.

I ended up with separate node.js server which takes care of communicating with OS and standard web app with the simplest bundle setup I have found (because I don't understand webpack config, too): Parceljs. Frontend and backend exchange information using socket.io with copy-paste examples from their website.

I couldn't believe it CAN be so simple! Maybe it's not "true" desktop app (it just opens in user browser), but works exactly like I want.

</comment><comment><USER54> So... let me get this straight. You are making a website. You do need to load some changing data into it, so just a static site will not cut it. But we want to keep things simple. All we really need are a few AJAX calls and some DOM updates. And just like the author mentioned we don't want to write old clunky JS, we want to write beautiful ES6 code. So we install babel for ES6. And we install jQuery to do our AJAX and DOM stuff. Turns out that if we want to make AJAX calls to our API server, we cannot just load the file in the browser, it expects a server. We look briefly at installing nginx or apache and it seems like a lot of trouble. But we do discover webpack dev server. That's perfect. So we install webpack and configure the dev server. Since we are doing it, we might as well make it run babel for us. And while at it, we might as well do the bundling. Especially, since we would like to use a couple of other NPM modules. Nothing major, just convenience things. And since we are using the dev server anyway, we add hot-reload support. And a minifier, so we can have a minified production build.

So now we are using HTML, CSS, jQuery, babel, webpack, webpack dev server, webpack hot reload plugin, webpack plugins to load resources and a minifier. But hey, keep it simple, right?

<comment><USER55> So using your summary at which step did the engineer make the wrong choice?

<comment><USER56> At the point that they chose to use all this kit and write "beautiful ES6". Write ES5, use a few polyfill functions, include the already minified mithril/vue/react js IF you actually are going to need dynamic DOM elements. An XHR sweetener is included in mithril at least, but if not, it's only a few lines easily memorized, as you will do them constantly, it's also a good candidate for that library you should have made for all your projects by now, with that "byId()" and "byClass" shorteners etc... just an XHR you can pass a callback, url, and method to...

      var xhr = new XMLHttpRequest();
      xhr.onreadystatechange = function(){
        if(this.readyState == 4 && this.status == 200) {
          //do stuff to your dom, JSON.parse(return stuff) etc.
        }
      }

      xhr.open("POST", "/some route/" + whatever, true);
      xhr.send();

FormData(); would add 2 more lines to the above... I see no point in all this front-end toolchain stuff trying to maintain an illusion that ES6 runs in most browsers. Invariably maintaining false abstractions will not promote deeper understandings of the rather essential and basic "request response" cycle of HTTP.

It's not even pretty. Classes in JS? Gimme a break. Show me the ugly truth and K.I.S.S. because life is short and we have better things to do in life...

<comment><USER55> > _At the point that they chose to use all this kit and write "beautiful ES6"_

So are you saying that most projects that use JS should avoid the use of ES6?

<comment><USER56> Well, either that or polyfill. Transpiling to JS may be a product of other motives (Typescript, Svelte, Elm etc.)

While Ruby is pretty and all, I don't find that I'm enjoying the lie that is ES6, and don't even get me started on classes in JS, etc.

Bottom line, JS isn't my favorite language, but I'm not dying reading/writing ES5, (nor does ES6 look lovely when I know that it's lying to me) and the advantages outweigh the disadvantages...

I'm questioning a lot of the group-think decisions.

State management? What is "a variable"?

Many times the cure is worse than the disease...

<comment><USER55> > _Transpiling to JS may be a product of other motives (Typescript, Svelte, > Elm etc.)_

I'm not sure what you mean. Are you saying those tools should be avoided too or are you saying they are an exception to the "avoid complexity" rule?

> _While Ruby is pretty and all, I don 't find that I'm enjoying the lie that > is ES6, and don't even get me started on classes in JS, etc.

I don't understand what you mean. What does Ruby have to do with anything? Also, what do you mean by lie?

> _Bottom line, JS isn't my favorite language

Ok. That's fine. So what?

> _the advantages outweigh the disadvantages_

Would you care to elaborate on this? What would you consider to the be the advantages and what makes the complexity disadvantage outweigh them?

> _I 'm questioning a lot of the group-think decisions._

What is there to question? Don't use tools just because other people are using them, when you encounter a specific problem you want to solve, evaluate the available tools for solving it.

> _State management? What is "a variable"?_

I'm not sure what you're asking here. Are you asking why people use state managers when building js applications on the web?

</comment></comment></comment></comment></comment></comment><comment><USER57> Client-side JavaScript is sometimes a good idea, but it's absurd to think that all sites require it, and I think it's grossly overused. Most sites are mostly-static content. If your site is static, HTML and CSS are all you should be using. If it's mostly static, server-side implementations or minor JavaScript sprinklings on HTML and CSS are often simpler, cheaper, and much more maintainable. Server-side implementations tend to be much easier to use, and work just as well when your users disable JavaScript because they want more security and privacy. Accessibility is _possible_ with client-side JavaScript, but it's far cheaper & easier without it. Some sites can't be implemented server-side (or are sensible to do completely disconnected), and then you really do need the interactivity of full-on client-side JavaScript. In my experience, requiring full-on client-side JavaScript tends to be more complex and time-consuming to implement, and often tends to have serious loading time lag (with careful design it can be addressed, but often it never seems to get addressed).

Everything is a trade-off. The usual cause of excessive complexity is engineering based on the latest fad, instead of what is actually the best choice.

</comment><comment><USER58> Because web development usually means a stateful user interface these days, and most people are not very good at that (independent of language).

</comment><comment><USER59> It's becoming so complicated that I'm struggling to come up with ideas for how to get my 13 year old nephew interested in web development.

When he was born I used to dream of having him look at a button on a web page and him asking me "what actually happens when I click that button"

I shudder to think where I would even begin to answer that today.

<comment><USER60> Exactly this was one of the reasons why I built [https://flems.io](https://flems.io). Flems is basically just a scratchpad that begins with 3 files — .html, .css and .js. All the current state is stored in the URL, so sharing is simply done by sending the URL to someone else - true serverless ;) Here's a simple sample you can start out on with your nephew.

[https://flems.io/#0=N4IgzgpgNhDGAuEAmIBcIB0ALeBbKIANCAGYCWMY...](https://flems.io/#0=N4IgzgpgNhDGAuEAmIBcIB0ALeBbKIANCAGYCWMYaA2qAHYCGuEamO+RIsA9nYn6wA8AIwCu8eLwAEZJAF4AOiHhYIAIXGS6SgHwK6UqQGEoZWAGspzfYID0Yibx2dIMBGV5V0AJlQBOEABfQnomFnQMACsqYh4+CAF0FXVNXgxeWFMLKTkpAAoAShydKWB9Q2SNRzoMMHgATxgMeAAnBjowEm4W3BypAHIwWAYYPP6pAGopAFkGFQxcBgAPPIBGQnzZ+ba6JG5cQqkAKilVgAYCoqn+gv79QM4eXAAHCggW1mEGYWgXaDh4B4OqxVqgAOwAFiCIRAjGYrAwsDAMS4vH48E+3CQ9VK5SkSDIYGeUAY9VQUhIMCWAG48SMyABzOgAWjIiFwYHJsASiBatIMUkiojqZBI9WZcXRXJ5735hlUjJw5POZwAblh7vp9ABiSqpAxlAVfCwMlrcUS7clYbjwV50cxyqQ8KDdckAdywbIgjuE3SQ73JdF43vufzcgM8INBqyCAF1AkA)

nb. You don't need to jump in with any of the frameworks used by companies targeting millions of users. The basics are still there...

</comment></comment><comment><USER61> This is a wonderful and helpful article. A similar post that's really helped me is "What's in a Production Web Application?" by Stephen Mann: [https://stephenmann.io/post/whats-in-a-production-web- applic...](https://stephenmann.io/post/whats-in-a-production-web-application/)

The insane number of tools and processes was the motivator behind Hackterms ([https://www.hackterms.com](https://www.hackterms.com)) - the Urban Dictionary for programming terms, and a sort or modern Jargon File. We're now at ~1200 definitions and I reference it regularly.

<comment><USER62> Very timely. As a backend dev I'd not come across the 'SPA' acronym used in the comments here. I wasn't even going to bother searching for it because swirly water in tubs. Now I know.

</comment></comment><comment><USER63> Does all the hate have to do with sexiness?

To many people, backend and infrastructure work is sexy. They would happily get their hands dirty and spend insane amounts of time debugging mind-boggling issues as long as they happen server-side.

Frontend work on the other hand is not, it seems. Maybe that's because the biggest problem of high quality frontend development is to figure out how to deal with users (who most deveopers seem to abhor), and how to navigate the, say... complicated circumstances that are browsers.

Maybe building something that has to work in an environment you can't control is just a little too stressful for most devs?

Personally I really don't care. I love doing great architectural work, but in the end I'm all about expertise and I don't discriminate. If I have to step- debug inside webpack plugins or understand Safari CORS handling quirks, so be it. I'm a software engineer, but to me sexiness is in relentlessly looking for an edge, happy customers and signed contracts.

</comment><comment><USER64> The downside of using a code converter is that when something does break, the browser is going to show you the generated code and you have to map that back into your original code. If the generated code is ugly (hint: it's always ugly) then this can be a real problem.

The generators can also do things in really dumb ways that make it slow or resource intensive and you'll have no clue why your elegant solution is running like a dog unless you go through and read the horrible generated code to see what it is actually doing.

<comment> the-pigeon Source maps help a ton with this. Have never had an issue figuring out where the heck an exception came from when I've had source maps setup correctly.

</comment></comment><comment><USER65> As other comments here have said, in different ways:

"Modern web development" tries to reinvent too many wheels.

I wish more developers/directors would try to approach this from the other direction: Making _native_ OS apps as easily discoverable, installable, accessible, navigable, sharable, restorable, updatable and uninstallable, as websites:

• I want to be able to type "photo editor" and see Pixelmator on macOS, Paint.NET on Windows, Photoshop on both, and GIMP on Linux.

• When I choose an app it should open as fast as a website, loading incrementally, but remain available even after I'm offline (except for internet-dependent features) like other native apps.

• It should always launch the latest version, but should also allow me to "freeze" and locally archive a specific version.

• It should adopt the look, feel, and all the special features of the OS and device I'm currently using.

• I should be able to capture the UI state as a "link" and share it with other people, for example a specific page in the preferences window, or a particular workspace layout.

• It should remember my preferences across machines and OSes.

• After I have stopped using it for a while it should not take up any local storage on my machine.

We already have high-performant, energy-efficient UI toolkits and graphics and audio engines, we already have task switchers and various accessibility features, and we already have everything else that every web app is constantly trying to reinvent, each in its own half-baked way.

It's a constant shuffle of N steps forward, N+m steps back. _" Oh look! A cool new technology for native apps! But wait, let's take a very roundabout detour to reimplement this in a crippled imitation so that browsers can host it too."_

<comment><USER23> Sounds like it would be easier to enrich the browser with native-look controls than create another cross-platform ecosystem. (Let alone that none of the platform owners want to share developoers with the other platforms / they have incentive to lock them in)

<comment><USER66> Stop using these platforms.

</comment></comment></comment><comment><USER67> It's not complicated, you kids are just spoiled.

JavaScript I was paid to write in 1995 had a shelf life of 6 months given Netscape's release schedule and I had to compete on performance with Delphi 3 native compiled code.

If you think web development is too complicated these days, you should just dump it all and write cgi scripts in Perl again.

Or if you're an academic, Smalltalk + Seaside.

If there is a problem with modern web development, it is the curse of too much choice. Focus on your end goal, and the choices available will become a blessing, not a curse.

</comment><comment><USER68> To someone attempting to return to web dev after a break of a decade or so, my normal response is incredulity at the absolute horrorshow that's arisen. To me it's a complete towering, teetering mess of differing approaches, needlessly heavyweight frameworks, terrible decisions, and inefficiency. This is probably the ultimate cliched comment but I honestly cannot understand how any self- respecting developer can work with this xxxx and look themselves in the mirror.

<comment><USER23> I know it sounds unbelievable, but plenty of web developers ignore that whole show. It just doesn't seem the "upgrade" is worth it until something better comes along.

</comment></comment><comment><USER69> As someone who hasn't done much web development in the last 10 years, it is mind-boggling how much you need to know in order to be a full-stack engineer these days. I tried to start a project a few months ago and just trying to decide on a technology was difficult. Npm, Gulp, Grunt, Webpack, React vs Vue vs Angular...I don't even know what half of these tools even do, why they're needed, not to mention the learning curve to get up to speed.

<comment> non-entity I got really jaded along with a few other things and let my skills stagnate for a few years and now I'm looking at jobs and I'm unqualified for all the half decent ones. I'm personally trying to switch out of development, but I kinda wish I had made an effort to at least understand some of the new(ish) stucc

<comment><USER69> I feel your pain. This is one of the few industries that doesn't value experience. Unless you're spending all your time learning new technologies, it's really easy to become irrelevant.

</comment></comment></comment><comment><USER70> In the early 2000s Jakob Nielson popularised website usability through his books and his deceptively simple website useit.com. Big companies were paying him big bucks to have him simplify their websites much to the annoyance of the Java astronauts peddling n-tier jumbo sites. I often wonder what Nielson make of the insidious trend of using React & Angular for minimally dynamic websites.

</comment><comment><USER71> My thought is it has to be a product of the language. Javascript can be used imperatively, declaratively, procedurally, and functionally, so it is. That coupled with the fact that it's probably the most widely distributed interpreter so lots of people use it and ideas come out at a rapid clip. Then there are the vendor differences...

</comment><comment><USER72> Most of the hiring is geared towards what do you know instead of how do you solve problems.

I recently went to work a two big company, which is considered highly agile and progressive. I was tasked to build a pricing engine to customize prices for a static inventory of products. Number of products were about 30 and did not change month to month. The architecture suggested we use close to 18 different technologies, including caching systems, message bus, reactive programming. All to give 10 possible prices for 30 products. So essentially 300 values and a system to change the rules which determined the prices based on 3/4 parameters. I built the entire system in 2 days which was ready to be tested, but was told to scrap the work as it did not follow the internal development guidelines. Not to mention I was reprimanded for not including team and calling a complex problem trivial as it increased signaling risk internally. Apparently they are still building that system with 5 engineers, 2 analysts, 1 devops person, and 1 team lead. I left the company 2 years ago. And interestingly each and every person on the team got a promotion, multiple performance bonuses in last 2 years.

</comment><comment><USER73> Because a Web developer had $PROBLEMS problems, and he thought, "I know! I'll add an abstraction layer!" Now he, and the world, had $PROBLEMS + 1 problems. Repeat ad nauseam since the mid 90s.

Also, an application software vendor had A(m,n) problems and thought "What we need is to make the Web into a universal platform capable of supporting any application." Now they, and the world, had A(m+1, n+1) problems.

</comment><comment><USER74> > Why is modern web development so complicated?

Although lots of cool stuff is possible, I suspect that very often, it's about profiling and tracking users, and not about delivering content. That's certainly my experience as a user. I routinely browse sites that call resources from numerous sites, and want to run multiple scripts. And all they're ostensibly doing is displaying some text and images.

<comment><USER75> Ironically, many actions are drastically easier to track on the server side. Frontend pageview tracking is trivially knocked out by ad block. Backend pageview tracking is impossible to block.

<comment><USER74> True. But lots of third-party tracking is harder, right?

<comment><USER75> Wouldn't say that. With something like Segment it's easy to shovel data from the backend to any analytics provider you can think of. The majority of analytics providers have a REST api of some sort.

<comment><USER74> Sorry, I wasn't clear.

I meant that, without 3rd-party cookies, tracking is harder. And I'm assuming that users who block scripts also block 3rd-party cookies.

</comment></comment></comment></comment></comment><comment><USER76> I think part of the reason so many of this type of article exist is because it seems the common expectation is that things should automatically make sense to us on first glance. So many products and tools are this way. But they are that way by design. The builders / inventors of those things hide you from the reality behind the scenes. People seem to get openly frustrated if they can't learn overnight all there is to know about a discipline that has taken some people years and maybe even decades to master.

We as a civilization haven't really had a need to reconcile this I think on the scale that we do today. Nothing was "out in the open" so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it.

As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn't mean we should expect to be able to understand it.

Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.

</comment><comment><USER77> It's not that complicated. There are only like 20+ popular javascript (or Typescript, CoffeeScript, Dart, ...) frontend frameworks to choose from (Vuejs, React, Angular, ...) and their popularity changes over time. Several so called "native" solutions if you also want fast Mobile apps and HTML is not looking good enough (NativeScript, ReactNative or even Flutter). And there are like 10+ languages to choose for the backend development. And don't forget proper state management client-side to maintain single source of trust (Redux, RxJS, NgRx or Vuex)! Webapps are for teams of people nowadays. Frontend team and backend team. You need like 10 people to make modern SPAs properly, also with all the proper CSP, headers and caching settings. And you have to transpile the code to javascript after every change and 1.5 GB of JS dependencies and tools with web-based editor like VSCode. But all that is worth it because it's so interactive and modern. :)

</comment><comment><USER78> I like to read these things, because it feels so foreign to me. I started web dev around 2003 (stopped maybe 2010-2011), it involved a empty HTML file, perhaps only the few basic elements copied in, some hand crafted CSS, hand crafted JavaScript, a few ifs for Internet Explorers of the days, it was pretty manual, but one knew all the bits and pieces of the code.

Given how much I spent doing things this way, I'm quite reluctant to building JavaScript, let alone CSS (though preprocessing first came to CSS, if my mind serves me right). I find the write-test-update loop to be much tighter for frontend work, so I'm quite fond of the old ways of doing things (and all my side projects look the same way as they did back in the early 2000s), but I understand that modern build tools are getting more and more performant. Not as performant as "Save" though :-)

</comment><comment><USER79> It isn't. With modern frameworks (e.g. React + Typescript + some CSS framework), it is surprisingly straightforward to build the front ends for highly complex applications.

<comment><USER80> What does your react setup look like?

Do you use webpack? Just babel? What about grunt/gulp? How often do these things change? If you left your project for 12 months, would it still work?

<comment><USER79> Usually typescript, with webpack to reduce bundle size in production.

As with desktop programming, you have a variety of build systems to choose from, and as long as you use something reasonably same it is fine.

</comment></comment></comment><comment><USER23> I wonder what drove this needless and pretentious complexity ? The javascript ecosystem feels fragile and hacky, which spell bad prospects for its long term survival. It's more likely that jquery and PHP will survive after 2025 than any of the javascript tools mentioned in the article.

Was it the inflow of too many mediocre graduates that needed help preventing themselves from writing buggy programs? The social credits that people added to their CV for making yet another uber-popular javascript thingy that got a lot of github stars? Or was it bored engineers in the major web companies who have nothing to do because their advertising money cow is already being milked, so they decided to build toys to sabotage everyone else?

<comment><USER81> > I wonder what drove this needless and pretentious complexity ?

> Was it the inflow of too many mediocre graduates that needed help preventing > themselves from writing buggy programs?

IMHO? Pretty much. That end result is linked to the desire to democratize programming. That was a common talking point back in the 90s-00's. They wanted normal, non-programming people to be able to make websites by themselves without programmers. They wanted to be more inclusive and make programming more accessible to the masses. They thought one day programming would be taught in schools right next to english and they'd use that skill every day to program their computers themselves. The common phrase used was "programming is the new literacy."

They did not succeed. To make the programming tools and languages easier to use, they had to add complicated abstractions. Objects. Exceptions. Garbage Collection. Types had to go. As a result, programming got a lot easier to make simple things, but a whole hell of a lot more complicated to engineer solid, reliable systems.

A lot of the comments in this very comments section show a great deal of fear at not using a framework to program even a simple website. That's a great example of the kind of mindset we've cultivated over the past 30 years. We're so worried about how to utilize an ever growing pool of barely computer literate junior developers that we've Harrison Bergeron'd our best and brightest.

</comment></comment><comment><USER82> This is like a neanderthal saying that fire is hard to build so let's eat the food raw. The time is now old man. The new frameworks are surely confusing (not complicated) to learn at first but that is because they expect you to learn a system by which the chances of you delivering a bad product gets mitigated as the lowest level components follow an accepted standard. You are learning a system, a new tool to aid in your work rather than starting from scratch every time. And if you say you don't start from scratch and have a system/set of components to reuse then, voila, you are just doing the same thing frameworks do, but in your own sweet way.

</comment><comment><USER83> Anyone take the reasonable approach lately? IMO, it involves taking the CDN version of a framework such as VueJS and slapping that bad boy as a script tag in your HTML file. No webpack, babel, sass, etc etc.

I'm developing a dashboard, nothing fancy but nothing simple. I am also reasonable and think one can build off of all the well established UI components out there such as Vuetify. I now have a lot of free time to spend on the backend API, which is what I happen to enjoy doing.

As a fan of end to end or integration testing, I could care less about test driven development on the front-end.

<comment><USER84> That's only "reasonable" if you have a simple, cookie-cutter site.

<comment><USER83> Can you go into more detail? With Vuetify, I add my colors and generate a new theme. Hardly any new css is needed, especially with the grid systems that come with it. The compiled Vuejs gives proper errors in chrome developer tools, so it's been easy thus far.

</comment></comment></comment><comment><USER85> Modern web development is so complicated because we fantasize that a nodejs frontend and backend will make everything better. It's like my product is better because it has more integration.

I still stick with Ruby on Rails stack. It has a bunch of good practices and patterns built up over the years.

On the good side, I set up a static Jekyll site using Github Pages. It comes with SSL from letsencrypt. I got to run my website for free without much setup. I assume I don't have to worry about scaling it either. No server, no nginx, no SSL config. It's amazing!

</comment><comment><USER86> I think there should be a new razor, we can call it the Apple razor because Apple is the most common case. Basically, when tempted to ascribe the decisions of a successful entity to stupidity, consider that you may not be considering all the facts and facets.

Yes, web development is complicated. Yes, that complexity is at times completely unwarranted. __But __, that does not mean that the originators of this complexity were simply being stupid. A company like Facebook has a simple requirement: keep users on the site. If that means building a completely overengineered platform or inventing a totally new front end framework, sure, go for it! As long as it keeps the experience so smooth, so seductive that people scroll for hours, absorbing ads and producing money for Facebook.

I wouldn't be surprised if someone did some user testing and the SPA with no jarring refreshes and fluid page changes scored significantly higher on user engagement.

If you look at the companies that have really fancy JS libraries, they're generally places that rely on people using their apps continuously. Netflix? They're practically the poster child for internet addiction. Twitter? Yep. Even old school media companies like the New York Times are starting to use fancy web technologies. Clicks and eyeball time is money. Stuff like React and transpiling and webpack are small prices to pay if they keep your front end developers happy and your website nice and shiny for your average user.

<comment><USER23> Does facebook use react in its main, user-facing site? Does twitter ?

<comment><USER86> Yeah, totally. You can open React Devtools on Facebook and inspect it yourself. Twitter uses React for mobile and judging by their HTML, they might be server side rendering React for their desktop site too, since there's the hallmarks of React (react-root) and CSS in JS.

</comment></comment></comment><comment><USER87> Conversely, why are modern web apps so terrible? Take the Google GSuite Admin Console. This is what I called "Turn based administration" [throwback to the old turn based strategy games]. You start by loading the page and the 15mb of random javascript. Now click on something! Wait. ::Javascript stuff:: Incoherent error. Click Help. New documentation webapp loads 15mb of javascript to display some static text.

<comment><USER23> Hello, i am the popup from the button you clicked 57 clicks ago. i just arrived asynchonously and i m going to destroy your entire form. but don't worry, i will do a slide-hover-twist-and-twerk animation when entering

</comment></comment><comment><USER88> Modern Javascript is complicated*. Elm Lang on the other hand is great for web dev.

</comment><comment><USER89> I think part of the reason so many of this type of article exist is because it seems the common expectation is that things should automatically make sense to us on first glance. So many products and tools are this way. But they are that way by design. The builders / inventors of those things hide you from the reality behind the scenes.

People seem to get openly frustrated if they can't learn overnight all there is to know about a discipline that has taken some people years and maybe even decades to master.

We as a civilization haven't really had a need to reconcile this I think on the scale that we do today. Nothing was "out in the open" so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it.

As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn't mean we should expect to be able to understand it.

Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.

<comment><USER56> ... except that broken or ignored browser standards, and Javascript's lack of dealing with Timezone, for example, are not the result of complexity, per se, but of social inability: a committee or industrial consortium being unable to come to an agreement... kicking the can down the road in some cases, building- in complexity for ulterior motives in some cases by some parties, etc...

the web is a mess on the front end for political, rather than computer science, reasons

(say, you don't want to include the 2mb outdated moment.js? well, even though every browser included this code to fetch and update it's IANA timezone database in it's source, and has compiled against it, you can't access it via a public API from JS though LOL... you can figure out a way to run this code to get your data muahahahahahah.... [https://www.iana.org/time- zones](https://www.iana.org/time-zones))

</comment></comment><comment><USER90> I wrote about this very topic earlier this year: "It's 2019 and I Still Make Websites with my Bare Hands" [1].

There is a lot to be said for simple, time-proven technology.

[1]: [https://medium.com/@mattholt/its-2019-and-i-still-make- websi...](https://medium.com/@mattholt/its-2019-and-i-still-make-websites- with-my-bare-hands-73d4eec6b7)

</comment><comment><USER91> The bar just keeps moving higher. Right now making a website that looked good a decade a go is very easy, but the cutting edge is about responsive, highly interactive applications. Additionally they are constructed by teams of people, increasing the level of complexity because of the need to share code while staying dependency-free. Client applications have become increasingly complex for anything that isn't a trivial website that mostly displays information. Complexity management on the client side I think is its own paradigm that is often not given enough credit and then people get surprised why their UI grows increasingly fragile while taking days to implement seemingly simple features.

Ironically some of the tools in the article will probably grow old which is part of the difficulty here. People learn the libraries, then it seems a new, better library comes along and makes things even better. Everything comes together once you learn it's about managing the algorithms, data, as well as rendering to the screen.

</comment><comment><USER92> I think a lot of programmers forget the purpose of programming is for an end result. Instead, they focus on ever more complexity to feel superior to their peers. "Look what I can do" attitude. This reminds me of the Nasa space pen, when Nasa spent a million to develop a space pen and the Russians just used a pencil.

<comment><USER93> According to this[1] and many other articles, the NASA space pen story is just a myth.

1\. [https://www.scientificamerican.com/article/fact-or- fiction-n...](https://www.scientificamerican.com/article/fact-or-fiction-nasa- spen/)

</comment></comment><comment><USER94> I think the structure of that post is a fitting portrayal of the structure of modern frontend development... And no, I am not one of those JavaScript naysayers. In fact, I started building my first Progressive Web App three years ago.

But what I feel quite frustrated about, is the pace at which tools become obsolete. It seems that you can be happy if you have two projects which actually use the same set of tools. And every time you want to fix a bug in some project which you didn't touch for a few months, you run into some kind of trouble while updating the dependencies.

Just today, I spent an hour getting a project to build again, which I built two years ago. I just hope that in the near future the community will settle on a common set of tools which will become stable and stay for a decade or so.

</comment><comment><USER95> I'm not sure if it's that complicated. I feel like you can do so much more with less these days.

For personal projects, React on Rails (+ Redux) has been a very productive setup. Once you get over the learning hump of how to set up a project it's basically the same thing over and over again.

</comment><comment><USER5> Although the article is about web development for the actual web, there is also a lot of web development that's not for the public web but just because using the browser used to be a simple alternative to developing a native GUI, especially if you valued portability.

For my current project I needed a GUI that I initially planned to implement in the browser, but then I started to question this assumption that web development is simpler, and decided to try to refresh my C++ and use Qt instead.

So far it's not a disappointment.

I wrote a bit recently about that here, if you are interested and can bear poor English:

[https://rixed.github.io/ramen/blog/2019-07.html](https://rixed.github.io/ramen/blog/2019-07.html)

</comment><comment><USER96> This could be rephrased, "Why is kernel development so complicated?" or "Why is FPGA development so hard?"

In any given technical environment that has sufficient time to mature there will be more information to process, more choices, and more surface area. It's just the principle of intellectual entropy. Stuff tends to get larger and more complicated and specialized because it is.

If you want something simple, why not invent it? There's nothing stopping the next person from coming along and coming up with something that gets the same job done a lot easier than what we have now.

Of course, the first time you try to implement a tiny portion of a browser primitive like drawing a table you'll quickly see why things are complex.

</comment><comment><USER97> Simply put, the web and all it's related technologies move at a much more rapid pace than Java, C++, .NET etc.

We can complain about it all we want but if you drop out of this for a few years, good luck. I know tons of senior dev's who have no idea what modern tools to use. They don't understand modules, loaders, config files.

Trust me on this, the front-end guys like myself, hate the backend guys that come along and criticize everything they know nothing about. They also get in the way as they bumble and stumble over concepts UI guys already know. There is a huge distinction these days with backend and frontend web development. Each should avoid criticizing the other.

<comment><USER98> us backend guys come from a time when buttons worked when you clicked on them. It's a concept we are adamant to share with you new front-end folks :)

</comment></comment><comment><USER99> Well..no one has to switch to React/Vue/etc. You can still deliver well- behaved websites using plain HTML5 (CSS3 + jQuery), without all the bloat taken thanks to npm/yarn. You can try to use SaSS or LeSS, to make your CSS files look neat and avoiding to DRY, but all the rest is pure bloat.

To all the people saying that you want a native-app look, then go for the native way. The web-apps will _NEVER_ be as fast as the native ones, just because, the native ones will be faster and faster as the hardware specs are going up. I personally hate to go through web-development, even if it's a desktop client: stop wrapping around web views.

</comment><comment> amiga-workbench Because web developers have massive a chip on their shoulder about not being """real""" developers.

So now we have meme frameworks and transpilers and hysterical build toolchains all for a platform for sharing documents.

<comment><USER100> I disagree with the first part (they are real developers!), but agree with the second. We have grafted an application platform on top of a document delivery platform.

<comment> amiga-workbench I should probably rephrase that part, because yes you are right, they are real developers. But there is this misunderstanding that what they do is simple and it couldn't be further from the truth.

So off they go and try to prove that perception wrong by piling on the complexity.

<comment><USER101> I don't think added complexity is a 'feature' us front end devs strive for. Instead, there are a lot of useful UX abstractions that are increasingly expected by users and are becoming extraordinarily tricky to roll on your own. Yeah there's tons of extra crap, but the 8000+ projects in most node_modules has become more or less the standard library for that projects developer. It's nuts, but JavaScript is the Wild West so it's what we deal with.

</comment></comment></comment></comment><comment><USER102> (shameless plug) Just for kicks I wrote the client side of [https://watch.ly/](https://watch.ly/) without any frameworks (but used less/ejs/express).

Also winricklabs.com

It's a nice breather after writing AngularJS for six years... I'm sure with the next complicated UI I'll use some big framework (Spring+Leaflet or Angular...)

However, I think the goal should be to reduce complexity and have your business/product be focused as possible.

Watch.ly is literally just live hit counters. The live part gets challenging at some scale. But the product is focused.

</comment><comment><USER103> Why? Because most programmers are lazy, arrogant, self-serving _children_.

Given the choice between learning the business – requiring lots of talking to users to understand what they do and why they do it, and then writing very plain uninteresting code that servers those business users' needs – or learning whizzy new CV-enhancing technologies and using them to invent excitingly complicated and interesting software problems so they can spend all their time solving those problem instead, which do you think the indolent bums are going to embrace?

</comment><comment><USER104> I've refocused on web development in a new job after six years of being mobile dev first. To me, the answer is that design and user expectation got more complicated. Look at what was considered a state of the art web page 10 years ago, and you'll find the UX wasn't nearly as nuanced as today. Combine that with polyfills and responsive design requirements and it's just as complicated as a native app, and look how big those things are.

</comment><comment><USER105> The modern web development also turned into app development to emulate functions that is on the desktop applications. That is what is bring ing the complicity to the web.

Rise of the SPA is great. However, I think unless there is a good reason for having a SPA such as hybrid mobile app development, then there is no point of using SPA.

Normal server side web page rendering with latest modern version of jQueryish/Zapeto should be just fine for the non app type of web development.

</comment><comment><USER106> The main reasons web development is complicated:

* Javascript has evolved from simple requirements e.g. flashy text to a full blown application environment, but there is relatively little base functionality included (e.g. compared to what you get in Java or C#) so people need to write those libs separately.

* The separate libraries above need to be included in your code, and copy/paste is not maintainable so some kind of module system is needed but JS doesn't come with one, so various people rolled their own and they competed for mindshare. 10 different standards.

* As above for UI frameworks. JS only has a basic framework included: the DOM. It's pretty good but doesn't scale "naked" to more complex apps, so again the community creates a whole bunch of those.

* As above for application frameworks (UX frameworks)? such as routers so that you can press the back button.

* Ah the back button - an example of where apps on the web have to care about something that desktop apps don't. There are other examples. Mixing http/https. Mobile responsive.

* CSS - I imagine originally designed for "documents" \- now has to work well with "web apps".

* Javascript again - no static typing, many devs find it too easy to make mistakes, we have Typescript and other compile to JS languages.

* Because of the above complexity with have Babel, Browserify, Webpack etc. (one is never enough!)

* Then some genius decides to use JS for the back end and we have Node, NPM, and then because Node is so useful it becomes the front-end tool chain provider. So you use NPM to install Webpack, and the newbie has to figure out difference between dev dependencies and ordinary ones etc.

* git clone [https://github.com/..](https://github.com/..). and who knows what stack they've used. Oh they are using Browserify. Never used that. 2 hours reading the docs.

* Each framework then finds ways to get more complex organically. React, Redux etc. and all that.

* Again every other programmer is using 10^10 different combinations of frameworks and techs. Compare to C# Desktop development where it might be they are using Winforms or WPF - that's your only problem!

I could go on. I still copy and paste my favorite templates for getting started with NPM/Webpack/Typescript. Not sure I could demo how to get there from scratch again. All the recommended ones online seem to have beartraps in them and stuff I don't understand.

But remember you all you need is a <script></script>! It's easy!

</comment><comment><USER107> Awesome! I had quite the experience setting up a react app workflow with a friend. If you don't get your versions of tools to all line up or you use a tool which is slightly unconventional, or sometimes if you're developing on not-Mac, things can go very wrong very quickly. Nice to have a post overviewing how to pick and choose (and why you shouldn't do that anyways).

</comment><comment><USER108> In 2012 you were building sites and even applications with a stagnant language (JavaScript) that lacked any module/bundling support while having to support multiple browsers with differing standards. Routing, state management, dependency resolution, etc. were handled on an ad hoc basis if at all.

The current complexity is a result of addressing these issues and doing so at a rapid pace.

<comment><USER56> trying to shoehorn a synchronous model onto an asynchronous state machine, are we?

</comment></comment><comment><USER109> The problem is the enormous amount of choice we have:

\- React or Vue?

\- Redux or stateful components?

\- GraphQL or REST or RPC?

\- SSR or SPA?

\- ...

We are missing a framework with sensible defaults for all these questions. And that does a good job at explaining what decisions one should take.

I'm trying to build such framework: Reframe ([https://github.com/reframejs/reframe](https://github.com/reframejs/reframe)).

</comment><comment><USER110> I recommend looking at Phoenix LiveView. It's still early, but it's a revelation in terms of eliminating pointless, complex JS.

<comment><USER111> I like this, and it looks like a good fit for a lot of dashboard / data vis applications.

</comment></comment><comment><USER112> In summary, the OP concluded frontend design has gotten easier though abstracting browser compatibility (i.e. compiled javascript frameworks).

The software stack is a natural phenomenon that adds to web design's complexity. Ever changing and never complacent, it continues to shape new features that weren't conceivable in the past.

</comment><comment><USER113> It isn't. Unless _you_ make it complicated. Developers spend time making things complicated. And then more time complaining that things are complicated. Followed by even more time "solving" what is complicated by making it complicated in different ways. Repeat. Yawn.

</comment><comment><USER114> Because building and deployment are not straight forward. 10 years ago you could have some PHP script, some HTML templating... Upload the whole thing via FTP onto some LAMP hoster, and you could show it to people. And the hoster even had an MySQL database preinstalled if you needed it.

</comment><comment><USER115> It took me some time that the author is female named Victoria Kirst with 6 years at Google and 1 year teaching at Stanford CS193X [http://web.stanford.edu/class/cs193x/](http://web.stanford.edu/class/cs193x/)

</comment><comment><USER116> Because people have no time or incentive to make it simple. In fact, the incentive is to make it as complex as possible so you could charge more (and then charge more still for maintenance), and create a moat that "lesser" developers won't be able to cross.

</comment><comment><USER117> Among various reasons: \- Most people overcomplicate things, in general, not just in web dev. \- Not using the right tool for the job (I often run into sites displaying static content where they are using a bunch of frameworks and unnecessary code)

</comment><comment><USER118> AFAIK, any modern development is so complicated.

Setup a web server: * VM from Cloud provider * Installing a bunch of staff * Throwing in a k8s cluster * Service mesh * Yaml files * Various network configuration * DNS * Firewall * Security etc.

<comment><USER119> Alternatively: provision a Heroku dyno, add a single-line Procfile, git push heroku and you're done.

<comment><USER118> Let's not pretend that Heroku is that popular to swing the main stream steup.

</comment></comment></comment><comment><USER120> Because software engineers want "growth", and for most of them growth means learning/creating new technical things, and learning/creating technical things means more complexity.

There are other reasons, but that is a huge one.

</comment><comment><USER121> I always think it would be a huge success if somebody could deliver the same ease of development that VB and Access had for the desktop. There are some I have seen but they all are not as simple as VB and Access were.

</comment><comment><USER122> I have been saying the same thing for years: webpack, Babel, react, the million or so CSS edge cases per browser, and then that's just to get started.

I found backend development much saner to reason about.

</comment><comment><USER123> i was just thinking about this yesterday. The khan academy website became so complex in its layout. I think the old school web will make a comeback. Things are too complicated these days

</comment><comment><USER124> The more developers who work with an ecosystem the more complicated it gets. Therefore the most developer common job (Web Development) gets the most complicated ecosystem.

</comment><comment><USER125> Speculative answer: "because it's a technical solution to a social problem, and therefore can only mask the symptoms and not address the underlying cause of the problem."

</comment><comment><USER126> For somebody who just wants to pick up a useful programming language/set of languages these days - should I engage with modern web development or avoid it entirely?

</comment><comment><USER127> If you think learning react and setting up a webpack build is complicated, I recommend you to stay away from modern backend development.

</comment><comment><USER128> well, programming is hard. It has always been hard. regardless of the field. classic web development is complicated as well.

<comment><USER129> Programming isn't hard or easy. Problems are hard or easy.

</comment></comment><comment><USER130> It's only as complicated as you wish to make it out to be. Make it simple by saying no to as much cruft as possible.

</comment><comment><USER131> It's not the tools, it's the 'Full Stack' title. If you want to be a 10x employee, be a full stack architect you need to know all of it.

You simply cannot be a monolithic craftsman, who wields only a few tools well. Because if you do that, in 10 years you'll be left in the dust complaining about ageism vs knowing new tooling

I'm not advocating this is a good thing, but its the environment we have fostered for ourselves and now we don't like it.

</comment><comment><USER132> Because people would use bloated libraries instead of using the built-in stuff like `document` and `window`.

</comment><comment><USER133> Good, let's keep it that way!

</comment><comment><USER134> Where's your newsletter signup so I can be notified when part 2 is released?

</comment><comment><USER135> > Why is modern web development so complicated?

All the tools that are meant to simplify it.

</comment><comment><USER136> Why has no-one made a tool that worked like Flash.

I get that the flash plugin sucked and was a battery hog.

But the development environment was quite decent. I'd love to be able to make HTML5 content in the same kind of way.

<comment><USER137> The problem with that, is that flash even as an IDE was not really suited our new responsive web. Its not really good for content or development of anything other than games, animations and ads.

<comment><USER138> Did you ever develop with Flex? MXML and CSS + ActionScript was a great way to design webapps, and if phones actually ran flash, apps and components could be just as responsive as anything modern. The closest JS ever got to it was Angular 1, but then the Angular folks changed course and whatever version it's at now is very different.

My current favorite is the ClojureScript ecosystem, but it's even more different than either still, and really only suited for apps. For a plain old website composed of several pages, mostly static content, it's hard to beat plain old HTML with maybe a light sprinkle of JS for a couple things.

<comment><USER137> Actually I must admit that I never really gave flex a chance. Don't get me wrong, I miss the flash days as well, its actually kind of sad that open source player / recompiler projects never really got anywhere.

</comment></comment></comment></comment><comment><USER139> Because people with degrees brought their backend complication to the frontend when they realized they could only get money as a web developer. Now we're all fucked.

</comment><comment><USER140> nice article; I don't really find it that complicated, only extremely useful.. In fact without it i would be quite the sad panda especially as I'm still required to support IE11 for foreseeable future in many large apps. But ya, if you don't need it don't use it. I'm sure as heck glad all the tooling I have now exists though!

</comment><comment><USER141> Why is modern web development so complicated? Because of fucking JavaScript and shitty front-end frameworks. The end.

</comment><comment><USER142> Because "innovation"

</comment><comment><USER143> Damn I miss Visual Basic.

</comment><comment><USER144> django, heroku, bootstrap and javascript libraries (but not frameworks)

easy

</comment><comment><USER145> <marquee> is all you need </marquee>

<comment><USER23> i think we need more native browser UIs like marquee. Look at AMP, it understands that but is impleemnted in JS.

</comment></comment><comment><USER146> Its complicated because people make it complicated. Instead of following trend bullshit and self-justifying tooling insanity start with the a solid foundation and build on it one tiny layer at a time.

This is a learning process. It isn't something a tool can magically do for you. If you think you can nail this in two hours or by dicking around with some tool you are lying to yourself. Don't worry, everybody with half a brain will see you for exactly what you are, so be honest with yourself that you probably aren't some software rockstar and learn to take the primitive dumb stuff very seriously.

If you are hoping a tool will magically do it for you then you will continue to suck. The web will continue to be a complicated mystery. You will probably continue to cry about how hard life is and people won't want to be around you.

At the most primitive the web is HTTP and HTML. Don't over think this. If you understand those you have the web. You don't even need URI. URI is an added convenience.

Next, build less shitty HTML. Any HTML no matter how ugly, inaccessible, presentation-oriented, user-agent centered, and otherwise broken is still a good start so long as it displays content to a web browser. The first goal of HTML is something that just works... somewhat. Improve on this. Learn to write better HTML and better content. Most people don't take HTML seriously, but this is really the most important part of building a good web experience.

Third, learn some presentation using CSS. This will take some practice. This takes some real practice. It isn't hard, and you can do really almost anything with CSS. Even still people FEAR the CSS.

Fourth, be a damn programmer and stop being afraid to read code. Learn to write JavaScript. Learn the concept of scope. Learn to really read code. A bunch of tooling and test automation isn't going to read the code for you, though many developers seem to think that is exactly what layers of unnecessary tools are for. Keep this very simple at first. Learn some basic events and then bail out. Don't immediately think you are some kind of architectural wizard, because you will fail. If you think a framework will solve this for you then continue to be mystified and confused.

Fifth, learn the DOM. The DOM is the heartbeat, or assembly language, of the client-side application experience of the web. The DOM is what binds HTML to the browser and CSS/JavaScript to HTML. Without the DOM you have a plain text experience with really bad presentation that you shouldn't be using. Frameworks won't teach you this. The best way to learn the DOM, how it really works, is to learn XML Schema. I strongly suggest this even if you never use XML or schemas ever again.

Build on that. Baby steps. It takes some effort but it isn't complicated.

</comment><comment><USER147> I actually wrote a thingo on this recently. Modern front end has essentially the exact same challenges as a server which provides its API with sockets/websockets/events.

A back end server with this configuration would have a handler layer for IO, business logic layer and data layer.

DI and IoC ensures that the IO layer doesn't know about the data layer as the logic layer takes it as a dependency. The IO layer consumes the logic layer and the logic layer doesn't care/know about that.

Front end is _exactly_ like this. The data source is REST rather than a database. The UI layer is an event source and consumer. The logic layer notifies its consumers (the UI layer) that there has been a change. The rendering library doesn't matter, it's just a mechanism to represent the events it consumes.

The problem in front end is there has been no rational mechanism for DI in the libraries. React relied on the service locator pattern to deliver dependencies so to ensure quality decoupling you would need to have wrapped your components with a million functions.

``` withTheme(withUsers(withSomethingElse(withAnotherThing(Component)) ```

So rather than that, just use a single "service", redux, and forget about DI. Everything can do anything and all your logic is done inside that one thing.

Angular is no better. While they have a nice DI solution, it still relies on concrete implementations rather than abstractions. So your business logic must live within "angular services" and can not simply be "javascript" consumed by a rendering library.

Vue just missed the point entirely.

React context packaged this problem in an ergonomic box and, in my opinion, is a fantastic solution given the constraints. However at this point, the meta in front end programming is so irrational that it boggles my mind.

In the following example, you can see that I have an application which uses React as a renderer. React consumes a package from /platform. The package has no relationship to the presentational layer.

I could run the units in the package inside node or the browser console and it wouldn't care about its rendering library. The "PostStore" class exposes an API which consists of a getter and a stream. React consumes the stream, because it needs to be notified on changes.

[https://stackblitz.com/edit/react-ts- biohay?file=gui%2Fapp.t...](https://stackblitz.com/edit/react-ts- biohay?file=gui%2Fapp.tsx)

Conversely, this loose coupling means that the view renderer is a small portion of the application. I could swap it out for another renderer. Preact, Svelte, whatever.

Front end is a mess.

</comment><comment><USER148> It's complicated because nobody knows how to fix it. There's no formal definition for a "good design" or a "better design", so people keep iterating over the designs not knowing whether the new design is actually better or worse.

If there was a way to quantify a good design vs a bad design through an algorithm then people can iterate in ways that properly and categorically makes things better rather than in ways that are opinionated, vague and possibly even in the wrong direction.

</comment><comment><USER149> It is corporate politics.

Modern web development is _not_ about making things more efficient or easier to do.

It is about proving you have a job title or knowledge that makes you more hire-able, raise-worthy, title-superior than Junior Devs.

Web dev is actually easy if you want it to be, avoid the hype and use simple tools that work out of the box.

</comment><comment><USER150> Because dumbass java programmers are migrating to js and are bringing their shit to the web.

</comment><comment><USER151> Because we're no longer making websites, we're making apps. Sure if you just need a simple website, make it from scratch, but good luck maintaining a full blown app using jQuery.

It's not just web development that is hard. You can't honestly say any toolchain on the desktop side is any easier.

That said, web development is getting easier now that the dust is settling and only a few major frameworks are used.

Get started with create-react-app. React is the industry standard, use it.

1) Install NodeJS

2) npx create-react-app demo

<comment><USER152> I disagree with your ending note. I like React and have been using it professionally for over 2 years, but I wouldn't recommend anyone to use something just because it is an industry standard. At my work, for example, the upper management is now convinced that microservices are going to solve all of their current maintainability problems, while the fact is that there are a lot of employees that write shit code, who will also develop shit microservices.

<comment><USER151> My sole reason is to point new developers to the skills that nets them the most job opportunities. Learn the most popular (and imo the best) framework first.

People bitch about the web being too hard and too many choices. Then when you say to just use the most common stack, they bitch that you should choose X instead. Doesn't make any sense.

React also has the largest ecosystem, is the most flexible, and the most feature complete. (I can natively target nearly all mobile/desktop environments)</comment></comment></comment>