3 ms·

What was bad about React then is the same thing that’s bad about it today: despite the atomic unit of React being a “component”, the best practice was always to

What was bad about React then is the same thing that’s bad about it today: despite the atomic unit of React being a “component”, the best practice was always to re-write your entire fronted in JavaScript, shipping a blank HTML page and forcing the end user to download a megabyte of JavaScript to make their computer write the HTML, for some reason. And in order to get the “convenience” upgrade over jQuery+backbone or whatever, you had to abandon all existing standards and best practices, making any JavaScript you were using that was not in the style of React useless. Web components that encapsulate state and interactivity, usable alongside a regular HTML page, were an emerging direction when React shipped and forced everyone to re-write ‘class=‘ to ‘className=‘. And being forced to re-write every app as an SPA was a dumb idea the day people started doing it, even in light of other available approaches. You’re right that a lot of people hated React before they ever tried it, and they were right, even with the full knowledge of what it was replacing.

troupo 3y ago
> Web components that encapsulate state and interactivity, usable alongside a regular HTML page, were an emerging direction They weren't. By 2013 web components were still flailing around completely ignoring everyting that was happening in the world and coming up with an unusable and badly design API while crippling a bunch of other things in the process (like forcing C++-like OOP onto prototype-based Javascript) > when React shipped and forced everyone to re-write ‘class=‘ to ‘className=‘. React is basically just Javascript. What do you think className is? https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla... > And being forced to re-write every app as an SPA was a dumb idea the day people started doing it, even in light of other available approaches. What do you think web components are if not a way for people to dump a bunch of Javascript onto a page (and dozens of Javascript-only specs to accompany them)?
- deleted 3y ago
  [deleted]
- mbgerring 3y ago
  > What do you think web components are if not a way for people to dump a bunch of Javascript onto a page (and dozens of Javascript-only specs to accompany them)? You can get most of what you need onto a web page with HTML. Some components need to be interactive. For that, you need JavaScript. The question is, do you: 1. Keep the rest of the HTML in place, and add JavaScript to that HTML for the interactivity you need (the web components approach) Or, 2. Re-write the entire web page as a JavaScript “app”, including the parts that are just fine as static HTML, for the “convenience” of the pieces that need interactivity (the React approach) Both involve “dumping JavaScript onto a page,” sure, but they are totally different approaches. For a decade, the entire industry picked “2”, and now the internet is a bloated disaster.
  - troupo 3y ago
    > Keep the rest of the HTML in place, and add JavaScript to that HTML for the interactivity you need (the web components approach) It's not the web components approach. Almost nothing about web components is about progressive enhancement. > Re-write the entire web page as a JavaScript “app”, including the parts that are just fine as static HTML That is literally what web components are. They can't even participate in forms without Javascript
hnbad 3y ago
You're describing AngularJS, not React. When React hit the scene there were services for "pre-rendering" your AngularJS app for SEO and crawlers. "Rehydration" for server-side rendering was one of the biggest selling points of React. Heck, even literal Web Components were stuck in that direction. The big reveal of the Web Components implementation in Polymer involved a demo page that was literally an empty HTML page with a single <DemoApp /> custom element node and a massive JS runtime. And that was after React had become popular enough for Googlers to actively heckle React and other libraries on Twitter: #UseThePlatform. React of course lapsed in server-side rendering eventually because it was not a priority to Facebook and therefore only an afterthought. Arguably the killing blow was Create React App not giving any thought to it at all. But one of the most popular React frameworks is Next, which is now more than 6 years old and is best known for being good at SSR. The class vs className thing is a silly argument and enough articles have been writing about this that I don't need to reiterate the full argument here but basically the DOM API calls it className (because it wanted to avoid reserved keywords in property names) and most libraries have special-cased "class" to be an alias for "className" or even go out of their way to prevent you from using the actual property name. React actually does less here, not more. The rendered DOM itself (i.e. the HTML sent over the wire in SSR or what you see in your DOM explorer) is no different whether you use JSX where it's called className or a template language that translates "class" to "className" for you.

troupo 3y ago

> Web components that encapsulate state and interactivity, usable alongside a regular HTML page, were an emerging direction They weren't. By 2013 web components were still flailing around completely ignoring everyting that was happening in the world and coming up with an unusable and badly design API while crippling a bunch of other things in the process (like forcing C++-like OOP onto prototype-based Javascript) > when React shipped and forced everyone to re-write ‘class=‘ to ‘className=‘. React is basically just Javascript. What do you think className is? https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla... > And being forced to re-write every app as an SPA was a dumb idea the day people started doing it, even in light of other available approaches. What do you think web components are if not a way for people to dump a bunch of Javascript onto a page (and dozens of Javascript-only specs to accompany them)?

deleted 3y ago
[deleted]
mbgerring 3y ago
> What do you think web components are if not a way for people to dump a bunch of Javascript onto a page (and dozens of Javascript-only specs to accompany them)? You can get most of what you need onto a web page with HTML. Some components need to be interactive. For that, you need JavaScript. The question is, do you: 1. Keep the rest of the HTML in place, and add JavaScript to that HTML for the interactivity you need (the web components approach) Or, 2. Re-write the entire web page as a JavaScript “app”, including the parts that are just fine as static HTML, for the “convenience” of the pieces that need interactivity (the React approach) Both involve “dumping JavaScript onto a page,” sure, but they are totally different approaches. For a decade, the entire industry picked “2”, and now the internet is a bloated disaster.
- troupo 3y ago
  > Keep the rest of the HTML in place, and add JavaScript to that HTML for the interactivity you need (the web components approach) It's not the web components approach. Almost nothing about web components is about progressive enhancement. > Re-write the entire web page as a JavaScript “app”, including the parts that are just fine as static HTML That is literally what web components are. They can't even participate in forms without Javascript

hnbad 3y ago

You're describing AngularJS, not React. When React hit the scene there were services for "pre-rendering" your AngularJS app for SEO and crawlers. "Rehydration" for server-side rendering was one of the biggest selling points of React. Heck, even literal Web Components were stuck in that direction. The big reveal of the Web Components implementation in Polymer involved a demo page that was literally an empty HTML page with a single <DemoApp /> custom element node and a massive JS runtime. And that was after React had become popular enough for Googlers to actively heckle React and other libraries on Twitter: #UseThePlatform. React of course lapsed in server-side rendering eventually because it was not a priority to Facebook and therefore only an afterthought. Arguably the killing blow was Create React App not giving any thought to it at all. But one of the most popular React frameworks is Next, which is now more than 6 years old and is best known for being good at SSR. The class vs className thing is a silly argument and enough articles have been writing about this that I don't need to reiterate the full argument here but basically the DOM API calls it className (because it wanted to avoid reserved keywords in property names) and most libraries have special-cased "class" to be an alias for "className" or even go out of their way to prevent you from using the actual property name. React actually does less here, not more. The rendered DOM itself (i.e. the HTML sent over the wire in SSR or what you see in your DOM explorer) is no different whether you use JSX where it's called className or a template language that translates "class" to "className" for you.