
Why is modern web development so complicated? - bibyte
https://www.vrk.dev/2019/07/11/why-is-modern-web-development-so-complicated-a-long-yet-hasty-explanation-part-1/
======
rossdavidh
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.

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

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

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

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

~~~
iherbig
[https://www.amazon.co.uk/Parkinsons-Law-Pursuit-Progress-
Bus...](https://www.amazon.co.uk/Parkinsons-Law-Pursuit-Progress-
Business/dp/0140091076)

~~~
rixed
Yes that one indeed.

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

~~~
tyingq
_" 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.

~~~
TurningCanadian
The statefulness of jQuery is a massive cognitive load.

~~~
The_rationalist
This is far from obvious and is almost never convincingly exemplified.

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

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

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

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

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

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

~~~
thaumaturgy
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".

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

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

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

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

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

~~~
vegiraghav
My thought exactly.The web is now a place to sell. That means you will have
variations for all sorts of people.

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

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

~~~
renke1
Who is considered a "real" developer these days?

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

~~~
wolco
With kickstarter campaigns and medium blog insights.

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

~~~
mort96
"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.

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

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

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

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

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

------
daotoad
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?

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

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

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

~~~
vcanales
Software Developer who mainly works in the frontend is too long. I do agree
that calling yourself either backend or frontend is not great.

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

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

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

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

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

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

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

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

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

~~~
slx26
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!

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

~~~
xrd
And the documentation is written by fanboys who are marketing it more than
they are documenting it.

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

------
aphextron
Web development is complicated because it is no longer web development. It's
application development. And nontrivial applications are, by definition,
complicated.

~~~
hombre_fatal
People forget that "front-end development" is just "client development" which
isn't simple nor trivial on any platform.

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

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

------
MadWombat
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?

~~~
root_axis
So using your summary at which step did the engineer make the wrong choice?

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

~~~
root_axis
> _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?

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

~~~
root_axis
> _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?

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

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

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

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

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

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

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

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

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

------
Razengan
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."_

~~~
buboard
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)

~~~
BlueTemplar
Stop using these platforms.

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

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

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

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

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

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

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

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

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

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

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

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

~~~
mirimir
True. But lots of third-party tracking is harder, right?

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

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

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

------
neop1x
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. :)

------
drej
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 :-)

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

~~~
justinmeiners
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?

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

------
buboard
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?

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

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

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

~~~
robertoandred
That’s only “reasonable” if you have a simple, cookie-cutter site.

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

------
dnprock
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!

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

~~~
buboard
Does facebook use react in its main, user-facing site? Does twitter ?

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

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

~~~
buboard
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

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

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

~~~
hootbootscoot
... 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))

------
mholt
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)

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

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

~~~
asalahli
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/)

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

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

------
rixed
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)

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

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

~~~
meesterdude
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 :)

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

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

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

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

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

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

------
hhas01
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?

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

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

------
quickthrower2
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!

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

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

~~~
hootbootscoot
trying to shoehorn a synchronous model onto an asynchronous state machine, are
we?

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

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

~~~
itronitron
I like this, and it looks like a good fit for a lot of dashboard / data vis
applications.

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

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

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

------
xhruso00
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/)

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

------
AlexDragusin
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)

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

~~~
paavohtl
Alternatively: provision a Heroku dyno, add a single-line Procfile, git push
heroku and you're done.

~~~
justicezyx
Let's not pretend that Heroku is that popular to swing the main stream steup.

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

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

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

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

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

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

------
sylens
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?

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

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

~~~
tamrix
Programming isn't hard or easy. Problems are hard or easy.

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

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

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

------
wintorez
Good, let's keep it that way!

------
smashthepants
Where's your newsletter signup so I can be notified when part 2 is released?

------
commandlinefan
> Why is modern web development so complicated?

All the tools that are meant to simplify it.

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

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

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

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

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

------
moocowtruck
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!

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

------
tomc1985
Because "innovation"

------
rb808
Damn I miss Visual Basic.

------
loblollyboy
django, heroku, bootstrap and javascript libraries (but not frameworks)

easy

------
butterisgood
<marquee> is all you need </marquee>

~~~
buboard
i think we need more native browser UIs like marquee. Look at AMP, it
understands that but is impleemnted in JS.

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

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

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

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

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

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

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

~~~
s_y_n_t_a_x
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)

