ReactJS is a tax Facebook levies on startup web development | Hacker News Reader

ReactJS is a tax Facebook levies on startup web development

typed.pw

29 pointsisercstmamu36 comments

I've been using React for just about everything front-end wise for the past year. I don't think it's particularly hindered me, really. Sure, it was a learning curve, as was Redux, but now I understand those concepts better, my process is, I clone a 'react starter pack' from git, which has all of the build set-up I need, webpack, sass, ES6 etc, etc. And that's really it, I find it quicker to develop in React and Redux because the component approach, along with the immutability of Redux, allows me to overcome bugs pretty quickly. I find I run into less bugs, too, due to the predictability of doing everything the 'react/redux' way. I also find writing unit tests so easy in React, using 'dumb' components. So the result is, I've got some of the most bug-free, well tested front-end codebases I've ever worked on.

I guess everyone's experiences are different, and I understand that it's a difficult series of libraries to learn and understand fully, and that can be time consuming. But long-term I think it's a time saver.

I'm quite surprised seeing quite many comments telling how they use React "for everything".

Isn't React just a small[1] library that essentially does only one single thing? (And does it well) Takes a component definition, a state object, and then renders (and maintains) the component as a DOM structure?

Unless I was looking into some other React that everyone's talking about, or I've had my eyes looking somewhere else and missed something giant - I'm sure it is. Then, how come everyone's doing everything with what's just an evolution of the templating libraries? I mean, even a simplest CRUD front-end webapp isn't only about the UI.

Not trolling, I really don't get it.

____

[1] Well, technically it's not really small, because it does not of stuff under the hood to implement those virtual DOM and make things efficient. But it's end-user (=web developer who isn't hacking on React internals) functionality isn't wide-scoped. It's a library after all, not Angular or another we-do-it-all framework.

I'm not the parent, but I think that a lot of people (like me sometimes) say React as a short for React+Redux (or other flux implementations). Parent does mention redux, so I guess it applies to them also.

Yes, I suspect it, but there's also ton of other stuff besides UI component rendering and state transformations.

I mean, stuff like persistence layer (communications with some sort of storage), data model and front-end form validation, etc. I don't think React or Redux provide those.

I think the great think about React, and stop me if I've missed your point, is that they're actually just libraries, not framework's, you can just pull in the parts you need and work off of those.

Say you're just doing a single page application, with some basic logic. You can just use React on its own to create components, as you don't need an entire state life-cycle. We do this a lot to 'enhance' our statically generated sites.

Or completely on the other end of the spectrum, you can use Redux, isomorphic rendering with Nodejs for example, react-router, and you can create a complete, dynamic site, with state, storage, authentication, whatever you need.

Then you have everything in between.

So you really can use React "for everything" in my view, and that's partly why I love it so much.

I don't think React is just an "evolution of template libraries", I think React is a concept, I know React didn't invent this concept of 'components', far from it, but I think it brought about the most clear-cut, concise way of creating web components, largely thanks to React's use of JSX, I think. When you team that up with Webpack (which you totally should btw), you can house all of that components dependencies in the same directory, and call them within the component, a truly modular approach.

(I promise you I don't secretly work for Facebook, I just love React).

> they're actually just libraries, not framework's, you can just pull in the parts you need and work off of those

Yes, that's the good part about it. Don't get me wrong, I'm very pleased with React for what it does. However, I only see it as a piece that does one certain thing (UI components), but still needs a lot of other pieces to make a whole.

I've actually first used it exactly this way - to just animate what previously was a static server-processed <form>. Much less work, compared to what I'd have to do if I'd wanted to use some large framework (and bend to its way of doing all things). Still, I was quite confused, as React got marketed as a sort of panacea, and when I started to actually learn what it does, I found out it's essentially just an UI library and I need other pieces for my project.

> I think React is a concept

Aha! I see your point then.

To me it's different. I see React just as glorified and fancy templating system evolution that can update the rendered object DOM in a smart way (rather than how it's with, e.g., Mustache where you have to discard the whole tree and place a new one over), properly preserving the DOM nodes and their internal states.

It really looks like an evolution to me:

- First, we had, e.g. Mustache (and myriad of others). They had one global template-wide state and rendered to a monolithic string without nodes.

- Then came Backbone (and then Angular) that had layered states. A monolith broken to pieces. Not yet atoms, though.

- Then came React and every node had its internal state, nicely propagated through the tree. To me it seems like a logical evolution. I'm not saying it's any trivial or an obvious step (it must've required a lot of effort to come with a nice implementation that React is), but not something ground-breaking either.

Then there's Redux that does some FRP state transformations. But to me it's not React, as it doesn't even really depend on it (although very few use it otherwise, and even those who do probably do so only as proof-of-concept "hey, look, I can use it with [e.g.] Vue!").

Then there's, say, Immutable.js that does data structures that play nicely with FRP. Or, say, various communication libraries (ranging from jQuery.ajax and whatwg-fetch to Restful.js or Socket.IO). To me, such things are certainly not part of React. That's why I was surprised at "React" doing "everything".

Guess, it's just a terminology issue then. Seems that many just call everything "React"...

> Say you're just doing a single page application, with some basic logic

Not trying to argue here, but don't you think for a simple static SPA, using React and creating components is too much overhead ? Why not just create the good-ol' html pages with css and js ?

I always take into account something I call as a effort-to-gain ratio. i.e.- If I have to give a certain amount of effort, I need to see proportional gain. I just don't see a proportional gain with using React in static SPAs.

But I get your point too. At a certain point when you are too familiar with a certain style of development, its hard to let it go.

This is silly. Facebook isn't forcing anyone to use React. People use it because it works better than the status quo.

>The component philosophy of React does offer some organizational benefits, especially for working in a team, but it’s nothing that couldn’t be replicated by some simple coding conventions.

If it's so simple to organize code why do many vanilla js codebases quickly devolve into spaghetti? It may be simple for the author, but not the average dev. Hell, it may not even be simple for the author if the author was placed in charge of a team of average devs! Just because something is easy technically doesn't mean it is easy politically. You can be "right" about something but still struggle to get others to play along. React predefines the rules and it is validated by a major tech company so people are apt to play along.

> React predefines the rules and it is validated by a major tech company so people are apt to play along.

That's his point. By being giant Facebook can "force" React to others.

Well, that's some serious tinfoilery. No one is forcing startups to use React, or to stay with it of they are stuck in development due to it. Facebook did not create and release one of the most popular JavaScript frameworks in order to intentionally hamstring other companies.

Leaving out the second-guessing and the search for motives, I can only say that I have only had positive experiences with React, and that the team I was part of is still working on their React app without losing any velocity after two years; I have never seen that happen with other frameworks or without frameworks at all.

Agree on the direction this post is going, but that's a really cynical way of looking at it. My perspective is that a combination of factors (and FB's engineering clout played no small part) in making React trendy enough where people started using it because it was cool, not because it actually solves their problem. And I'd imagine in a lot of cases those projects aren't complex enough to warrant React, and/or developers have dived in without really understanding how it works and what it does.

React is absolutely overkill for many, many web applications.

The temptation to over-engineering has been seen again and again, yet the industry continues to fall for it.

I think a lot of it boils down to the cult of the new/a fear of being left behind and, perhaps more pernicious, fear of being perceived as 'not smart enough' to deal with the complexity of these tools.

It's an interesting theory but I don't see much to back it up.

In my own experience, developing rich UIs has been - after the initial learning curve - a way simpler task than using vanilla JS.

I completely agree with this. Here is the key point of the article, which I think goes hand in hand with Facebook's mission to create a new web that they are entirely in control of: "From Facebook’s perspective, React has to serve two functions: - priming and funnelling programmers into their enterprise and - suppressing development efficiency elsewhere. It’s positioned very well to achieve both."

This isn't conspiracy or tinfoil-hattery as other comments have mentioned. I think it's really the case and I doubt Facebook disagrees.

I see a lot of handwaving on the side of "just" (fun activity: search for the word "just" on this page) using vanilla JavaScript. Can anyone point to a sane method of putting together a real-world large(ish) JavaScript application without using (or essentially rewriting) any of the established frameworks? I am talking about a single page app with multiple sections, each with multiple pages using nested reusable components. Bonus points for solutions for performance, server-side rendering, nested routing, state management, data flow.

I do react professionally. EVERY DAY. And yes I agree with you to a large extent. I just don't think it's react specifically. Take for instance, building an address form. In the year 2016 this has never been more difficult. What used to be two hours of html/css/jquery, has been turned into a nightmare of our own design. React and other heavy hitters do serve a purpose, but I think it's fair to say that things are harder now than ever.

We live in a world where many js devs only know js, this wasn't true 10 or even 5 years ago.

Could not agree more. I also think React serves its purpose really well, if and only if you will have a complex web app with a lot of updates, connections and a lot of abstraction in components is beneficial for you. So if you want to test everything and want to put everything in a component: Use React, it's proven to work in large scale, look at FB.

But React is not the perfect tool for all use cases. Often many parts of your web app don't need component abstraction. React feels like app development, not like web development. Especially if most of your problems are more web designer problems React makes things difficult for you. One point I absolutely don't like is all the "massive" amount of tooling you need to get React working in a good way. I want to do web development not to be a webpack hero.

Just to be clear: I like React and it serves its purpose. But if you want to be more flexible and don't need logic in every part of your project try something lighter like vue.js (2.0 is coming out soon), which feels like a good mixture of React and Angular best concepts, which is better and ideal for "glueing" stuff and your web templates together with some advanced logic. No need to make components everywhere. It's a lighter transition (from vanilla, jquery etc.) which gives you enough power to handle every medium complex web app. And you also have components there if you want ;)

Frankly - if you're doing web development and not app development (using your words), you shouldn't be using any client-side templating at all. Just render templates server-side, and if necessary use something like InstantClick.

> tricking the framework into doing what we want it to do

I read this from many framework users about many frameworks. Seems like the average developer just can't change is modus operandi to work with the framework they use.

> performance is abysmal

Yes, it's not that good, but most of the time it's enough. Many people write how you should go immutable and be pure and the performance (see pure render mixin etc.) will come. I simply switched some parts of the app, that need high-speed, out with D3 for example.

> it’s nothing that couldn’t be replicated by some simple coding conventions

True and there are many many component based frameworks to choose from. React simply has the better eco system.

> priming and funnelling programmers into their enterprise

Yes and that's probably the main selling point of React for Facebook (i.e. why they give it away for free). They already hired a bunch of devs that did some OSS work on React.

> suppressing development efficiency elsewhere

This, on the other hand, is a bit of a stretch. They don't force anyone to use it and if you did and saw the problems with it (like I did), you could simple use a different framework. There is no shortage on JS frameworks.

What I like about React, is that it has a big eco-system/community and a small API.

After using it one year, I saw its flaws (both in React and Redux) and wouldn't use it for the next project if I have the choice.

Especially when all you're building is a basic CRUD form.

Not knowing the nature of author's project, I think the issue is not so much about "levied taxes" but back to the wisdom of choosing the right tools for the problem at hand.

This article is disappointingly short.

While I agree that React stuff can be done with vanilla HTML and JS for me at least it has been a dramatic improvement in code quality and productivity. And this coming from someone who refused to use jQuery for Ajax when it first came out, I don't jump on bandwagons lightly.

I also haven't seen performance issues assuming you remember to turn off debug in production. But that is not to say there isn't any.

But everyone has their own experiences.

I will say, I don't know if you can call it a tax when no one is forcing your startup to use it.

I think the real reason react is taking off is the ease of integration with es6. It's weakness is the lack of support for web components. The lack of support may cause react to lag behind dart and angular 2 in the future but right now it's a nice way to work with es6 and get some pretty good code organization. Angular 2 is going to be easier to test but people also use react with typescript for the same level of testability. But ultimately the popularity has to do with the way react integrated with babel and es6.

One of the most important skills in web engineering is navigating an ecosystem of tools that grew more complex to use than the problems they originally aimed to solve. And ignoring those tools, identifying and adopting only the ones that are exceptions to the rule.

While I sympathize that React ended up this way effectively, I don't believe it was the premeditated intent. It happens often enough without malicious intent that Occam's razor suggests this is only another non-malicious case.

We've already been through an era of manual DOM updates with jQuery and it was pretty horrible for anything non-trivial.

My first biggish js app was built around jQuery custom events. It started out elegant and simple, I was very happy. It then quickly became a nightmare, a very non-benign spaghetti monster.

I think there is a tendency to reach for frameworks as a default instead of evaluating if they are really needed.

Components is the main benefit of React. It forces you to think modularly, which can be very difficult at first.

Web dev fads change so fast today, only young whipper snappers can keep up because they have both the time to waste and the ignorance not to know its yet another reinvention of the wheel.

Case in point Enyo.

http://enyojs.com/

Yeah, no. At least not any more than the same holds true for Angular, Ember, etc. And thinking it's some ingenious evil plot is a bit silly.

+1. i am paying this tax tinkering with reactjs getting it to do stuff which is very trivial with normal html/js world

Here's an example of using "trivial normal html/js" inside a React component:

http://www.webpackbin.com/VkDiCyjd-

What gives you the idea you have to do everything with React if React makes something too difficult? React has escape hatches built into it for a reason.

Certificate authority is invalid -- would never visit.

It isn't for me.

The server isn't sending the intermediate CA certificate, so you'll get errors unless your browser has cached the LetsEncrypt intermediate (for example from having browsed a different site that sent the LetsEncrypt intermediate). "This server's certificate chain is incomplete. Grade capped to B."

Anyways, they score an "F" on SSLLabs because "This server is vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade set to F."

https://www.ssllabs.com/ssltest/analyze.html?d=typed.pw&s=10...

Reply on news.ycombinator.com