Comment by pier25 | Hacker News Reader

Comment by pier25 | Hacker News Reader

Parent Full thread

> I feel sorry though for someone getting into frontend dev now.

Yeah. For the last decade or so frontend has felt like standing on shifting sands.

In part it's the ecosystem and entangled deps but also because JS frameworks are really still figuring it out. A couple of years ago I was hoping we'd reach some sort of stable plateau but it just keeps going...

"the DOM is slow we need a VDOM!"

"the VDOM wasn't such a good idea... signals with fine-grained reactivity is really the solution for DOM udpates!"

"oh wait but we now need a compiler!"

"oh wait there's too much JS now... we better move stuff to the server and do SSR with full page hydration!"

"maybe full page hydration wasn't such a good idea... we now need islands!"

Etc.

Don't get me wrong, each of these steps makes total sense. But we're getting into this uber complex solution that involves so much stuff across the whole stack... and it's not even clear to me that running JS in our servers was such a good idea to begin with.

SSR was essential and the motivation was stuff like SEO. For people who care that was uncompromisable. For people who only care about SPA the conversation has been frozen for almost a decade; almost all the innovative fury has been on the SSR/MPA/hybrid side.

> For people who only care about SPA the conversation has been frozen for almost a decade

I don't know, there's been a lot of stuff since 2014.

In client-side React we've seen stuff like react-query, mobx, etc which weren't there a decade ago. Back in 2014 everyone was still using redux (ugh).

Or Svelte and SolidJS which have brought massive improvements in performance and reducing JS with signals, compiler, etc.

FWIW, both Redux and Mobx were invented in 2015.

Thanks for the clarification. It was a long time ago!

And if you're still using React with Redux you're doing just fine for SPA development, as in you're actually still modern and not merely fine. React Query is the only new development you listed that SPA professionals may want to think about, and even then only a little. It's a life convenience tool for making async calls to foreign APIs easier (for internal APIs you probably want RPC-like experiences with type and client generation).

Meanwhile MPA people are redefining the boundaries of work by marrying the frontend to the backend. They are doing some big re-architecture type stuff, and it is very interesting, far more interesting than React Query being the better Axios. If I had to lead with an argument about interesting changes on the SPA side, I would've lead with the ongoing improvements to CRDT libraries. It's niche but there really isn't much of a revolution going on otherwise on the SPA side.

> as in you're actually still modern and not merely fine

Not sure what you mean by "fine".

There's nothing modern about client-side React. To get some perspective consider that more time has passed since today to the release of React in 2013 than from React to jQuery in 2007.

> To get some perspective consider that more time has passed since today to the release of React in 2013 than from React to jQuery in 2007.

Oh my God! That just sent me into a mid life existential crisis for a moment.

Quite a good number of React apps are offline-first. I build offline-first software for emergency services. That means one should maximize app usefulness despite temporary disconnection to peers or server.

The ROI proposition of MPA/hybrid becomes really meh.

"screw it, lets compile it into a WASM blob that renders it all on a canvas"

That'd be unironically simpler than the current state of things.

Nah. There's so much stuff that would need to be implemented.

Just think of all the functionality related to text that browsers give you in HTML: styles, spellchecking, selection, accessibility features, etc. And that's just text.

Most people would just use the most popular framework that did all that for them, while the remainder would complain loudly about the shortcomings of that framework, and we’d be right back where we started.

It would be significantly worse, unless there is a very good reason for that (e.g. some app like Photoshop could work that way).

You lose any form of accessibility, inspectability, AdBlocking won't work, in many cases even mouse select/copy-paste won't work..

I didn't say it'd be better. Just it would be simpler.

No need to learn html, css, JavaScript, bundlers, etc, etc.

You will inadvertently reinvent the browser inside a browser but worse.

Seriously, I think there is a possible future where a macOS-like reactive UI toolkit is developed that compiles and deploys to the web via WASM. Maybe even a compiler that takes something like Xcode's Interface Builder's .nib files (and associated code). Microsoft tried something like that with Blazor WebAssembly. It works really well, but I think a fully data-reactive model like Apple's could be even more successful when applied to web apps.

Whatever the case, I think very few companies have reached the excellence of native macOS interface design in the context of a web app. Figma is a lone exception; for anyone else to achieve what they have, they'd have to reinvent the wheel yet again in so many small ways. (Have you noticed in Figma how moving the mouse down and to the right diagonally from a menu item to its associated submenu does not cause the menu item and submenu to be deselected? That detail, and so many others, are straight-up macOS-inspired UI craftsmanship.)

We need a reusable toolkit that lets ordinary developers achieve Figma-level UI excellence in web apps.

Dreamweaver existed even earlier. I hope something like what you mention (flutter) does not become popular because of accessibility.

> Maybe even a compiler that takes something like Xcode's Interface Builder's .nib files

Please never let this happen.

I don't agree but if you're looking for something that renderers everything in a canvas it's called Flutter https://flutter.dev/, and strangely it's made by Google, even though Flutter's success means the end of scraping the web for search.

Parent speaks the truth.

The amount of fiddling and tweaking required for web UI feels substantially higher than any GUI toolkit I’ve ever used. And I’ve used a lot of them!

I suspect this isn’t seen as a problem because Vite and friends do an amazing job of hot reload. But it is still a helluva brick wall to shipping things.

A11y enters the chat with their buddy "compliance"

Reply on news.ycombinator.com