Hacker News Reader

Comment by peteforde | Hacker News Reader

The current generation of less-experienced developers tends to default to building every project in React, even if there's no tangible benefit to accepting this complexity. It's unpopular to express, but the truth is that many junior devs don't know how to do it any other way. I don't blame them for this, because they literally haven't been doing it long enough to have mastered multiple techniques.

Managers go with it because it's still hip and easy to hire for. If things go wrong, well, it was good enough for Facebook.

View on HN

We can’t blame junior devs using React and other frameworks to try to build more responsive applications. That’s where the demand is.

I wouldn’t say it’s easier to build in these SPA frameworks nor harder. Attention to detail is something people recognize or learn over time.

I actually blame the old guard for not putting in enough time and energy to mentor juniors. It didn't have to end up like this.

As for whether an SPA is harder or easier, that's not really the relevant dimension. You should not be making technology decisions for your company based on what your new junior devs are comfortable with. They will actually level up faster if they are forced to take what they've learned and apply it to something they weren't working on in their nine-week intensive.

Meanwhile, there's nothing "easy" about React and co when you factor in the layers of abstraction and bikeshedding involved in a typical full-stack deployment today. Compared to when I learned, you suddenly have to also be confident with bash, git, docker, AWS, postgres, webpack, and the whole concept of a virtual DOM before you even start modelling your data or thinking about state transformations. Now go compare that to the original Rails "blog in 15" video and you'll have a hard time claiming that anything is easier. The drop in developer ergonomics over this golden era of JS tooling is stunning in its unneccesary masochism.

> bash, git, docker, AWS, postgres, webpack, and the whole concept of a virtual DOM

That's very far fetched. A React app can just be the default template from CRA + some place to host the generated files (like Netlify if you want something simple). You don't need to know any of the above.

Sure, you can get an example of a React component working on a webpage. I'm talking about the daily lived experience of a working junior developer trying to build something real using typical tools for 2019.

There's nothing wrong with react here. You just have to also use a router.

Reduces server costs. Able to process data on client, including mathematical computation via We ebAssembley. Which in effect allows you to create "Web Apps," rather than just a news site, blog, ecommerce, etc... figma.com is an excellent example.

Not to mention that SPA have been used for video game UI. Rather than building that system from the ground up.

If your client's needs are to just display a static and do not dynamic updates from the server then ignoring the SPA approach is very wise.

Client side navigation handled poorly is just that handled poorly. And should be handled by the Senior Developer and not the Junior. As SPA is just another tool for a specific use case.

Honestly, what do you think we did before the Facebook gods deigned to grace us with React? You understand that we didn't need SPAs to build everything, right?

Most of what's gotten better on the web has been about standardization and drastic improvements to EcmaScript. Unfortunately, we've taken all of these new toys and made sites that load slower, on average, on today's phones than typical sites did in 2009. The problem is far worse in developing nations where phones are many generations behind.

Don't get me wrong: I'm glad that React exists and if I was building Trello, it would obviously be an excellent tech choice.

However, there's exactly nothing simpler or faster about a React app vs a properly-cached SSR fronted by Turbolinks and a tiny framework like Stimulus for 98% of applications. I don't know how this became a sacred cow but at some point the Reactive defenders started reminding me of Scientologists.

People were really, really stoked about Java when it came out, too. One codebase that will run without modification on every device, they said.

I use Angular and Svelte professionally. Reactive to me is reactive programming via the rx package that spans many languages. However I only use those frameworks if the job calls for it.

Call me a blending edge buff, but once WebGPU rolls out you can blur the distinction of web site and native program. But I would not utilize such on statically rendered website. But I would use it on a portable version of Photoshop, Blender, AutoCAD, or Minecraft.

Can you do the above today, inefficiently yes. But once WebGPU (gpu multi processing via a compute shaders with shared instructions) hits in combination with WebAssembley Workers (shared instruction cpu processing with proper floats across X cores) it will be an entirely different story.

What is insane to me is that these UI frameworks run in combination with the DOM on the main thread. That they are not designed from the ground up to run SSR and it is an afterthought.

Or in the instance of third world can even be managed by a Service Worker that drip feeds updates and presents th em on the site they are on next time they visit.

1 million and one ways to skin a cat. No way is better, it depends on the client's budget and use case.

Facebook loads pretty slowly for me.

Reply on news.ycombinator.com