13 ms·

I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous

I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous "rich/complex interaction". And.... I just rarely see any good examples of this. The huge majority of apps (web or otherwise) are not video games. They're forms that submit stuff to a server and get a response. There's sometimes a dropdown here or there.... and that's it.

acephal 7y ago
Mmm, I work on a multimedia sequencer (timeline, viewport, etc) in the browser, it would be utter hell if the whole thing was put together via manual DOM updates in something like a Backbone View render function. I know this because when I joined the company, they were trying to do it in Backbone. For a project of that scope, this was a great way to introduce a large surface for error and maintenance (the project kicked off right when React was launching and Typescript wasn't public). Leveraging React as an interface to updating the DOM removes all of those concerns from your implementation work. That's a big productivity boost when you're trying to build a multimedia sequencer. More so when your team is junior-dominant.
- Jare 7y ago
  > when React was launching and Typescript wasn't public Minor correction, React came out about 7 months after Typescript. That said, Typescript had a promising birth but a rough infancy, so I wouldn't blame anyone for considering it released only after 1.x versions starting in late 2014.
  - acephal 7y ago
    Yeah, that was bad characterization. This was the first half of 2015.
itronitron 7y ago
I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework. That was nice because it was relatively easy for anyone to trace through the application as needed. In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user.
- kqr 7y ago
  In my experience, when it comes to rich interaction, the question isn't whether or not to use a framework -- the question is whether to write your own framework from scratch and discover all mistakes you can make on your own, or use one that already exists and builds on best practises as well as we know them.
- spookthesunset 7y ago
  > I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework Ah but if you actually looked at what you built, I am 100% sure you folks built your own framework instead. A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. You will never be able to hire talent that already knows the tools for your framework. You'll be spending all of the next eternity cobbling together features that you could have had out of the box had you adopted somebody else's framework instead. The choice is never "use a framework" vs. "don't use a framework". The choice is "do we use somebody else's framework" vs. "do we build our own framework". What you implicitly and unknowingly chose was the "we are gonna build our own framework" option. In my experience, the minute the few folks who pushed the "no framework" option leave the company, all the rest of the developers smile and scramble to replace the hot mess of a codebase with something using an industry accepted framework.
  - crtlaltdel 7y ago
    i've seen a shop start as a "no-framework" effort and it did indeed become an "internal framework" project. imo it was a strange choice, given how much effort had to go into maintaining and bugfixing the internal framework...mostly issues that would have been flushed out in something with wider support. before being involved in mostly "modern saas", i was heavy in electrical/electronics mfg and there was always a tension between "not-invented-here" and "borrow-buy-build" camps. NIH would stress that all components in our designs should be in-house (electrical metering, data acquisition, etc) while the BBB camp would turn every effort into a 3rd party integrations exercise. at times this even applied to the factory floor. i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..."
wefarrell 7y ago
It sounds like you don't see the need for single page applications, which is a larger discussion.
nepeckman 7y ago
I see this sentiment on hacker news a lot, and I honestly dont get it. A list of functionality I've implemented that requires (or is made easier by) JavaScript: Client side validation, error messages, autocomplete, dynamically picking/removing/auto filling fields based on user input, forms that need to know user answers to previous forms, smart tables, update of data pushed from server, sharing markup/functionality between pages, removing markup when no longer needed, adding markup when relevant, etc. Of course, all of the above functionality can (and has been) implemented in jQuery, or vanilla js. But using a framework makes it easier to structure and edit the project.
- ativzzz 7y ago
  The OP mentions > They're forms that submit stuff to a server and get a response. So it sounds like they're not actually doing any of the things you mention. For basic forms that just submit, of course React is overkill. Hell, a software developer is overkill for that. For any of the things you mention, React or another similar UI framework makes the project much more manageable.
- dotancohen 7y ago
  Thank you for actually answering the question! Your list of functionality is the first that I've seen which actually shows where React really is helpful.
- bdcravens 7y ago
  The issue seems with moving responsibilities that the server handles really well to the client (namely, state and session management). I think it's less a matter of Javascript-framework vs no framework, and more a matter of SPA vs. non-SPA
  - mands 7y ago
    This hits the nail on the head - it's about SPA vs MPA. Component-based architectures are a proven and a win on FE for more complex interactions, but that doesn't necessitate an SPA. We had a large SPA with a REST API backend and were finding it really difficult to add more features to the FE due to the inherent complexity of the SPA. We decided to split it into an MPA, adding React components to server-side rendered pages as needed (along with intercooler and stimulus when we don't need the power of React). Things have become much simpler and quicker to develop, allowing us to focus on the user features instead. It's easy to forget how much you get for free from the browser and traditional HTTP/HTML client-server mechanics, along with the ease of having full access to your database and data model in your templates - and makes you wonder if going with an SPA first is throwing the baby out with the bathwater.
bernawil 7y ago
They're forms that submit stuff to a server and get a response What kind of response? Asuming no React, a. json b. SSR-html? If, a. Now you've got to process that response, handle errors and finally render into html. You'll be either imperatively replacing DOM nodes, interpolating string templates or both. Probably re-binding event handlers after that. b. You'll be merging your server-rendered html to your current view. Re-binding event handlers if you've got any interactive stuff (e.g your SSR came with a modal link) and god knows what else. React is a million times better than this.
- pests 7y ago
  You forget the most basic response. A full HTML file with a corresponding reload. None of what you said applies. I'm a big react fan and advocate too but sometimes I think we forget about the basics.
  - bernawil 7y ago
    First time I hear XMLHttpRequest was a mistake. No one is going to sit through a full-page reload on every form validation. Even intermediate solutions that merged (hacked) client-server state failed too. APIs are just better.
    - acdha 7y ago
      > No one is going to sit through a full-page reload on every form validation. Why not? Most of the pure HTML forms I use load at least an order of magnitude faster than the complex SPAs I use because there's so many fewer network requests. You can make SPAs which are as fast but I'd say fewer than a third companies, even very large ones like Google or Facebook, succeed at doing so and an even smaller percentage have thought hard enough about error handling. On a daily basic I use sites from Google, Twitter, Facebook, etc. where I have to do a reload anyway because their developers were unaware that network operations require timeouts, retries, and that you need to provide UI feedback for all of those to match what the browser provides by default. EDIT: to be clear, I like that we can do a ton of very complicated things in a browser now — we've been working towards that as an industry for the last 3 decades and it's great that it's largely arrived — but I think it really hits the failure of companies to skimp on resources for anything which isn't critical to the default user experience. Duplicating built-in functionality should be seen as an expensive commitment, not the default unless you're willing to devote the extra resources needed.
ojr 7y ago
with react native I am able to leverage native device apis in Javascript without writing the underlying Swift or Java bridge, there are so many super popular libraries (5k + stars on github), image pickers, contacts, file systems, ui elements that support both platforms and have huge open source support. I am able to create components faster in React or a framework with up to date documentation/testing than using a custom component solution and speed is always in fashion.
mr_toad 7y ago
> They're forms that submit stuff to a server and get a response. React is overkill for something that simple. You don’t even need JavaScript for simple forms.
derefr 7y ago
I think React's use-case is multi-model visualization tools (e.g. a Bloomberg terminal) and cross-visualization editing tools (e.g. Business Intelligence software.) Things where one data source gets data-bound not just to to multiple views, but to multiple view controllers which expose the data differently.
imtringued 7y ago
I would like to see a chat application implemented with just forms that submits stuff. How are you going to get new messages?
- toast0 7y ago
  Ok, so don't do this, but script src=/fetchmessages.js?t=1 Which returns document.write(messagecontent) //if message document.write(script tag t=n+1) If there are messages, server returns them all immediately, plus the repoll JS, and if there aren't any, it waits N seconds before returning just the repoll. This could fit pretty well into an IRC single channel model, where you just stuff all the messages into a single place. For something more akin to MDI/TDI where you have different message displays depending on who you click on, it's trickier to just shove the messages in at the end --- although, if you were a terrible person, you could do something like use the chat id with a prefix as a class name, and use that to show/hide. You still need dom manipulation to add new chats.
- icedchai 7y ago
  This was done in the 90's. You simply refresh the page periodically. You can use the HTML "meta refresh" tag, no JS required.
- jrandm 7y ago
  I got sidetracked searching for pictures of the multiplayer part of the game Vagabond's Quest.[0] I wasn't successful, unfortunately, but a number of the pages outside the login wall were archived.[1] I think you might find several of these pages entertaining,[2] especially if you're familiar with text-based games (especially MUDs and MOOs[3]) and a Dungeons and Dragons-esque setting. The items, combat (PvP and 1-player), and any other aspect of chance were transparently dice rolls and modifiers in-game. Because this is Hacker News, don't miss out on the >20-year-old anti-hacking mechanism.[4][5] Keep in mind this is for a sequel or companion game that came (IIRC years) after the original. With that stage set, picture a black background and some grey text with scattered red/green/blue highlights. The logo was probably the only image. The page would reload every few seconds, but you could manually reload and see new messages sooner. If your username was in a chat text it would make the text larger (both the line and your name, I think).[6] Maybe under a few other conditions too: if you were fighting someone, if it was the admin/mod/dev(!) Falados, I think you could add a few of your own word filters at some point. Originally it was just your username in the line, I'm pretty sure. The combat moves and rolls were also part of this chat stream. I remember being in busy rooms with dozens of people, frantically refreshing, trying to read the top of the screen quickly before it was lost. It was great! I hadn't quite connected the games to programming yet, but I imagine the Hall or Arena you "joined" for Player vs Player combat and chat was by visiting the page of HTML generated by Perl scripts (I remember URIs ending in .pl, maybe some CGI thing?) that had a meta tag to trigger the refresh. It had a regular form with a submit button and the page reload was convenient because that was the only way to see your message or anyone else's new in the page. I'm amazed how clearly I remember playing, if the details are a bit fuzzy. Looking for pictures I came across this,[7] and am excited to read through and maybe check out a beta. Thanks for prompting the search! [0]: http://www.angelfire.com/games2/LanderZ/vq.html http://www.angelfire.com/games2/LanderZ/vq.html [1]: https://web.archive.org/web/20000818004717/http://www.netdragons.com/games/vq1/guide/ https://web.archive.org/web/20000818004717/http://www.netdra... [2]: https://web.archive.org/web/19990902013706/http://www.netdragons.com/games/vq1/dungeon/faq/ https://web.archive.org/web/19990902013706/http://www.netdra... [3]: https://en.wikipedia.org/wiki/MOO https://en.wikipedia.org/wiki/MOO [4]: https://web.archive.org/web/19991105152436/http://www.netdragons.com/games/vw/abt/hack.ipc https://web.archive.org/web/19991105152436/http://www.netdra... [5]: https://crypto.stackexchange.com/questions/47177/would-sha1-be-broken-by-sheer-brute-force-even-if-it-had-no-weaknesses-of-its-o https://crypto.stackexchange.com/questions/47177/would-sha1-... [6]: FONT tags, I'm 99% sure. This was probably one of my early view-source learn-by-example sources, in a futile attempt to cheat [7]: https://playvq.com/roadmap/ https://playvq.com/roadmap/

acephal 7y ago

Mmm, I work on a multimedia sequencer (timeline, viewport, etc) in the browser, it would be utter hell if the whole thing was put together via manual DOM updates in something like a Backbone View render function. I know this because when I joined the company, they were trying to do it in Backbone. For a project of that scope, this was a great way to introduce a large surface for error and maintenance (the project kicked off right when React was launching and Typescript wasn't public). Leveraging React as an interface to updating the DOM removes all of those concerns from your implementation work. That's a big productivity boost when you're trying to build a multimedia sequencer. More so when your team is junior-dominant.

Jare 7y ago
> when React was launching and Typescript wasn't public Minor correction, React came out about 7 months after Typescript. That said, Typescript had a promising birth but a rough infancy, so I wouldn't blame anyone for considering it released only after 1.x versions starting in late 2014.
- acephal 7y ago
  Yeah, that was bad characterization. This was the first half of 2015.

itronitron 7y ago

I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework. That was nice because it was relatively easy for anyone to trace through the application as needed. In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user.

kqr 7y ago
In my experience, when it comes to rich interaction, the question isn't whether or not to use a framework -- the question is whether to write your own framework from scratch and discover all mistakes you can make on your own, or use one that already exists and builds on best practises as well as we know them.
spookthesunset 7y ago
> I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework Ah but if you actually looked at what you built, I am 100% sure you folks built your own framework instead. A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. You will never be able to hire talent that already knows the tools for your framework. You'll be spending all of the next eternity cobbling together features that you could have had out of the box had you adopted somebody else's framework instead. The choice is never "use a framework" vs. "don't use a framework". The choice is "do we use somebody else's framework" vs. "do we build our own framework". What you implicitly and unknowingly chose was the "we are gonna build our own framework" option. In my experience, the minute the few folks who pushed the "no framework" option leave the company, all the rest of the developers smile and scramble to replace the hot mess of a codebase with something using an industry accepted framework.
- crtlaltdel 7y ago
  i've seen a shop start as a "no-framework" effort and it did indeed become an "internal framework" project. imo it was a strange choice, given how much effort had to go into maintaining and bugfixing the internal framework...mostly issues that would have been flushed out in something with wider support. before being involved in mostly "modern saas", i was heavy in electrical/electronics mfg and there was always a tension between "not-invented-here" and "borrow-buy-build" camps. NIH would stress that all components in our designs should be in-house (electrical metering, data acquisition, etc) while the BBB camp would turn every effort into a 3rd party integrations exercise. at times this even applied to the factory floor. i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..."

wefarrell 7y ago

It sounds like you don't see the need for single page applications, which is a larger discussion.

nepeckman 7y ago

I see this sentiment on hacker news a lot, and I honestly dont get it. A list of functionality I've implemented that requires (or is made easier by) JavaScript: Client side validation, error messages, autocomplete, dynamically picking/removing/auto filling fields based on user input, forms that need to know user answers to previous forms, smart tables, update of data pushed from server, sharing markup/functionality between pages, removing markup when no longer needed, adding markup when relevant, etc. Of course, all of the above functionality can (and has been) implemented in jQuery, or vanilla js. But using a framework makes it easier to structure and edit the project.

ativzzz 7y ago
The OP mentions > They're forms that submit stuff to a server and get a response. So it sounds like they're not actually doing any of the things you mention. For basic forms that just submit, of course React is overkill. Hell, a software developer is overkill for that. For any of the things you mention, React or another similar UI framework makes the project much more manageable.
dotancohen 7y ago
Thank you for actually answering the question! Your list of functionality is the first that I've seen which actually shows where React really is helpful.
bdcravens 7y ago
The issue seems with moving responsibilities that the server handles really well to the client (namely, state and session management). I think it's less a matter of Javascript-framework vs no framework, and more a matter of SPA vs. non-SPA
- mands 7y ago
  This hits the nail on the head - it's about SPA vs MPA. Component-based architectures are a proven and a win on FE for more complex interactions, but that doesn't necessitate an SPA. We had a large SPA with a REST API backend and were finding it really difficult to add more features to the FE due to the inherent complexity of the SPA. We decided to split it into an MPA, adding React components to server-side rendered pages as needed (along with intercooler and stimulus when we don't need the power of React). Things have become much simpler and quicker to develop, allowing us to focus on the user features instead. It's easy to forget how much you get for free from the browser and traditional HTTP/HTML client-server mechanics, along with the ease of having full access to your database and data model in your templates - and makes you wonder if going with an SPA first is throwing the baby out with the bathwater.

bernawil 7y ago

They're forms that submit stuff to a server and get a response What kind of response? Asuming no React, a. json b. SSR-html? If, a. Now you've got to process that response, handle errors and finally render into html. You'll be either imperatively replacing DOM nodes, interpolating string templates or both. Probably re-binding event handlers after that. b. You'll be merging your server-rendered html to your current view. Re-binding event handlers if you've got any interactive stuff (e.g your SSR came with a modal link) and god knows what else. React is a million times better than this.

pests 7y ago
You forget the most basic response. A full HTML file with a corresponding reload. None of what you said applies. I'm a big react fan and advocate too but sometimes I think we forget about the basics.
- bernawil 7y ago
  First time I hear XMLHttpRequest was a mistake. No one is going to sit through a full-page reload on every form validation. Even intermediate solutions that merged (hacked) client-server state failed too. APIs are just better.
  - acdha 7y ago
    > No one is going to sit through a full-page reload on every form validation. Why not? Most of the pure HTML forms I use load at least an order of magnitude faster than the complex SPAs I use because there's so many fewer network requests. You can make SPAs which are as fast but I'd say fewer than a third companies, even very large ones like Google or Facebook, succeed at doing so and an even smaller percentage have thought hard enough about error handling. On a daily basic I use sites from Google, Twitter, Facebook, etc. where I have to do a reload anyway because their developers were unaware that network operations require timeouts, retries, and that you need to provide UI feedback for all of those to match what the browser provides by default. EDIT: to be clear, I like that we can do a ton of very complicated things in a browser now — we've been working towards that as an industry for the last 3 decades and it's great that it's largely arrived — but I think it really hits the failure of companies to skimp on resources for anything which isn't critical to the default user experience. Duplicating built-in functionality should be seen as an expensive commitment, not the default unless you're willing to devote the extra resources needed.

ojr 7y ago

with react native I am able to leverage native device apis in Javascript without writing the underlying Swift or Java bridge, there are so many super popular libraries (5k + stars on github), image pickers, contacts, file systems, ui elements that support both platforms and have huge open source support. I am able to create components faster in React or a framework with up to date documentation/testing than using a custom component solution and speed is always in fashion.

mr_toad 7y ago

> They're forms that submit stuff to a server and get a response. React is overkill for something that simple. You don’t even need JavaScript for simple forms.

derefr 7y ago

I think React's use-case is multi-model visualization tools (e.g. a Bloomberg terminal) and cross-visualization editing tools (e.g. Business Intelligence software.) Things where one data source gets data-bound not just to to multiple views, but to multiple view controllers which expose the data differently.

imtringued 7y ago

I would like to see a chat application implemented with just forms that submits stuff. How are you going to get new messages?

toast0 7y ago
Ok, so don't do this, but script src=/fetchmessages.js?t=1 Which returns document.write(messagecontent) //if message document.write(script tag t=n+1) If there are messages, server returns them all immediately, plus the repoll JS, and if there aren't any, it waits N seconds before returning just the repoll. This could fit pretty well into an IRC single channel model, where you just stuff all the messages into a single place. For something more akin to MDI/TDI where you have different message displays depending on who you click on, it's trickier to just shove the messages in at the end --- although, if you were a terrible person, you could do something like use the chat id with a prefix as a class name, and use that to show/hide. You still need dom manipulation to add new chats.
icedchai 7y ago
This was done in the 90's. You simply refresh the page periodically. You can use the HTML "meta refresh" tag, no JS required.
jrandm 7y ago
I got sidetracked searching for pictures of the multiplayer part of the game Vagabond's Quest.[0] I wasn't successful, unfortunately, but a number of the pages outside the login wall were archived.[1] I think you might find several of these pages entertaining,[2] especially if you're familiar with text-based games (especially MUDs and MOOs[3]) and a Dungeons and Dragons-esque setting. The items, combat (PvP and 1-player), and any other aspect of chance were transparently dice rolls and modifiers in-game. Because this is Hacker News, don't miss out on the >20-year-old anti-hacking mechanism.[4][5] Keep in mind this is for a sequel or companion game that came (IIRC years) after the original. With that stage set, picture a black background and some grey text with scattered red/green/blue highlights. The logo was probably the only image. The page would reload every few seconds, but you could manually reload and see new messages sooner. If your username was in a chat text it would make the text larger (both the line and your name, I think).[6] Maybe under a few other conditions too: if you were fighting someone, if it was the admin/mod/dev(!) Falados, I think you could add a few of your own word filters at some point. Originally it was just your username in the line, I'm pretty sure. The combat moves and rolls were also part of this chat stream. I remember being in busy rooms with dozens of people, frantically refreshing, trying to read the top of the screen quickly before it was lost. It was great! I hadn't quite connected the games to programming yet, but I imagine the Hall or Arena you "joined" for Player vs Player combat and chat was by visiting the page of HTML generated by Perl scripts (I remember URIs ending in .pl, maybe some CGI thing?) that had a meta tag to trigger the refresh. It had a regular form with a submit button and the page reload was convenient because that was the only way to see your message or anyone else's new in the page. I'm amazed how clearly I remember playing, if the details are a bit fuzzy. Looking for pictures I came across this,[7] and am excited to read through and maybe check out a beta. Thanks for prompting the search! [0]: http://www.angelfire.com/games2/LanderZ/vq.html http://www.angelfire.com/games2/LanderZ/vq.html [1]: https://web.archive.org/web/20000818004717/http://www.netdragons.com/games/vq1/guide/ https://web.archive.org/web/20000818004717/http://www.netdra... [2]: https://web.archive.org/web/19990902013706/http://www.netdragons.com/games/vq1/dungeon/faq/ https://web.archive.org/web/19990902013706/http://www.netdra... [3]: https://en.wikipedia.org/wiki/MOO https://en.wikipedia.org/wiki/MOO [4]: https://web.archive.org/web/19991105152436/http://www.netdragons.com/games/vw/abt/hack.ipc https://web.archive.org/web/19991105152436/http://www.netdra... [5]: https://crypto.stackexchange.com/questions/47177/would-sha1-be-broken-by-sheer-brute-force-even-if-it-had-no-weaknesses-of-its-o https://crypto.stackexchange.com/questions/47177/would-sha1-... [6]: FONT tags, I'm 99% sure. This was probably one of my early view-source learn-by-example sources, in a futile attempt to cheat [7]: https://playvq.com/roadmap/ https://playvq.com/roadmap/