4 ms·

React popularity seems to me the result of wrongly-headed thinking: that because facebook is popular, any technology behind it must be good, and because react i

React popularity seems to me the result of wrongly-headed thinking: that because facebook is popular, any technology behind it must be good, and because react is popular (allegedly), react must be good. I've always been very sceptical of react, and I'm glad I didn't invest too much time looking into it, as it seems both a time sink and a boilerplate-filled approach. I wonder why some people like it, writing no-framework javascript isn't difficult at all, and you can organise it in a nicer, readable way, plus there are many alternative frameworks that seem better. Is it because of too many choices, people would hang on to the one they think will stick?

gianlucaguarini 9y ago
Of course the same thing applies to Angular.js and Google but luckily I never had the chance to work on a project with it until now.
NikolaeVarius 9y ago
I dislike being the guy who things that 'everything sucks' but the things I've seen come out of React have been horrifying. Very few websites even require anything that React provides nor do most webapps need to be webapps. I've come across bugs where simple text boxes were crashing the browser. Fixing that bug took the front end three days because they simply had no idea how to fix it because everything was buried in the React abstraction layer.
- sotojuan 9y ago
  Sounds like a case of bad developers. Obviously, plenty of sites that use React do just fine. That said, I've had those frustrations at work and wishing in my head that our SPA was a server-rendered app instead.
  - NikolaeVarius 9y ago
    Sure, but the question that always lingered in my head was, how it even possible to mess up a text box? It was a simple input form that crashed the browser by taking up all its memory. I could literally see my browser GC spike during every single keystroke. If it's possible screw up the most basic element of a website, I shudder to think what other simple elements are out there that are horribly written
    - ashark 9y ago
      Asana (ugh, not my choice) once prompted me for feedback. The whole thing's performance is always worst-in-class god-awful, but the feedback textarea lagged nearly a full second before registering each keystroke. A textarea. A textarea. My feedback was... a little mean. Having read some of the stuff about their NIH-induced in-house framework I suspect they've got several things hanging around in it that belong on Accidentally Quadratic, assuming they're still using that thing. If they're not still using it then I don't know what they're doing wrong. Possibly most things. Meanwhile I use Basic HTML gmail because full page reloads are way faster than Ajaxy-Gmail and (especially) Inbox. And those are from a company with "only" "A players". I hate the modern web so very much.
      - sotojuan 9y ago
        > I hate the modern web so very much It's worse when making SPAs is my job :-(
dorfsmay 9y ago
I am not a js dev, but isn't the issue of no-framework that you have to write a bunch of code to deal for various browsers? And a bunch of more code to deal with basic web patterns that you'll end up copying from project to project?
- autoreleasepool 9y ago
  I don't see where the parent suggested no framework. It's likely he or she prefers working a different framework or library, like vue.js or even jQuery. For me, jQuery is the bare minimum requirement. I would never attempt to write a large app in pure JS, even with babel. You would definitely run into some of the problems you mentioned. EDIT: I see now where he mentioned no-framework JS
  - haukur 9y ago
    I really don't see how jQuery would help you much there. It doesn't provide any sort of common structure at all, and it's nowadays arguably not very helpful for its helpers either.
    - autoreleasepool 9y ago
      > write a bunch of code to deal for various browsers jQuery helps here
      - haukur 9y ago
        Out of curiosity, which of these compatibility features do you find most useful?
  - Achshar 9y ago
    I have written relatively large (35k lines) project in pure JavaScript (without even jquery) and have never faced any of the issues mentioned by the parent, (Babel helped). I write native first and then run babel to appease my older browser faring users. The advantages of native are that it's extremely snappy to use and fast to load. Bears smaller memory footprint (have to use angular.js at work and god it's awful) and with newer things like async await, ES16 classes, etc code management is very good. Can't recall the last time I had to take care of a specific browser quirk.
rpedela 9y ago
I am working on a web application that is dynamic enough that the standard way to build websites makes it really hard. So I started building my own version of React. Found React some time later and switched because it was better than my crappy code. Why was I trying to build React? I wanted a framework that behaved more like a video game render loop or a desktop UI framework. I wanted a framework where I could simply update the data and the complicated view would update itself efficiently (as few draw calls as possible). I wanted a framework that felt like those much better tools (in my opinion) I was used to on the desktop. React is the very first web framework to do that and it was a huge breath of fresh air for me. However that does not mean every website needs to be built with React. In fact it is probably overkill for most websites.
- 3131s 9y ago
  > I wanted a framework that behaved more like a video game render loop I had that thought the other day, apparently it's not so novel after all! Does anybody know of other frameworks that take this sort of approach?
  - pitaj 9y ago
    Anything with a Virtual DOM pretty much.
arcticfox 9y ago
I can only speak for myself, but I only use React because it solves massive problems with building complicated apps in Javascript. (This value has been explained in countless other places here, so I won't repeat it here.) I actually use it in spite of Facebook, not because of it.
jasode 9y ago
>writing no-framework javascript isn't difficult at all, If anyone recommends this without any concrete source code to illustrate the superiority of the advice, be skeptical for 2 reasons: 1) the programmer who rejects frameworks ends up writing another invisible framework that doesn't happen to have a name. Because the author is intimately familiar with his own code, he many not even realize that an implied framework emerged from it. 2) the programmer truly avoided coding an "accidental framework" but only by duplicating code everywhere. In short, if you organize code in any coherent way with consistent abstractions to follow principles of DRY[1], it becomes a framework whether you give it a name or not. It doesn't mean the framework-called-React is perfect. What it does is raise the quality of discussion from "plain JS is better than ReactJS" to the more realistic comparison of "my unnamed-framework is better than React-framework because ... see my source code at github, etc". >I wonder why some people like it I think for some, they truly chose it for the wrong reason. However, there are others who look at the problems React solves (efficient DOM diffing algorithm, 1-way view update, etc) and conclude that they would rather not reinvent that themselves. Therefore, they use React so they can start solving other more specific problems relevant to their business domain. [1] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
- thr0waway1239 9y ago
  Imagine if I flipped around your statement and said - don't trust anyone who recommends the superiority of a framework without comparing absolutely every possible framework at their disposal and showing sample code to explain why a certain framework must be chosen. Are you up to this comparison task? Suddenly, the problem changes from "finding better tools for my job" to "evaluating some fairly opinionated peoples' views on how the rest of the world should write their code". The second scenario is best avoided because a) you don't want to take the word of someone who isn't going to face the consequences of all your framework-induced overcomplicated code razzmatazz b) for too many people, this also means skipping the part where they learn to walk and start trying to run c) not to mention, the companies creating these frameworks are surreptitiously doing everything possible to change the nature of the web, so by not using the frameworks (however "open" the "source" is presumed to be), you register a little bit of a protest at a fairly low cost Besides, have you ever considered the following: the person creating the invisible framework is actually best suited to find better ways, assuming they do want to improve their coding abilities. Such a person is more likely to naturally gravitate towards the solution. If they fail to do so, those who end up maintaining such code will end up gravitating towards the best solution. How do you think the converse scenario plays out, where someone did use a framework without really needing it, and then it was found to be overcomplicated and unmaintainable?

gianlucaguarini 9y ago

Of course the same thing applies to Angular.js and Google but luckily I never had the chance to work on a project with it until now.

NikolaeVarius 9y ago

I dislike being the guy who things that 'everything sucks' but the things I've seen come out of React have been horrifying. Very few websites even require anything that React provides nor do most webapps need to be webapps. I've come across bugs where simple text boxes were crashing the browser. Fixing that bug took the front end three days because they simply had no idea how to fix it because everything was buried in the React abstraction layer.

sotojuan 9y ago
Sounds like a case of bad developers. Obviously, plenty of sites that use React do just fine. That said, I've had those frustrations at work and wishing in my head that our SPA was a server-rendered app instead.
- NikolaeVarius 9y ago
  Sure, but the question that always lingered in my head was, how it even possible to mess up a text box? It was a simple input form that crashed the browser by taking up all its memory. I could literally see my browser GC spike during every single keystroke. If it's possible screw up the most basic element of a website, I shudder to think what other simple elements are out there that are horribly written
  - ashark 9y ago
    Asana (ugh, not my choice) once prompted me for feedback. The whole thing's performance is always worst-in-class god-awful, but the feedback textarea lagged nearly a full second before registering each keystroke. A textarea. A textarea. My feedback was... a little mean. Having read some of the stuff about their NIH-induced in-house framework I suspect they've got several things hanging around in it that belong on Accidentally Quadratic, assuming they're still using that thing. If they're not still using it then I don't know what they're doing wrong. Possibly most things. Meanwhile I use Basic HTML gmail because full page reloads are way faster than Ajaxy-Gmail and (especially) Inbox. And those are from a company with "only" "A players". I hate the modern web so very much.
    - sotojuan 9y ago
      > I hate the modern web so very much It's worse when making SPAs is my job :-(

dorfsmay 9y ago

I am not a js dev, but isn't the issue of no-framework that you have to write a bunch of code to deal for various browsers? And a bunch of more code to deal with basic web patterns that you'll end up copying from project to project?

autoreleasepool 9y ago
I don't see where the parent suggested no framework. It's likely he or she prefers working a different framework or library, like vue.js or even jQuery. For me, jQuery is the bare minimum requirement. I would never attempt to write a large app in pure JS, even with babel. You would definitely run into some of the problems you mentioned. EDIT: I see now where he mentioned no-framework JS
- haukur 9y ago
  I really don't see how jQuery would help you much there. It doesn't provide any sort of common structure at all, and it's nowadays arguably not very helpful for its helpers either.
  - autoreleasepool 9y ago
    > write a bunch of code to deal for various browsers jQuery helps here
    - haukur 9y ago
      Out of curiosity, which of these compatibility features do you find most useful?
- Achshar 9y ago
  I have written relatively large (35k lines) project in pure JavaScript (without even jquery) and have never faced any of the issues mentioned by the parent, (Babel helped). I write native first and then run babel to appease my older browser faring users. The advantages of native are that it's extremely snappy to use and fast to load. Bears smaller memory footprint (have to use angular.js at work and god it's awful) and with newer things like async await, ES16 classes, etc code management is very good. Can't recall the last time I had to take care of a specific browser quirk.

rpedela 9y ago

I am working on a web application that is dynamic enough that the standard way to build websites makes it really hard. So I started building my own version of React. Found React some time later and switched because it was better than my crappy code. Why was I trying to build React? I wanted a framework that behaved more like a video game render loop or a desktop UI framework. I wanted a framework where I could simply update the data and the complicated view would update itself efficiently (as few draw calls as possible). I wanted a framework that felt like those much better tools (in my opinion) I was used to on the desktop. React is the very first web framework to do that and it was a huge breath of fresh air for me. However that does not mean every website needs to be built with React. In fact it is probably overkill for most websites.

3131s 9y ago
> I wanted a framework that behaved more like a video game render loop I had that thought the other day, apparently it's not so novel after all! Does anybody know of other frameworks that take this sort of approach?
- pitaj 9y ago
  Anything with a Virtual DOM pretty much.

arcticfox 9y ago

I can only speak for myself, but I only use React because it solves massive problems with building complicated apps in Javascript. (This value has been explained in countless other places here, so I won't repeat it here.) I actually use it in spite of Facebook, not because of it.

jasode 9y ago

>writing no-framework javascript isn't difficult at all, If anyone recommends this without any concrete source code to illustrate the superiority of the advice, be skeptical for 2 reasons: 1) the programmer who rejects frameworks ends up writing another invisible framework that doesn't happen to have a name. Because the author is intimately familiar with his own code, he many not even realize that an implied framework emerged from it. 2) the programmer truly avoided coding an "accidental framework" but only by duplicating code everywhere. In short, if you organize code in any coherent way with consistent abstractions to follow principles of DRY[1], it becomes a framework whether you give it a name or not. It doesn't mean the framework-called-React is perfect. What it does is raise the quality of discussion from "plain JS is better than ReactJS" to the more realistic comparison of "my unnamed-framework is better than React-framework because ... see my source code at github, etc". >I wonder why some people like it I think for some, they truly chose it for the wrong reason. However, there are others who look at the problems React solves (efficient DOM diffing algorithm, 1-way view update, etc) and conclude that they would rather not reinvent that themselves. Therefore, they use React so they can start solving other more specific problems relevant to their business domain. [1] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

thr0waway1239 9y ago
Imagine if I flipped around your statement and said - don't trust anyone who recommends the superiority of a framework without comparing absolutely every possible framework at their disposal and showing sample code to explain why a certain framework must be chosen. Are you up to this comparison task? Suddenly, the problem changes from "finding better tools for my job" to "evaluating some fairly opinionated peoples' views on how the rest of the world should write their code". The second scenario is best avoided because a) you don't want to take the word of someone who isn't going to face the consequences of all your framework-induced overcomplicated code razzmatazz b) for too many people, this also means skipping the part where they learn to walk and start trying to run c) not to mention, the companies creating these frameworks are surreptitiously doing everything possible to change the nature of the web, so by not using the frameworks (however "open" the "source" is presumed to be), you register a little bit of a protest at a fairly low cost Besides, have you ever considered the following: the person creating the invisible framework is actually best suited to find better ways, assuming they do want to improve their coding abilities. Such a person is more likely to naturally gravitate towards the solution. If they fail to do so, those who end up maintaining such code will end up gravitating towards the best solution. How do you think the converse scenario plays out, where someone did use a framework without really needing it, and then it was found to be overcomplicated and unmaintainable?