Why is modern web development so complicated?

The answer to &quot;why is ___ so ___?&quot;, is very nearly always best when phrased as the question, &quot;what was supposed to stop __ from __?&quot; The answer is nearly always...nothing.<p>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.<p>Developers don&#x27;t really feel like pointing out, &quot;you should get rid of me and just pay for someone to do html&quot;. Managers don&#x27;t really feel like pointing out &quot;the project I&#x27;m managing doesn&#x27;t really deserve a team of developers, you should take them away from me.&quot; The designers don&#x27;t feel like pointing out &quot;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.&quot; The even-higher-ups don&#x27;t really feel like pointing out &quot;I don&#x27;t need to hire all these people, you can take this VC money and return it to the original investors&quot;. The VC&#x27;s don&#x27;t feel like pointing out, &quot;there&#x27;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.&quot;<p>So, it doesn&#x27;t happen, because there was nothing to prevent it.

Because it had to play catch up to native apps feature wise due to demand, while building upon a base that wasn&#x27;t intended for that, while serving the same app to literally thousands of different environments and expecting it to work perfectly.<p>Thus, growing pains and overly complicated frameworks&#x2F;plugins&#x2F;other bits slapped together to address the core issues which ballooned the complexity. But we all knew that.<p>What&#x27;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&#x27;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&#x27;re actually quite easy to build. I&#x27;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&#x27;t any needed compilation step or crazy npm dependencies.<p>While it will never be as easy as it was back in the mosaic days, web dev is simplifying.

It doesn&#x27;t have to be complicated, if you get support from above.<p>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.<p>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.<p>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&#x27;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.<p>Not buying into the framework-of-the-day hype just landed me job security for the next two years.

Because, Webpages have become complicated. Suddenly, you have all this interactivity going on, which you didn&#x27;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.<p>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&#x27;t be possible. I got it done with service workers (because flight wi-fi isn&#x27;t a 100% always on connection).<p>It was a boon for me because I made a lot of money on that project and I needed the money. It&#x27;s also a curse because every browser has all these invisible code running behind the scenes whether you want it to or not.<p>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.

Webdev isn&#x27;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.<p>Basically, developers can support complexity &lt;x&gt;. No matter what you do to simplify it, you&#x27;ll always push toward &lt;x&gt;, just getting more value out in the process. If you don&#x27;t, your competitors will.<p>Also, even the most complex rollup&#x2F;webpack&#x2F;react&#x2F;redux&#x2F;styled-component&#x2F;npm&#x2F;blah&#x2F;blah&#x2F;blah setup has nothing on the kubernetes&#x2F;kafka&#x2F;databases&#x2F;queues&#x2F;whatever infrastructures of the world.<p>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.<p>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.

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!<p>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.<p>Calling themselves “full stack engineers” is another symptom of this.

It&#x27;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&#x27;m actually thinking to move some stuff from Django to Gatsby&#x2F;React setup just because everyone knows React, and a lot of our new devs don&#x27;t know Django&#x2F;Python.

I&#x27;m not blaming the tools, but too often, at least (for me) based on multiple interactions with various devs&#x2F;engineers - yes, sometimes on Twitter :) - tools are proudly spoken of as a proxy for quality product. That is, I&#x27;m using the latest wiz-bam shiny new object tool so the users of the product must be overjoyed.<p>Nah. Nobody cares. I think that bears repeating...Nobody cares.<p>My mum has __never__ said to me &quot;I love React&quot; or &quot;Isn&#x27;t Bootstrap the best.&quot; But she __has__ complained to me about a site&#x2F;app being buggy, confusing, difficult, etc. I&#x27;ve said the same to myself too many times to count. I think we all have.<p>A couple months ago, I read an article about (frontend) tools and how important X, Y and&#x2F;or Z are. The author&#x27;s product had a repo on GH. There were 700+ issues. All I could think was, &quot;Apparently those tools have given his team a false sense of security. Looks like they&#x27;ve bitten over more than they can chew.&quot; I filed the article under: Just because you can, doesn&#x27;t mean you should.<p>Years ago, I remember reading an answer on Quora (when Quora still mattered) that included:<p>&quot;A fool with a tool is still a fool.&quot;<p>I don&#x27;t think I&#x27;ll even forget that line. It&#x27;s so true. I&#x27;m not against tools. I&#x27;m just not in favor of those who claim tool X, Y or Z is a panacea.

Web development sucks precisely because we use a document markup language, a document styling language, and an interaction scripting language to build <i>applications</i>. It was bad enough when we just used this mess to make <i>user interfaces</i>.<p>If you&#x27;ve ever written or worked on a classical desktop application, you&#x27;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&#x27;t use them yet, I have to support terrible old browsers (like IE7) that are embedded in customer applications.<p>We&#x27;ve been involved in reinventing a pretty, zero-config version of X-Windows, and we&#x27;re only about 60% of the way done. How much further would we be if we didn&#x27;t insist on building it in a hopped up word-processor?

These &quot;i hate debugging wandering pixels&quot; and &quot;i don&#x27;t want to figure out why my css doesn&#x27;t work&quot; opinions sounds like they come from people who aren&#x27;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&#x27;re a lower class of people.<p>I&#x27;ve been working on the server- and client-side of the web for about 10 years now, and I can&#x27;t recall running into these &quot;wandering pixel&quot; issues they talk about in the past ~4 years.<p>Frontend development is not just about building a cute website for grandma anymore, and that&#x27;s why it&#x27;s complicated. We&#x27;re passing more responsibilities to the browser, and we have to care about performance when doing work there, and that&#x27;s why it&#x27;s complicated. Writing performant software for an unknown machine is hard, and that&#x27;s why it&#x27;s complicated.

I think the default should be: Don&#x27;t use any JavaScript if you don&#x27;t have to. And if you have to, use it responsibly.<p>Recommended reading:<p>- &quot;Responsible JavaScript: Part I&quot; by Jeremy Wagner (<a href="https:&#x2F;&#x2F;alistapart.com&#x2F;article&#x2F;responsible-javascript-part-1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;alistapart.com&#x2F;article&#x2F;responsible-javascript-part-1...</a>)<p>- &quot;A JavaScript-Free Frontend&quot; by Matt Reyer (<a href="https:&#x2F;&#x2F;dev.to&#x2F;winduptoy&#x2F;a-javascript-free-frontend-2d3e" rel="nofollow">https:&#x2F;&#x2F;dev.to&#x2F;winduptoy&#x2F;a-javascript-free-frontend-2d3e</a>)<p>Disclaimer: I&#x27;m from Germany, but have a 6-y&#x2F;o Android phone and live in a rural area with poor EDGE connectivity (~50kb&#x2F;s). Most &quot;modern&quot; websites don&#x27;t load&#x2F;work for me.

Simple answer: Because the stupid hipsters try to change a simple concept of a state machine into MVC hell.<p>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.<p>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.

I&#x27;ll tell you why it&#x27;s so complicated, but first let me update my 8,000 node_modules for my single page Hello World app

I don&#x27;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.

Web development is complicated because it is no longer web development. It&#x27;s application development. And nontrivial applications are, by definition, complicated.

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.<p>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.<p>The tools make it easier for you to be a good developer.<p>Good web development was never easy.

As other comments here have said, in different ways:<p>&quot;Modern web development&quot; tries to reinvent too many wheels.<p>I wish more developers&#x2F;directors would try to approach this from the other direction: Making <i>native</i> OS apps as easily discoverable, installable, accessible, navigable, sharable, restorable, updatable and uninstallable, as websites:<p>• I want to be able to type &quot;photo editor&quot; and see Pixelmator on macOS, Paint.NET on Windows, Photoshop on both, and GIMP on Linux.<p>• When I choose an app it should open as fast as a website, loading incrementally, but remain available even after I&#x27;m offline (except for internet-dependent features) like other native apps.<p>• It should always launch the latest version, but should also allow me to &quot;freeze&quot; and locally archive a specific version.<p>• It should adopt the look, feel, and all the special features of the OS and device I&#x27;m currently using.<p>• I should be able to capture the UI state as a &quot;link&quot; and share it with other people, for example a specific page in the preferences window, or a particular workspace layout.<p>• It should remember my preferences across machines and OSes.<p>• After I have stopped using it for a while it should not take up any local storage on my machine.<p>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.<p>It&#x27;s a constant shuffle of N steps forward, N+m steps back. <i>&quot;Oh look! A cool new technology for native apps! But wait, let&#x27;s take a very roundabout detour to reimplement this in a crippled imitation so that browsers can host it too.&quot;</i>

In my free time I try to create some desktop apps. It&#x27;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.<p>I&#x27;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&#x2F;renderer process. I just can&#x27;t grasp it.<p>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&#x27;t understand webpack config, too): Parceljs. Frontend and backend exchange information using socket.io with copy-paste examples from their website.<p>I couldn&#x27;t believe it CAN be so simple! Maybe it&#x27;s not &quot;true&quot; desktop app (it just opens in user browser), but works exactly like I want.

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&#x27;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&#x27;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.<p>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?

Client-side JavaScript is sometimes a good idea, but it&#x27;s absurd to think that all sites require it, and I think it&#x27;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&#x27;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 <i>possible</i> with client-side JavaScript, but it&#x27;s far cheaper &amp; easier without it. Some sites can&#x27;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).<p>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.

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

It&#x27;s becoming so complicated that I&#x27;m struggling to come up with ideas for how to get my 13 year old nephew interested in web development.<p>When he was born I used to dream of having him look at a button on a web page and him asking me &quot;what actually happens when I click that button&quot;<p>I shudder to think where I would even begin to answer that today.

This is a wonderful and helpful article. A similar post that&#x27;s really helped me is &quot;What&#x27;s in a Production Web Application?&quot; by Stephen Mann: <a href="https:&#x2F;&#x2F;stephenmann.io&#x2F;post&#x2F;whats-in-a-production-web-application&#x2F;" rel="nofollow">https:&#x2F;&#x2F;stephenmann.io&#x2F;post&#x2F;whats-in-a-production-web-applic...</a><p>The insane number of tools and processes was the motivator behind Hackterms (<a href="https:&#x2F;&#x2F;www.hackterms.com" rel="nofollow">https:&#x2F;&#x2F;www.hackterms.com</a>) - the Urban Dictionary for programming terms, and a sort or modern Jargon File. We&#x27;re now at ~1200 definitions and I reference it regularly.

Does all the hate have to do with sexiness?<p>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.<p>Frontend work on the other hand is not, it seems. Maybe that&#x27;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.<p>Maybe building something that has to work in an environment you can&#x27;t control is just a little too stressful for most devs?<p>Personally I really don&#x27;t care. I love doing great architectural work, but in the end I&#x27;m all about expertise and I don&#x27;t discriminate. If I have to step-debug inside webpack plugins or understand Safari CORS handling quirks, so be it. I&#x27;m a software engineer, but to me sexiness is in relentlessly looking for an edge, happy customers and signed contracts.

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&#x27;s always ugly) then this can be a real problem.<p>The generators can also do things in really dumb ways that make it slow or resource intensive and you&#x27;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.

It’s not complicated, you kids are just spoiled.<p>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.<p>If you think web development is too complicated these days, you should just dump it all and write cgi scripts in Perl again.<p>Or if you’re an academic, Smalltalk + Seaside.<p>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.

As someone who hasn&#x27;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&#x27;t even know what half of these tools even do, why they&#x27;re needed, not to mention the learning curve to get up to speed.

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&#x27;s more likely that jquery and PHP will survive after 2025 than any of the javascript tools mentioned in the article.<p>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?

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 &amp; Angular for minimally dynamic websites.

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...

Most of the hiring is geared towards what do you know instead of how do you solve problems.<p>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&#x2F;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.

Because a Web developer had $PROBLEMS problems, and he thought, &quot;I know! I&#x27;ll add an abstraction layer!&quot; Now he, and the world, had $PROBLEMS + 1 problems. Repeat ad nauseam since the mid 90s.<p>Also, an application software vendor had A(m,n) problems and thought &quot;What we need is to make the Web into a universal platform capable of supporting any application.&quot; Now they, and the world, had A(m+1, n+1) problems.

&gt; Why is modern web development so complicated?<p>Although lots of cool stuff is possible, I suspect that very often, it&#x27;s about profiling and tracking users, and not about delivering content. That&#x27;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&#x27;re ostensibly doing is displaying some text and images.

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 &#x2F; inventors of those things hide you from the reality behind the scenes. People seem to get openly frustrated if they can&#x27;t learn overnight all there is to know about a discipline that has taken some people years and maybe even decades to master.<p>We as a civilization haven&#x27;t really had a need to reconcile this I think on the scale that we do today. Nothing was &quot;out in the open&quot; so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it.<p>As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn&#x27;t mean we should expect to be able to understand it.<p>Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.

It&#x27;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 &quot;native&quot; 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&#x27;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&#x27;s so interactive and modern. :)

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.<p>Given how much I spent doing things this way, I&#x27;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&#x27;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 &quot;Save&quot; though :-)

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.

This is like a neanderthal saying that fire is hard to build so let&#x27;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&#x27;t start from scratch and have a system&#x2F;set of components to reuse then, voila, you are just doing the same thing frameworks do, but in your own sweet way.

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.<p>I&#x27;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.<p>As a fan of end to end or integration testing, I could care less about test driven development on the front-end.

Modern web development is so complicated because we fantasize that a nodejs frontend and backend will make everything better. It&#x27;s like my product is better because it has more integration.<p>I still stick with Ruby on Rails stack. It has a bunch of good practices and patterns built up over the years.<p>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&#x27;t have to worry about scaling it either. No server, no nginx, no SSL config. It&#x27;s amazing!

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.<p>Yes, web development is complicated. Yes, that complexity is at times completely unwarranted. <i></i>But<i></i>, 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.<p>I wouldn&#x27;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.<p>If you look at the companies that have really fancy JS libraries, they&#x27;re generally places that rely on people using their apps continuously. Netflix? They&#x27;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.

Conversely, why are modern web apps so terrible? Take the Google GSuite Admin Console. This is what I called &quot;Turn based administration&quot; [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.

Modern Javascript is complicated*. Elm Lang on the other hand is great for web dev.

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 &#x2F; inventors of those things hide you from the reality behind the scenes.<p>People seem to get openly frustrated if they can&#x27;t learn overnight all there is to know about a discipline that has taken some people years and maybe even decades to master.<p>We as a civilization haven&#x27;t really had a need to reconcile this I think on the scale that we do today. Nothing was &quot;out in the open&quot; so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it.<p>As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn&#x27;t mean we should expect to be able to understand it.<p>Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.

I wrote about this very topic earlier this year: &quot;It&#x27;s 2019 and I Still Make Websites with my Bare Hands&quot; [1].<p>There is a lot to be said for simple, time-proven technology.<p>[1]: <a href="https:&#x2F;&#x2F;medium.com&#x2F;@mattholt&#x2F;its-2019-and-i-still-make-websites-with-my-bare-hands-73d4eec6b7" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@mattholt&#x2F;its-2019-and-i-still-make-websi...</a>

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&#x27;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.<p>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&#x27;s about managing the algorithms, data, as well as rendering to the screen.

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. &quot;Look what I can do&quot; 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.

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.<p>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&#x27;t touch for a few months, you run into some kind of trouble while updating the dependencies.<p>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.

I&#x27;m not sure if it&#x27;s that complicated. I feel like you can do so much more with less these days.<p>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&#x27;s basically the same thing over and over again.

Although the article is about web development for the actual web, there is also a lot of web development that&#x27;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.<p>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.<p>So far it&#x27;s not a disappointment.<p>I wrote a bit recently about that here, if you are interested and can bear poor English:<p><a href="https:&#x2F;&#x2F;rixed.github.io&#x2F;ramen&#x2F;blog&#x2F;2019-07.html" rel="nofollow">https:&#x2F;&#x2F;rixed.github.io&#x2F;ramen&#x2F;blog&#x2F;2019-07.html</a>

This could be rephrased, &quot;Why is kernel development so complicated?&quot; or &quot;Why is FPGA development so hard?&quot;<p>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&#x27;s just the principle of intellectual entropy. Stuff tends to get larger and more complicated and specialized because it is.<p>If you want something simple, why not invent it? There&#x27;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.<p>Of course, the first time you try to implement a tiny portion of a browser primitive like drawing a table you&#x27;ll quickly see why things are complex.

Simply put, the web and all it&#x27;s related technologies move at a much more rapid pace than Java, C++, .NET etc.<p>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&#x27;s who have no idea what modern tools to use. They don&#x27;t understand modules, loaders, config files.<p>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.

Well..no one has to switch to React&#x2F;Vue&#x2F;etc. You can still deliver well-behaved websites using plain HTML5 (CSS3 + jQuery), without all the bloat taken thanks to npm&#x2F;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.<p>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&#x27;s a desktop client: stop wrapping around web views.

Because web developers have massive a chip on their shoulder about not being &quot;&quot;&quot;real&quot;&quot;&quot; developers.<p>So now we have meme frameworks and transpilers and hysterical build toolchains all for a platform for sharing documents.

(shameless plug) Just for kicks I wrote the client side of <a href="https:&#x2F;&#x2F;watch.ly&#x2F;" rel="nofollow">https:&#x2F;&#x2F;watch.ly&#x2F;</a> without any frameworks (but used less&#x2F;ejs&#x2F;express).<p>Also winricklabs.com<p>It&#x27;s a nice breather after writing AngularJS for six years... I&#x27;m sure with the next complicated UI I&#x27;ll use some big framework (Spring+Leaflet or Angular...)<p>However, I think the goal should be to reduce complexity and have your business&#x2F;product be focused as possible.<p>Watch.ly is literally just live hit counters. The live part gets challenging at some scale. But the product is focused.

Why? Because most programmers are lazy, arrogant, self-serving <i>children</i>.<p>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?

I&#x27;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&#x27;ll find the UX wasn&#x27;t nearly as nuanced as today. Combine that with polyfills and responsive design requirements and it&#x27;s just as complicated as a native app, and look how big those things are.

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.<p>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.<p>Normal server side web page rendering with latest modern version of jQueryish&#x2F;Zapeto should be just fine for the non app type of web development.

The main reasons web development is complicated:<p>* 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.<p>* The separate libraries above need to be included in your code, and copy&#x2F;paste is not maintainable so some kind of module system is needed but JS doesn&#x27;t come with one, so various people rolled their own and they competed for mindshare. 10 different standards.<p>* As above for UI frameworks. JS only has a basic framework included: the DOM. It&#x27;s pretty good but doesn&#x27;t scale &quot;naked&quot; to more complex apps, so again the community creates a whole bunch of those.<p>* As above for application frameworks (UX frameworks)? such as routers so that you can press the back button.<p>* Ah the back button - an example of where apps on the web have to care about something that desktop apps don&#x27;t. There are other examples. Mixing http&#x2F;https. Mobile responsive.<p>* CSS - I imagine originally designed for &quot;documents&quot; - now has to work well with &quot;web apps&quot;.<p>* Javascript again - no static typing, many devs find it too easy to make mistakes, we have Typescript and other compile to JS languages.<p>* Because of the above complexity with have Babel, Browserify, Webpack etc. (one is never enough!)<p>* 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.<p>* git clone <a href="https:&#x2F;&#x2F;github.com&#x2F;.." rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;..</a>. and who knows what stack they&#x27;ve used. Oh they are using Browserify. Never used that. 2 hours reading the docs.<p>* Each framework then finds ways to get more complex organically. React, Redux etc. and all that.<p>* 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&#x27;s your only problem!<p>I could go on. I still copy and paste my favorite templates for getting started with NPM&#x2F;Webpack&#x2F;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&#x27;t understand.<p>But remember you all you need is a &lt;script&gt;&lt;&#x2F;script&gt;! It&#x27;s easy!

Awesome! I had quite the experience setting up a react app workflow with a friend. If you don&#x27;t get your versions of tools to all line up or you use a tool which is slightly unconventional, or sometimes if you&#x27;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&#x27;t do that anyways).

In 2012 you were building sites and even applications with a stagnant language (JavaScript) that lacked any module&#x2F;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.<p>The current complexity is a result of addressing these issues and doing so at a rapid pace.

The problem is the enormous amount of choice we have:<p>- React or Vue?<p>- Redux or stateful components?<p>- GraphQL or REST or RPC?<p>- SSR or SPA?<p>- ...<p>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.<p>I&#x27;m trying to build such framework: Reframe (<a href="https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;reframe" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;reframe</a>).

I recommend looking at Phoenix LiveView. It’s still early, but it’s a revelation in terms of eliminating pointless, complex JS.

In summary, the OP concluded frontend design has gotten easier though abstracting browser compatibility (i.e. compiled javascript frameworks).<p>The software stack is a natural phenomenon that adds to web design&#x27;s complexity. Ever changing and never complacent, it continues to shape new features that weren&#x27;t conceivable in the past.

It isn&#x27;t. Unless <i>you</i> make it complicated. Developers spend time making things complicated. And then more time complaining that things are complicated. Followed by even more time &quot;solving&quot; what is complicated by making it complicated in different ways. Repeat. Yawn.

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.

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 <a href="http:&#x2F;&#x2F;web.stanford.edu&#x2F;class&#x2F;cs193x&#x2F;" rel="nofollow">http:&#x2F;&#x2F;web.stanford.edu&#x2F;class&#x2F;cs193x&#x2F;</a>

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)

AFAIK, any modern development is so complicated.<p>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.

Because software engineers want “growth”, and for most of them growth means learning&#x2F;creating new technical things, and learning&#x2F;creating technical things means more complexity.<p>There are other reasons, but that is a huge one.

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.

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.<p>I found backend development much saner to reason about.

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

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.

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.”

For somebody who just wants to pick up a useful programming language&#x2F;set of languages these days - should I engage with modern web development or avoid it entirely?

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

well, programming is hard. It has always been hard. regardless of the field. classic web development is complicated as well.

It&#x27;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.

It&#x27;s not the tools, it&#x27;s the &#x27;Full Stack&#x27; title. If you want to be a 10x employee, be a full stack architect you need to know all of it.<p>You simply cannot be a monolithic craftsman, who wields only a few tools well. Because if you do that, in 10 years you&#x27;ll be left in the dust complaining about ageism vs knowing new tooling<p>I&#x27;m not advocating this is a good thing, but its the environment we have fostered for ourselves and now we don&#x27;t like it.

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

Good, let&#x27;s keep it that way!

Where&#x27;s your newsletter signup so I can be notified when part 2 is released?

&gt; Why is modern web development so complicated?<p>All the tools that are meant to simplify it.

Why has no-one made a tool that worked like Flash.<p>I get that the flash plugin sucked and was a battery hog.<p>But the development environment was quite decent. I&#x27;d love to be able to make HTML5 content in the same kind of way.

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

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

Because &quot;innovation&quot;

Damn I miss Visual Basic.

django, heroku, bootstrap and javascript libraries (but not frameworks)<p>easy

&lt;marquee&gt; is all you need &lt;&#x2F;marquee&gt;

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.<p>This is a learning process. It isn&#x27;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&#x27;t worry, everybody with half a brain will see you for exactly what you are, so be honest with yourself that you probably aren&#x27;t some software rockstar and learn to take the primitive dumb stuff very seriously.<p>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&#x27;t want to be around you.<p>At the most primitive the web is HTTP and HTML. Don&#x27;t over think this. If you understand those you have the web. You don&#x27;t even need URI. URI is an added convenience.<p>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&#x27;t take HTML seriously, but this is really the most important part of building a good web experience.<p>Third, learn some presentation using CSS. This will take some practice. This takes some real practice. It isn&#x27;t hard, and you can do really almost anything with CSS. Even still people FEAR the CSS.<p>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&#x27;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&#x27;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.<p>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&#x2F;JavaScript to HTML. Without the DOM you have a plain text experience with really bad presentation that you shouldn&#x27;t be using. Frameworks won&#x27;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.<p>Build on that. Baby steps. It takes some effort but it isn&#x27;t complicated.

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&#x2F;websockets&#x2F;events.<p>A back end server with this configuration would have a handler layer for IO, business logic layer and data layer.<p>DI and IoC ensures that the IO layer doesn&#x27;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&#x27;t care&#x2F;know about that.<p>Front end is <i>exactly</i> 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&#x27;t matter, it&#x27;s just a mechanism to represent the events it consumes.<p>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.<p>``` withTheme(withUsers(withSomethingElse(withAnotherThing(Component)) ```<p>So rather than that, just use a single &quot;service&quot;, redux, and forget about DI. Everything can do anything and all your logic is done inside that one thing.<p>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 &quot;angular services&quot; and can not simply be &quot;javascript&quot; consumed by a rendering library.<p>Vue just missed the point entirely.<p>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.<p>In the following example, you can see that I have an application which uses React as a renderer. React consumes a package from &#x2F;platform. The package has no relationship to the presentational layer.<p>I could run the units in the package inside node or the browser console and it wouldn&#x27;t care about its rendering library. The &quot;PostStore&quot; class exposes an API which consists of a getter and a stream. React consumes the stream, because it needs to be notified on changes.<p><a href="https:&#x2F;&#x2F;stackblitz.com&#x2F;edit&#x2F;react-ts-biohay?file=gui%2Fapp.tsx" rel="nofollow">https:&#x2F;&#x2F;stackblitz.com&#x2F;edit&#x2F;react-ts-biohay?file=gui%2Fapp.t...</a><p>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.<p>Front end is a mess.

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&#x27;s arisen. To me it&#x27;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.

It&#x27;s complicated because nobody knows how to fix it. There&#x27;s no formal definition for a &quot;good design&quot; or a &quot;better design&quot;, so people keep iterating over the designs not knowing whether the new design is actually better or worse.<p>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.

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 &quot;lesser&quot; developers won&#x27;t be able to cross.

It is corporate politics.<p>Modern web development is <i>not</i> about making things more efficient or easier to do.<p>It is about proving you have a job title or knowledge that makes you more hire-able, raise-worthy, title-superior than Junior Devs.<p>Web dev is actually easy if you want it to be, avoid the hype and use simple tools that work out of the box.

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&#x27;re all fucked.

Because dumbass java programmers are migrating to js and are bringing their shit to the web.

Because we&#x27;re no longer making websites, we&#x27;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.<p>It&#x27;s not just web development that is hard. You can&#x27;t honestly say any toolchain on the desktop side is any easier.<p>That said, web development is getting easier now that the dust is settling and only a few major frameworks are used.<p>Get started with create-react-app. React is the industry standard, use it.<p>1) Install NodeJS<p>2) npx create-react-app demo