10 ms·

Ugh, this is massively overcomplicating the vanilla js case. Just put the checkbox html & css on the page. Write a function that updates the label based on che

Ugh, this is massively overcomplicating the vanilla js case. Just put the checkbox html & css on the page. Write a function that updates the label based on checked state. Call it on input/change events. It's like 3 lines of js. React.js people always invent this vanilla js / jQuery strawman that's so complicated and spaghetti that no mortal can possibly understand it. It's total BS. You can write succinct maintainable code without a 100 lb framework.

savanaly 5y ago
It's all about scaling of complexity and number of engineers working on the project. No doubt hand rolled js is better when you only have to do the one thing you mentioned and you're the only person who has to read or write the code. What happens when it's one of hundreds of checkboxes on the site? When they all do slightly different things depending on user sku, product page, file type, file permissions, god knows what else. And when one experiment flag is on or how about this other one? Then i18n? Then what about the fact that after you write this line countless other engineers will see and modify it in the future, it's not just you writing and maintaining it? These are the problems that my company (and, I assume, Publicis Sapient with 20,000 employees according to Google) have to consider when choosing whether to hand roll JS or use a framework.
- simonw 5y ago
  Then you can switch to something like React. But most projects won't ever get close to the level of complexity you are describing. Meanwhile I have seen SO MANY sites that use full React for a contact form with two fields on it.
  - arcturus17 5y ago
    You don't need to get close to that level of complexity for React to become useful. > Meanwhile I have seen SO MANY sites that use full React for a contact form with two fields on it. I agree that the contact form you describe would be dead-easy to do vanilla. Maybe throw in Parcel if you want to write ES6. However, while I suspect some people may use React in this case because it's all they know, others may do it because they are literally faster in React - they have a workflow that can see them code and deploy such a website to Netlify or Heroku or whatever in 10 minutes.
  - hajile 5y ago
    Preact to render the view and a dozen lines to handle the submission and data in a closure are still likely an easier solution than vanilla JS.
  - joesb 5y ago
    Which is fine if your company and teams use React a lot. Why introduce inconsistency in everyone's workflow just because this specific page is a simple contact form? The fact that it is just a simple contact form is exactly why you should use the same tools and workflow that everyone in your team has already been using. Write what other people knows so you don't have to be the one maintaining it.
- QuadrupleA 5y ago
  Everything a programmer does is "hand rolled" whether it's JS or JSX. You'll still have to tackle those complex requirements and come up with a good design that organizes things and makes them manageable, whether you're using React and JS or just JS. To say that a good design is just impossible with JS or that no other engineers could possibly understand the resulting code seems absurd. Javascript is a Turing-complete language. It gives you a lot of design options. Your poor engineers will have to learn it to use React anyway so why would vanilla js necessarily be worse than js plus a giant framework?
  - csande17 5y ago
    I once worked at a place that thought like the grandparent comment. "We're gonna have a huge app with lots of different UI variations. Let's use React. Then it will be super maintainable and scalable!" And then it turned out that if your plan to write maintainable code starts and ends at "use React", you will end up writing code that is not maintainable, and your framework will not save you, and in fact you will be fighting framework-induced bugs and performance issues on top of the problems caused by your total inability to design computer programs. The pace of software development at your company will grind to a halt, you will accept this as the only possible state of affairs (we're following all the best practices by using React!), and your company will limp along for a while and then go out of business.
    - bayesian_horse 5y ago
      It's more about the programmers than the underlying technology. But with react (and redux etc) very smart and experienced people have already put some thought into things like maintainability, and your chances of achieving success from the shoulders of these giants are higher than by starting from scratch. Unless you don't need to reach that high.
      - csande17 5y ago
        I don't think that's really true. React doesn't give you less problems, it just gives you different problems that aren't as immediately visible because you haven't learned to look for them yet. For example, if you're used to thinking that every page of a web app can be tested individually, you won't notice bugs in single-page apps that only happen when using specific links to arrive on pages in a specific order.
errantspark 5y ago
Yup. React is a tool so that thousands of people can speak the same language about a big codebase. That's what it's for, that's the only thing it's (arguably) good at. If you want to pretend otherwise you're left to these sorts of mental gymnastics to make the evidence fit your assumptions.
- atatatat 5y ago
  How does it achieve this?/aim to achieve this?
vpj 5y ago
This is true. We recently re-wrote everything in plain javascript from react, and it didn't increase the lines of code. The vanilla code was much easier to maintain too. React comes in your way when things get complicated and the work arounds produce really messy code. Edit: Project (GitHub): https://github.com/labmlai/labml/tree/master/app https://github.com/labmlai/labml/tree/master/app It's a mobile/web app to monitor machine learning experiment.
- bayesian_horse 5y ago
  Without context like what this application does or how many lines of code you are talking about, this means exactly nothing... Also there is nobody stopping you from writing extremely messy React applications...
  - vpj 5y ago
    https://github.com/labmlai/labml/tree/master/app https://github.com/labmlai/labml/tree/master/app
    - bayesian_horse 5y ago
      It doesn't look like a very complex application, but already has a ton of abstractions, essentially building your own, unproven and unreviewed framework. Also I think you got a typo at https://github.com/labmlai/labml/blob/master/app/ui/src/views/empty_runs_list.ts#L11 https://github.com/labmlai/labml/blob/master/app/ui/src/view...
      - vpj 5y ago
        Thanks for finding the typo. Ton of abstractions is an overstatement. https://github.com/vpj/weya https://github.com/vpj/weya is more like a helper function around `document.createElement`.
      - QuadrupleA 5y ago
        A function is an abstraction. A JSON object is too. Are we in preschool here, not allowed to create new abstractions because they're "unproven and unreviewed" by a FAANG? This all seems so narrow and parochial, like people who have never left their own village. There's a wide world of useful technologies and design techniques out there (including React) and the simplest possible design that solves your problems is usually best.
bayesian_horse 5y ago
If you need to achieve the same functionality and maintainability without React (or some other external library), then by definition you somehow have to reimplement much of it yourself. And no, React isn't all that big in terms of functionality or size. What are the chances that you are arriving at a solution that is better than React? That other engineers have no trouble understanding and maintaining? You'd have to invent new concepts, or at least call them differently, to not copy React's (or any other framerwork's) concepts or ideas. That would make it harder for other people to understand the code.
seer 5y ago
Well react itself is just the virtual diff algo really. How to change this page to this other page as fast as possible, if you don’t know or don’t care to know that other page. That second qualifier is really important. As long as you have 2-10 screens and know the transitions by heart, nothing stopping you from hand rolling js. But once you start adding states things get tricky really fast, as transitions grow exponentially. I’ve built some very complicated apps with vanilla js back in the day, and we had ways of dealing with things like that. We called it “reloading the page” where you start from 0 with your state. Kinda like restarting windows to fix it, rather than figuring out whats wrong. And you could get quite far that way. 37signal’s basecamp was like that - an html app with vanilla js sprinkled throughout. Worked great. But there is a limit in complexity. JS and html are great for building websites, but if you want to build an actual application, you need to be really clever and accept a lot of limitations. React just lifts the ceiling of what you can do, without being all to complicated. And you can use the technics of react without react itself too, once you understand what it is all about - https://github.com/ivank/vanilla-teuxdeux https://github.com/ivank/vanilla-teuxdeux
- kreetx 5y ago
  Why do the virtual dom thing at all? Just remember the locations you need to update and update only them, like svelte or lit-html.
  - jcelerier 5y ago
    wasn't this done because e.g. updating manually a thousand elements one by one was shown to be, like, orders of magnitude slower than updating the whole thing ?
    - mirekrusin 5y ago
      Every time I see d3 stuff, it's pretty fast.
    - Mavvie 5y ago
      I don't think so. I believe it's because without a virtual DOM and a diff, how would react do rendering at all? The whole point of react is you just have a functional "render" method, so you need to render _somewhere_ (and it can't be the DOM for a variety of reasons, eg. deleting and rebuilding the whole DOM would be slow and break things like focus). Svelte is different and doesn't export a render function -- the component knows what DOM nodes need to change for a given prop/reactive var change, so it doesn't need a virtual DOM (and can be much faster as a result)
schwartzworld 5y ago
"I hate people advocating for a tool by bringing up the problem it was used to solve. Just keep your app so simple that you don't need the tool." A better solution is to emulate the react strategy. Create a state object, on user input you can rewrite sections DOM based on the state. You probably don't need React's diffing algorithm until you run into performance problems. Then you have to limit which parts of the Dom you update to keep it snappy. Then you might as well just use react.
- edem 5y ago
  Then you end up rewriting a buggy under-performing version of React. No, thanks. If size is really a concern use Preact.
  - mattgreenrocks 5y ago
    The beautiful thing about React is not React itself, but rather how much it pushed functional idioms into mainstream programming. We can do better from here, mostly by hewing more to the functional core/imperative shell idea. Redux is a popular approach that shows the power of this. In more modern languages with ADTs you don’t even need a library/framework once you fully understand how to structure things well.
    - pjmlp 5y ago
      And me thinking .NET did it first with Rx.
      - mattgreenrocks 5y ago
        Rx never got the attention it deserved IMO. It was the right thing but never really had the ergonomics. It’s entirely possible I wasn’t able to appreciate it at the time, too.
        pjmlp 5y ago
        It is part of Angular and everywhere on Android and iOS, it is plenty of attention.
stephenr 5y ago
The example as shown doesn’t even need JavaScript. It could be a few lines of css.
- leephillips 5y ago
  And that would be even shorter than the React version.
Waterluvian 5y ago
For primitive apps or anything that’s very straightforward like CRUD forms and tables, vanilla works great and should be encouraged. Anything moderately complex gets really painful when you’re storing state in all your HTML elements. A big part of React is to abstract away the horribleness of trying to prevent unnecessary, quite expensive interactions with the DOM. That’s why a lot of comparison examples miss the point and facilitate poor discussion.
benbristow 5y ago
Cool. Project Manager: Now add 3 checkboxes, one being 'N/A' and when you select N/A the other checkboxes are disabled and unchecked. And update the labels, and have additional form sections showing depending on which checkbox is displaying. Probably not that difficult, and probably a bad example, but with React/Vue/etc. it's a lot easier to deal with complex states than manually manipulating the DOM. From experience trying to be clever and anti-framework ends up just creating another framework that's worse in every imaginable way.
- edem 5y ago
  And they also end up with a lot of useless framework knowledge they'll never use again after the project goes up in flames.
  - lawwantsin17 5y ago
    This comment is the reality. Everything else is marketing.
- marcosdumay 5y ago
  Hum... Your new function reads all the checks, calculate the new values and enabled conditions, and applies them. It's called by the onChange of all of the relevant elements. Reactive frameworks do make your life simpler (at least once you pay for the large one time cost of using them), but the change isn't enormous.
  - benbristow 5y ago
    Or you just use React and it has that function already built for you... All you need to do is call setState
    - marcosdumay 5y ago
      You certainly doesn't mean that React has your business rules builtin.
edem 5y ago
You (and most commenters on this branch) forget the most important thing: there are bazillions of libraries that work with react so I don't have to produce all that untested vanilla code. I only have to wire them together in a way I see fit and then I can jump on the next project. Also: good luck finding a person who would forego using and maintaining their easy-to-market React skills.
- acdha 5y ago
  None of which is specific to React, as decades of history shows. One reason that history is worth paying attention to is that it confirms that you’ll be spending a lot of time managing dependencies, testing breaking upgrades, and working with upstream maintainers to fix problems and add features. It’s still a net win but there’s a real cost which is easy to ignore until you count the number of FTE weeks which went into keeping a project building and secure.
brundolf 5y ago
You're right that this doesn't represent the way a vanilla JS UI would ever actually be written in practice (even calling it a "vanilla JS UI" instead of an "html UI" points directly at the problem) But: 1) Even though the web-specific example is contrived, it's a good demonstration/explanation of what people mean generally by declarative vs imperative 2) I don't want to wade into the tired argument, but classic HTML + minimal hand-written JS doesn't scale beyond a certain point. If it did, everyone would still be doing things that way
deleted 5y ago
[deleted]

savanaly 5y ago

It's all about scaling of complexity and number of engineers working on the project. No doubt hand rolled js is better when you only have to do the one thing you mentioned and you're the only person who has to read or write the code. What happens when it's one of hundreds of checkboxes on the site? When they all do slightly different things depending on user sku, product page, file type, file permissions, god knows what else. And when one experiment flag is on or how about this other one? Then i18n? Then what about the fact that after you write this line countless other engineers will see and modify it in the future, it's not just you writing and maintaining it? These are the problems that my company (and, I assume, Publicis Sapient with 20,000 employees according to Google) have to consider when choosing whether to hand roll JS or use a framework.

simonw 5y ago
Then you can switch to something like React. But most projects won't ever get close to the level of complexity you are describing. Meanwhile I have seen SO MANY sites that use full React for a contact form with two fields on it.
- arcturus17 5y ago
  You don't need to get close to that level of complexity for React to become useful. > Meanwhile I have seen SO MANY sites that use full React for a contact form with two fields on it. I agree that the contact form you describe would be dead-easy to do vanilla. Maybe throw in Parcel if you want to write ES6. However, while I suspect some people may use React in this case because it's all they know, others may do it because they are literally faster in React - they have a workflow that can see them code and deploy such a website to Netlify or Heroku or whatever in 10 minutes.
- hajile 5y ago
  Preact to render the view and a dozen lines to handle the submission and data in a closure are still likely an easier solution than vanilla JS.
- joesb 5y ago
  Which is fine if your company and teams use React a lot. Why introduce inconsistency in everyone's workflow just because this specific page is a simple contact form? The fact that it is just a simple contact form is exactly why you should use the same tools and workflow that everyone in your team has already been using. Write what other people knows so you don't have to be the one maintaining it.
QuadrupleA 5y ago
Everything a programmer does is "hand rolled" whether it's JS or JSX. You'll still have to tackle those complex requirements and come up with a good design that organizes things and makes them manageable, whether you're using React and JS or just JS. To say that a good design is just impossible with JS or that no other engineers could possibly understand the resulting code seems absurd. Javascript is a Turing-complete language. It gives you a lot of design options. Your poor engineers will have to learn it to use React anyway so why would vanilla js necessarily be worse than js plus a giant framework?
- csande17 5y ago
  I once worked at a place that thought like the grandparent comment. "We're gonna have a huge app with lots of different UI variations. Let's use React. Then it will be super maintainable and scalable!" And then it turned out that if your plan to write maintainable code starts and ends at "use React", you will end up writing code that is not maintainable, and your framework will not save you, and in fact you will be fighting framework-induced bugs and performance issues on top of the problems caused by your total inability to design computer programs. The pace of software development at your company will grind to a halt, you will accept this as the only possible state of affairs (we're following all the best practices by using React!), and your company will limp along for a while and then go out of business.
  - bayesian_horse 5y ago
    It's more about the programmers than the underlying technology. But with react (and redux etc) very smart and experienced people have already put some thought into things like maintainability, and your chances of achieving success from the shoulders of these giants are higher than by starting from scratch. Unless you don't need to reach that high.
    - csande17 5y ago
      I don't think that's really true. React doesn't give you less problems, it just gives you different problems that aren't as immediately visible because you haven't learned to look for them yet. For example, if you're used to thinking that every page of a web app can be tested individually, you won't notice bugs in single-page apps that only happen when using specific links to arrive on pages in a specific order.

errantspark 5y ago

Yup. React is a tool so that thousands of people can speak the same language about a big codebase. That's what it's for, that's the only thing it's (arguably) good at. If you want to pretend otherwise you're left to these sorts of mental gymnastics to make the evidence fit your assumptions.

atatatat 5y ago
How does it achieve this?/aim to achieve this?

vpj 5y ago

This is true. We recently re-wrote everything in plain javascript from react, and it didn't increase the lines of code. The vanilla code was much easier to maintain too. React comes in your way when things get complicated and the work arounds produce really messy code. Edit: Project (GitHub): https://github.com/labmlai/labml/tree/master/app https://github.com/labmlai/labml/tree/master/app It's a mobile/web app to monitor machine learning experiment.

bayesian_horse 5y ago
Without context like what this application does or how many lines of code you are talking about, this means exactly nothing... Also there is nobody stopping you from writing extremely messy React applications...
- vpj 5y ago
  https://github.com/labmlai/labml/tree/master/app https://github.com/labmlai/labml/tree/master/app
  - bayesian_horse 5y ago
    It doesn't look like a very complex application, but already has a ton of abstractions, essentially building your own, unproven and unreviewed framework. Also I think you got a typo at https://github.com/labmlai/labml/blob/master/app/ui/src/views/empty_runs_list.ts#L11 https://github.com/labmlai/labml/blob/master/app/ui/src/view...
    - vpj 5y ago
      Thanks for finding the typo. Ton of abstractions is an overstatement. https://github.com/vpj/weya https://github.com/vpj/weya is more like a helper function around `document.createElement`.
    - QuadrupleA 5y ago
      A function is an abstraction. A JSON object is too. Are we in preschool here, not allowed to create new abstractions because they're "unproven and unreviewed" by a FAANG? This all seems so narrow and parochial, like people who have never left their own village. There's a wide world of useful technologies and design techniques out there (including React) and the simplest possible design that solves your problems is usually best.

bayesian_horse 5y ago

If you need to achieve the same functionality and maintainability without React (or some other external library), then by definition you somehow have to reimplement much of it yourself. And no, React isn't all that big in terms of functionality or size. What are the chances that you are arriving at a solution that is better than React? That other engineers have no trouble understanding and maintaining? You'd have to invent new concepts, or at least call them differently, to not copy React's (or any other framerwork's) concepts or ideas. That would make it harder for other people to understand the code.

seer 5y ago

Well react itself is just the virtual diff algo really. How to change this page to this other page as fast as possible, if you don’t know or don’t care to know that other page. That second qualifier is really important. As long as you have 2-10 screens and know the transitions by heart, nothing stopping you from hand rolling js. But once you start adding states things get tricky really fast, as transitions grow exponentially. I’ve built some very complicated apps with vanilla js back in the day, and we had ways of dealing with things like that. We called it “reloading the page” where you start from 0 with your state. Kinda like restarting windows to fix it, rather than figuring out whats wrong. And you could get quite far that way. 37signal’s basecamp was like that - an html app with vanilla js sprinkled throughout. Worked great. But there is a limit in complexity. JS and html are great for building websites, but if you want to build an actual application, you need to be really clever and accept a lot of limitations. React just lifts the ceiling of what you can do, without being all to complicated. And you can use the technics of react without react itself too, once you understand what it is all about - https://github.com/ivank/vanilla-teuxdeux https://github.com/ivank/vanilla-teuxdeux

kreetx 5y ago
Why do the virtual dom thing at all? Just remember the locations you need to update and update only them, like svelte or lit-html.
- jcelerier 5y ago
  wasn't this done because e.g. updating manually a thousand elements one by one was shown to be, like, orders of magnitude slower than updating the whole thing ?
  - mirekrusin 5y ago
    Every time I see d3 stuff, it's pretty fast.
  - Mavvie 5y ago
    I don't think so. I believe it's because without a virtual DOM and a diff, how would react do rendering at all? The whole point of react is you just have a functional "render" method, so you need to render _somewhere_ (and it can't be the DOM for a variety of reasons, eg. deleting and rebuilding the whole DOM would be slow and break things like focus). Svelte is different and doesn't export a render function -- the component knows what DOM nodes need to change for a given prop/reactive var change, so it doesn't need a virtual DOM (and can be much faster as a result)

schwartzworld 5y ago

"I hate people advocating for a tool by bringing up the problem it was used to solve. Just keep your app so simple that you don't need the tool." A better solution is to emulate the react strategy. Create a state object, on user input you can rewrite sections DOM based on the state. You probably don't need React's diffing algorithm until you run into performance problems. Then you have to limit which parts of the Dom you update to keep it snappy. Then you might as well just use react.

edem 5y ago
Then you end up rewriting a buggy under-performing version of React. No, thanks. If size is really a concern use Preact.
- mattgreenrocks 5y ago
  The beautiful thing about React is not React itself, but rather how much it pushed functional idioms into mainstream programming. We can do better from here, mostly by hewing more to the functional core/imperative shell idea. Redux is a popular approach that shows the power of this. In more modern languages with ADTs you don’t even need a library/framework once you fully understand how to structure things well.
  - pjmlp 5y ago
    And me thinking .NET did it first with Rx.
    - mattgreenrocks 5y ago
      Rx never got the attention it deserved IMO. It was the right thing but never really had the ergonomics. It’s entirely possible I wasn’t able to appreciate it at the time, too.
      - pjmlp 5y ago
        It is part of Angular and everywhere on Android and iOS, it is plenty of attention.

stephenr 5y ago

The example as shown doesn’t even need JavaScript. It could be a few lines of css.

leephillips 5y ago
And that would be even shorter than the React version.

Waterluvian 5y ago

For primitive apps or anything that’s very straightforward like CRUD forms and tables, vanilla works great and should be encouraged. Anything moderately complex gets really painful when you’re storing state in all your HTML elements. A big part of React is to abstract away the horribleness of trying to prevent unnecessary, quite expensive interactions with the DOM. That’s why a lot of comparison examples miss the point and facilitate poor discussion.

benbristow 5y ago

Cool. Project Manager: Now add 3 checkboxes, one being 'N/A' and when you select N/A the other checkboxes are disabled and unchecked. And update the labels, and have additional form sections showing depending on which checkbox is displaying. Probably not that difficult, and probably a bad example, but with React/Vue/etc. it's a lot easier to deal with complex states than manually manipulating the DOM. From experience trying to be clever and anti-framework ends up just creating another framework that's worse in every imaginable way.

edem 5y ago
And they also end up with a lot of useless framework knowledge they'll never use again after the project goes up in flames.
- lawwantsin17 5y ago
  This comment is the reality. Everything else is marketing.
marcosdumay 5y ago
Hum... Your new function reads all the checks, calculate the new values and enabled conditions, and applies them. It's called by the onChange of all of the relevant elements. Reactive frameworks do make your life simpler (at least once you pay for the large one time cost of using them), but the change isn't enormous.
- benbristow 5y ago
  Or you just use React and it has that function already built for you... All you need to do is call setState
  - marcosdumay 5y ago
    You certainly doesn't mean that React has your business rules builtin.

edem 5y ago

You (and most commenters on this branch) forget the most important thing: there are bazillions of libraries that work with react so I don't have to produce all that untested vanilla code. I only have to wire them together in a way I see fit and then I can jump on the next project. Also: good luck finding a person who would forego using and maintaining their easy-to-market React skills.

acdha 5y ago
None of which is specific to React, as decades of history shows. One reason that history is worth paying attention to is that it confirms that you’ll be spending a lot of time managing dependencies, testing breaking upgrades, and working with upstream maintainers to fix problems and add features. It’s still a net win but there’s a real cost which is easy to ignore until you count the number of FTE weeks which went into keeping a project building and secure.

brundolf 5y ago

You're right that this doesn't represent the way a vanilla JS UI would ever actually be written in practice (even calling it a "vanilla JS UI" instead of an "html UI" points directly at the problem) But: 1) Even though the web-specific example is contrived, it's a good demonstration/explanation of what people mean generally by declarative vs imperative 2) I don't want to wade into the tired argument, but classic HTML + minimal hand-written JS doesn't scale beyond a certain point. If it did, everyone would still be doing things that way

deleted 5y ago

[deleted]