Hacker News Reader

Comment by dynamite-ready | Hacker News Reader

And there's the problem...

"...component orchestration, reactive state management..."

Webdev tool makers are sadists, and many of the 'thought leaders' in the field have Stockholm syndrome.

Some aspects of web development certainly are hard (security especially).

Frontend development however, does not need to be as hard as it currently is. At the very least, I think there's an opportunity to simplify that layer of the stack, and give the control back to design professionals.

Dreamweaver to my mind, represented a more productive direction than React currently does.

View on HN

On the contrary, front end isn't good enough yet, and getting to the point where it's ideal will require more complexity. Users want things to work fast. If you're including a roundtrip to a server your app will never be good enough for a user on a rural 1Mbps satellite connection with 500ms latency. That's the goal - your app has to work well for that guy. You can't get it to be fast if you're using the network a lot. We need concurrent rendering, async background processing, and as much work shifted on to worker threads as we can manage. All the things that native apps do to crank up the performance need to happen on the web too.

Also, don't forget that the web is fantastically backwards compatible. You can write web apps without the complexity if you want to. You can use Dreamweaver! You can server-side render every page. It works. If that's what you want to serve your users then you should do that. Just don't complain when they use the competitor's app that's faster, more responsive, and does fun things like working offline.

More than any framework, what most market leading applications need to provide a competitive service, is greater access to creator resource (developers / designers / content creators, whatever) and / or innovation in pre-production and design.

The problem with current development trends is in how the complexity found in the tools, makes the pool of available creators (at a want for a better term) a tiny, exclusive club. This has a detrimental effect on efforts to innovate at design / pre-production stage, because the designers are near enough held hostage by us developers.

It also has an overall effect on project velocity, because work that could possibly be covered by techically competent designers (namely HTML/CSS development), can only be addressed by expensive and exclusive 'framework specialists'.

I strongly believe this can change by rethinking where the complexity lies.

The culture built around over-complicated tooling is possibly analogous to placing the responsibility for the production of a feature film in the hands of the VFX and lighting teams, or perhaps only deeming a mechanic as having the aptitude to drive a car.

I'm not rigidly stuck to this idea, I'm just musing here.

perhaps only deeming a mechanic as having the aptitude to drive a car

This analogy is a really good one, but you've got it slightly wrong. The website user is the person driving the car. The developer is the equivalent of the person building the car. Saying the development process is "too complicated" is like saying developers should only ever build compact family cars like a Ford, but some of us want to be building BMWs and Teslas and Porsches and F1 cars and monster trucks and semi-trucks, etc. Sure, it's more complex and difficult, but the end result suits the user better, fulfils their needs better, and often just makes them a lot happier.

> If you're including a roundtrip to a server your app will never be good enough for a user on a rural 1Mbps satellite connection with 500ms latency.

That's a tiny minority of users. And that sort of user probably has an old, slow computer which is crushed under the weight of your vast javascript framework, anyway.

Whatever about a _better_ experience (some subjectivity there, though I don't really buy it) I'm pretty sure the modern web isn't a _faster_ experience for most users than it was a decade ago.

That's a tiny minority of users. And that sort of user probably has an old, slow computer which is crushed under the weight of your vast javascript framework, anyway.

React isn't vast. React and ReactDOM together are about 40Kb over the wire of total download size if they're gzipped (https://bundlephobia.com/result?p=react@16.13.1 && https://bundlephobia.com/result?p=react-dom@16.13.1). For reference, the latest version of jQuery is 30Kb. Personally, I test all my production builds on a Chromebook that has 2GB of RAM, and they usually hit 60fps even on relatively complex pages. This is what the standard should be for building for the web - small, fast web apps that work well on slow computers and slow, high latency internet connections.

You can decide not to support everyone if you want, but that's a decision. The technology already works quite well if you put the effort in to building things properly. Build complexity is not a good excuse for serving slow apps.

It's rarely just react, though.

It's possible in principle to build small fast SPAs, but they're vanishingly rare in real life. And even where code size is small, CPU usage and latency are often bizarrely high; even that 500ms latency user might find a roundtrip to the server faster than waiting on some SPAs.

I do a lot of my personal browsing on an elderly (six year old) iPad. It's totally fine for normal web pages, but every year the number of websites which are painful on it rises, due to (usually largely unnecessary) javascript.

Sure there's lots of reasons to not use React and many places don't. Bad management/decision making is more to blame in this case than anything.

Reply on news.ycombinator.com