Why is modern web development so complicated?

Everyone expects the frontend to be easy, especially non-engineers: "hey, it's just a box, and you can just resize it and center it just that way..", while non-engineers would just move away when you mention thread/concurrency/parallelism.

The outside perception, I am afraid, affects me. I don't want to be stuck all the time doing things that are equally hard, but much less appreciated.

I have a lot of respect for frontend development, and approach it with the same kind of caution and respect that I do the backend stuff, however that is not always appreciated, and since it can get complicated fast, and people are expected to finish quickly as if on a treadmill, those things get messed up, hacked, and brittled up.

Another analysis paralysis issue with frontend is cost/benefit for doing it "right." Since frontend is a leaf and not the dependency of another layer in the application, it becomes dispensible to a certain extend in some scenarios. It is seen as replaceable and not worth spending a lot of time on. So when working on frontend, second guessing whether it will be scrapped off later is always hanging in there, paralysing you between "engineering" mode, or just give it a quick hack.

I would not dread doing frontend development, if allowed to do things correctly.

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

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

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.

It's awesome that Google did that. This is the first I've heard of it. But:

> The thing is that the overhead for this process really only makes sense at Google scale.

The software industry is far larger than Google. If we want to claim that software is a discipline of engineering, we all need to have access to that kind of reference data, rather than trying to feel our way around in the dark in comment threads about blog posts about somebody's personal experiences.

I won't go so far as to say there's no such thing as software engineering -- a number of people working for companies with large budgets have well earned that title, I'm sure -- but the extent to which the term is traded like currency in our industry is disrespectful to the discipline.

> So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time.

The fetishization of developer time is one of the problems slowing the maturation of our industry. It ignores end-user time, it ignores management time; it often focuses solely on the initial development time of a project and ignores entirely the ongoing maintenance time for a project.

How many codebases are there out there that are gigantic balls of mud? How much developer time has been wasted on trying to maintain or refactor those codebases? How many really dumb security issues have negatively impacted companies or end users? How many comments has tptacek left on one little forum in one musty corner of the internet over the years trying to explain cryptographic and security-related best practices to an infinite legion of under-trained developers?

How many people have lost their lives to software defects? Not even the really tricky CS stuff, I mean the kind of defects that any other engineering discipline uses as case studies in their introductory courses.

Which case study would you choose for our Galloping Gertie?

Certainly software has done an incalculable amount of good in the world, and its impact is far and away net positive.

But while software has been busy "eating the world", it has rarely paused to also consider the cost and damage it has wrought and whether there are practices that could be standardized to reduce those negative effects. So I disagree wholeheartedly that we're not yet at the point that these things are important. Depending on who you ask, computer programming is between 60 and 180 years old. That's well long enough for us to begin asking questions like, "what data do we have to support this approach or that approach?"

There is still plenty of room for experimentation and research. There is still plenty of room for hobbyists and tinkerers. This isn't an exclusive-or thing.

As much as I really do appreciate blog posts like this one, and the discussion they tend to generate, and especially that there's a new one to read every single day (he said, wryly), I can't help but see every one of them as another indicator of the immaturity of our profession.