6 ms·

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 application

by osdiab 6y ago

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.

dvt 6y ago
> 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.
- osdiab 6y ago
  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.
  - ivan_gammel 6y ago
    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.
    - osdiab 6y ago
      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.
    - baddox 6y ago
- arvinsim 6y ago
  It doesn't take much imagination to see that in a deep component hierarchy, drilling down states as props is a maintainability nightmare.
- dragonwriter 6y ago
  > 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?
- baddox 6y ago
  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.
- cwhiz 6y ago
  I don’t really care what HTML is supposed to be.
baddox 6y ago
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.
- osdiab 6y ago
  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.
  - baddox 6y ago
    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.
- dbbk 6y ago
  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.
  - 6y ago

by osdiab 6y ago

dvt 6y ago

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

osdiab 6y ago
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.
- ivan_gammel 6y ago
  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.
  - osdiab 6y ago
    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.
  - baddox 6y ago
arvinsim 6y ago
It doesn't take much imagination to see that in a deep component hierarchy, drilling down states as props is a maintainability nightmare.
dragonwriter 6y ago
> 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?
baddox 6y ago
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.
cwhiz 6y ago
I don’t really care what HTML is supposed to be.

baddox 6y ago

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.

osdiab 6y ago
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.
- baddox 6y ago
  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.
dbbk 6y ago
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.
- 6y ago