Live data from Hacker News

Why is modern web development so complicated?

vrk.dev

371–380 of 731 posts

Re: Why is modern web development so complicated?

#371
post #59

Earlier quoted context omitted.

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.

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.

That is THE benefit of a "framework" -

It locks you, and future developers, into a paradigm. It might not be a "best" or even "good" way of doing things, but, adopting a framework helps keep everybody writing the same 'shit software'.

Consistency, it turns out, is key. That's because (as others have pointed out) all software is ultimately shit software. If you wrote it, chances are you don't think it's shit, but everyone else does.

Re: Why is modern web development so complicated?

#372

Earlier quoted context omitted.

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.

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

There are reasons why other industries are more mature, like:

they've been waaaaaaaaay longer than CS/SE

they do not change so robustly & fast in short peroids of time.

>We can't even accurately estimate the cost of a complex project given our choice of tools

Let's do not pretend as if that was limited to our industry.

Re: Why is modern web development so complicated?

#373

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 javascrip…

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.

Re: Why is modern web development so complicated?

#374
post #59

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…

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.

The true judge is the user experience, not the code quality. Modern web sites try to be apps, with tons of whizzy nonsense that breaks on user browsers, to the users' detriment, when they should be simple CRUD sites to manage digital files.

Re: Why is modern web development so complicated?

#375
post #84

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…

> Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build.

What's changing in Chrome 77? A caniuse search for "web components" does not turn up anything that's not old news.

Re: Why is modern web development so complicated?

#376

Earlier quoted context omitted.

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.

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

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

Sure they can. At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc. (Actually there were two of them - the more famous one is the Jeff Dean version that traded off CPU cycles vs. L1-L3 cache misses vs. RAM latency vs. sending data over the network vs. compression vs. disk latency etc, measured in nanoseconds) If you had any moderately complex new system, you'd prototype a few different approaches on a small set of sampled data, do some multiplication to figure out how much it'll actually cost in production, then compare that against the engineer time needed for various optimizations. If you were in a revenue-generating area like Search, somebody (usually at the executive level) would also be calculating how much the project was likely to make or lose for the company and ensuring that's acceptable. Not all that unlike any traditional engineering field.

The thing is that the overhead for this process really only makes sense at Google scale. For the vast majority of new software projects, revenues on success >>> developer time >>> hardware cost. 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. And if the developer can build it, the hardware costs needed to run it will be negligible, so just buy more hardware.

This is an artifact of the software industry essentially being a gold rush, where it's rapidly eating the rest of the world and replacing non-computerized processes that are millions of times slower. When you have 6 orders of magnitude to play with, you can play fast and loose with estimates, because any acceptable solution at all will make you a lot of money. When software has eaten the rest of the world and new systems are competing with existing computerized systems, then it's worth it to start paying attention to things like efficiency, security, TCO. There's some evidence we're approaching that point, but we're not there yet, and it's still more advisable for an entrepreneur to tackle an old-school non-computerized industry than to try and improve on existing software solutions.

Re: Why is modern web development so complicated?

#377
post #369
post #351

Earlier quoted context omitted.

So a thing nobody wants or needs became extremely commonplace because JS devs (and only JS devs, I guess the Java guys have yet to discover this) realized they could invent some new frameworks and managers would gladly pay six-figures a head for them to play around with it?

I don't think the JS devs drove it, at least not primarily. I think they're largely eager to exploit the enthusiasm of others (and probably they should be) and I've seen it happen. I do think it's peculiar to the web. Most other GUI app ecosystems are content not to invent their own visual vocabularies over and over or twist every mundane little program or UI element into an "experience", for instance—I think that ha…

> Your manager or project owner or whoever says "we want a webapp" are you gonna stick your neck out and argue against it?

The question is: what are you going to argue for instead? Not using the web at all is a non-starter, especially in the retail space where you'd get killed by a web-based competitor.

I don't know what your experience is, but historically my bosses haven't given half of a damn what tech stack I use. They care that I deliver on what I promise. Hypothetically, I could still be using PHP/HTML/jQuery but there are a great many reasons I don't and not one of them has to do with padding my resume.

Re: Why is modern web development so complicated?

#378

Earlier quoted context omitted.

If it's a traditional website and not an app, then I'm totally fine with it reloading every time you navigate to a new page or submit a form. Modern servers and browsers are plenty fast for full page reloads, as long as there isn't anything extra slowing down the load or rendering.

Most people say they are, but when you actually measure it you find engagement metrics are better for SPA sites, especially for ecommerce and social. Quite simply people spend more money if they can click fewer times. And thus we have things like infinite scrolling and ajax.

Care to link to those measurements ?

Re: Why is modern web development so complicated?

#379
post #23
post #2

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.

Flexbox? That's way easier than float design and both of those are way easier than designing everything with tables.

Tables were always easy.

Re: Why is modern web development so complicated?

#380
post #59

Earlier quoted context omitted.

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.

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.

What if I told you there is a theory about good module design and if you follow the formal rules of the theory (not design principles mind you there's a huge difference) good and organized designs can emerge from just knowledge of the theory itself?
Post reply on HN