Hacker News Reader

Comment by idlewan | Hacker News Reader

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?

View on HN

>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

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?

There are some traditional upsides/downsides to writing your own framework, but they should be evaluated for each case without blindly espousing one view or another - that said, for almost all business needs, you are probably better served by using an established framework.

Frameworks 1) Solve more difficult problems that most developers are not qualified to implement optimal solutions in a timely manner for (i.e. efficient algorithms, creating parsers for correctly parsing templates and avoiding security pitfalls, cross-platform rendering, avoiding cross-platform bugs such as browser-specific issues, etc.) 2) Have a publicly documented and established set of patterns/concepts (good for hiring - most developers do not want to learn a homebrewed system that likely brings less professional development benefits for their careers. Whether this is accurate or not in how it affects their careers is irrelevant, this perception is pretty strong from what I can tell anecdotally) 3) Avoids the significant cost of committing to R&D to reinvent the wheel, which most companies are not willing to do and/or does a disservice to companies financially

Homebrewing a framework, which is what you do when you avoid an existing one has these upsides 1) Building something that is potentially easier to understand (especially if built by one or a few people) 2) Potential for smaller JavaScript payload sizes

The upfront cost of creating a homebrewed framework is significant, and to be honest, going that route is probably technical malpractice for an engineer for almost all situations, even at bigger companies. I would be far more wary of any recommendation of homebrewing a framework than adopting an existing one maintained in the open by a community. The downsides of a framework not controlled by you are far outweighed by the downsides of creating one from scratch almost all the time. It is far more productive to participate in the community for a framework that is close enough to your ideal and influence the process that way than it is to burn it all down and suffer trying to solve the same problems in a more limited and likely worse way.

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.

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.

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

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.

> I hate the modern web so very much

It's worse when making SPAs is my job :-(

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.

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

Anything with a Virtual DOM pretty much.

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.

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.

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?

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

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.

I have no idea what "native" means in this context, care to elaborate?

I beg your pardon, poor choice of words, native here means plain js. Nothing more.

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.

> write a bunch of code to deal for various browsers

jQuery helps here

Out of curiosity, which of these compatibility features do you find most useful?

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

No, because it's 2017, not 2007.

Reply on news.ycombinator.com