Comment by osdiab | Hacker News Reader

Comment by osdiab | Hacker News Reader

Parent Full thread

I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience.

With Hooks I’m happy in that most of the “business logicky” stuff can be split out into those and my components have returned to being pretty much entirely UI code - I don’t really use any of those weird in-between tags like <Query> anymore.

Transpilation will happen if you want to use new JS features at all. If you use React without JSX and not using any ES6 features, then you can certainly support old browsers without those transpilation steps - just include the compiled CDN-distributed script in a script tag like jQuery, it’s even advertised in the React getting started docs. Just turns out nobody wants to do that.

I agree that SSR is a crazy story though and I hope someone makes something better - but jQuery doesn’t really help with that at all, bootstrapping state from a different machine than the runtime and not incurring state weirdness/security vulnerabilities seems like a generally difficult problem, not a React-specific one. NextJS (and maybe prerender snapshotting) seems like the only decent options right now.

> I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience.

Respectfully, that's not at all what HTML is supposed to be, but even so, as it turns out, sometimes you do need state to drill pretty deep down (say you need an icon to be green if you're authenticated). So people started just passing state as props everywhere, but oh no that's an anti-pattern. So now people are using redux, mobx, or the context API to do essentially the exact same thing. Three new tools were developed by dozens of engineers to basically re-invent "global state." It's ludicrous.

What do you think HTML is for?

If you want the hypermedia-concept of mostly static documents with links to each other, feel free to turn off Javascript or not use React.

If you’re using the web as an application delivery platform that works cross platform without installs and instant updates, then HTML is the base of your UI framework, and as such it helps to have predictability that frameworks like React offer.

Re state, for me the “bad thing” about global state is usually the same “bad thing” about jQuery-based apps - that anything can mess with anything. But all the solutions you mentioned, and especially the Context API, force components to declare their dependencies and update shared state in restricted ways, which makes that “bad thing” much less bad.

If you don’t like shared state at all, feel free to not use any of those, and pass around state throughout the app - but don’t complain to me when synchronizing state throughout your web app becomes a problem, or that boilerplate becomes a drag, because those are the problems these solve.

Let’s put it straight: HTML is a Hypertext Markup Language by definition, it’s not an application UI markup language. We are living in a very confused world where inappropriate standard is used just because nothing better got sufficiently big market share. ES, TS, CSS, all the libraries and frameworks in the ecosystem are all just attempts to make the whale fly. For last 20 years we should have been focusing on building semantic web on HTML, while RAD tools should have been standardizing APIs and UIs across platforms on different, probably similarly looking standards (I’d prefer seeing there some DSL with C-like syntax). Unfortunately we have to deal with what we have - jquery, React, Angular etc, the tools that have not invented anything that we haven’t seen yet, but which pretend to be a silver bullet for solving complexity which should not exist in the first place.

On that I agree, I do wish there was a better cross-platform application UI platform. But it doesn’t exist, so as such beggars can’t be choosers.

It would be a strange choice to not use the best tool for the job because one of the acronyms that’s related to that tool stands for something that for historical reasons doesn’t precisely describe the job.

Agree. My point is that it's the best available AND the worst among those which could be standardized.

Totally agree! Additionally I think it goes beyond HTML, it is also HTTP protocol that has been bent and hacked to make proper event-based UI to work with (originally) stateless request-response concept in responsive and secure way. It often deeply frustrates me when I find myself struggling to solve some stupid problem that was completely non-issue 20+ years ago when I was writing applications in Delphi on Windows 95. What happened, guys?

Browsers also don't provide the necessary tools to actually build interactive UIs without reaching for external libraries. If you want to allow the user to select date or time in a decent user-friendly way... you just have to pull some JS thing in. Dropdowns/select boxes still only provide the most basic capability; multiselect sucks, need to pull in another JS thing. The list can go on.

Even if your application is 90% non-interactive, the remaining 10% could end up introducing a lot of complexity only because browsers haven't advanced on that front at all in the past decade. And that 10% could easily outweigh the 90% when it comes to the architecture of your application - you get frustrated with the jumblefuck of JS littered randomly around to support X feature on Y page and so you just grab React and build a more manageable thing with it.

The standards committees for the Web have seriously dropped the ball.

> using the web as an application delivery platform that works cross platform

Therein lies the problem, understandable as it is. If you're using React (or any other modern UI/MVw/whatever for that matter), you're still describing your app as mutating a grossly inappropriate scene graph of divs and spans held together with CSS tricks when your conceptual model is probably more adequately represented in terms of panels, fields, and canvases. On top of that, you pick about the weakest language out there, and over the course of decades, morph it into becoming more like a real programming language with runtime type info, accidental async patterns, decorators, compilation pipelines and whatnot, giving up the two benefits that JavaScript has, namely ubiquity and running OOTB on browsers by simple page reloading.

It doesn't take much imagination to see that in a deep component hierarchy, drilling down states as props is a maintainability nightmare.

> So people started just passing state as props everywhere, but oh no that's an anti-pattern

It's not an anti-pattern because of some abstract aesthetics, it's a pragmatic management nightmare in practice.

> So now people are using redux, mobx, or the context API to do essentially the exact same thing.

Not to do the same thing, but to improve management of it.

> Three new tools were developed by dozens of engineers to basically re-invent "global state." It's ludicrous.

Why is it ludicrous that engineering effort goes into solving pragmatic problems with how things that have always been possible are done?

I don’t understand. Prop drilling or global state libraries like Redux don’t change the fact that the HTML of your site is a function of its inputs. Those are just two different ways to implement this concept of the HTML being a function of inputs.

Use your example of the icon that’s green if you’re authenticated. With React (regardless of whether you’re prop drilling or using something like Redux and context), you just update your state with isAuthenticated: true and the changes to green. There should only be one way to set that Boolean, and the icon will update regardless of where that Boolean is set. That’s all that’s meant by this concept of HTML being a function of inputs.

I don’t really care what HTML is supposed to be.

The SSR data fetching story really isn’t much different than the story for managing global state in React on the client.

It’s true than a client-side React application could just do AJAX requests on component mounts (or in a useEffect hook) to keep that data in local React component state, and that wouldn’t easily translate to React SSR (because the server renderer can’t know when your component tree is “ready”).

But most complex app-style web sites are already going to need some global state management similar to Redux, where data fetched from the network is stored not in local React component state but in a global store, and when you have that (as well as a JS router, something else you’ll probably be needing anyway), the React SSR story really isn’t that crazy at all.

There’s other problems too - all components need to be runnable serverside (which adds complexity to otherwise simple operations on the dom), forcing yourself to put all state into a redux store even if you’re not planning to share it is more unnecessary boilerplate/overhead - and there isn’t any clear canonical way to achieve this for arbitrary apps.

I’m finding it tricky to implement cleanly in my company’s fairly large React codebase, though I do think the fundamental problem is not a simple one and requires tradeoffs.

It’s true that there’s no official React guidance on doing this, and doing so would probably require official React choices for routing, global state management, etc. which the React team is clearly not interested in doing.

But there are popular frameworks like next.js that have pretty simple patterns (like getInitialProps) that can probably be adapted to any React codebase.

I don't really understand why suspending server rendering to load data is still an unsolved problem for React. Ember figured this out 4 years ago with FastBoot.

It’s not an unsolved problem. There are very many React apps with SSR, and popular frameworks that use React and provide straightforward SSR data fetching patterns.

They don't suspend the render though. The main options, like with Apollo/Relay essentially have to do a double-render.

Reply on news.ycombinator.com