React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it.
The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework. It's not a complete Application Framework, sure, and you may mix it with other stuff. In fact, you will generally mix it with other stuff. But I don't think that the difference library vs framework lies in providing for all of the aspects of the application or just for some parts of it.
In this particular case, the author seems to have overstepped that somewhat, saying "With a framework, you’re essentially given all the materials to build that house, and it’s up to you in what arrangement you put them in."
And in there lies the problem. That is not a framework. That's Home Depot. A framework does indeed tell you in what arrangement you're supposed to put the materials. It's in fact this that makes it a framework. It gives you structure. Or at least, the basis for the structure. You put your materials into the arrangement the framework suggests.
React is only concerned with UI, sure. But then again it does give you quite a bit of structure. It does tell you how you're supposed to arrange and build your UI. You extend this class with these methods, or you create this kind of function using these functions in this way. You put your rendering here, and return it in this way... and then the framework will run it.
What is correct is that React is for UI. So, sure, it will not tell you how you should do your API calls. But not because it's not a framework, but because API calls are not a UI concern.
I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code.
So with that in mind, you can use React as both. If you ever call `ReactDOM.render()` just once and then live in React land, with all the lifecycle hooks and whatnot, you're essentially treating React as a framework, as React calls everything after the first initialize.
If you call `ReactDOM.render` in multiple places or have something around that handles that for you, then you're using React as a library.
I think the "library" vs "framework" argument irt react is pretty silly.
At the end of the day, what difference does it make?
React may not be as opinionated as other application frameworks, but it's also non completely un-opionionated.
If you write a full ui in React, whats the level of effort involved to port it back to vanilla js, or even another framework? It's certainly not trivial. IMO that's the only qualifier needed.
But I agree, it's all about marketing.
I do think the "win" that React has here is that it's easy to introduce React into an existing project with minimal overhead. In that sense I think its closer to library than framework, but after enough time you will inevitably end up with a "React app" and not a "web app with some React".
I think the sense which the original article talks about is an important one: You can generally use vanilla libraries for non-UI stuff. You don't generally need to use anything React specific.
This is in contrast to frameworks like Angular which try to reinvent to entire ecosystem in an "Angular style". Which is a massive pain if the Angular version has a bug, doesn't implement the feature you need, or is simply far too complicated because it's trying to be everything to everyone. In React, there are usually 2 or 3 options for everything with different trade-offs. And this is amazing, because you can pick the library that works for your project.
The library argument makes much more sense if you've been around the block in web UI. There are many precursor and concurrent web frameworks that do much more than just the UI: They control data management, dependency injection, etc. For some, the UI is nearly an after thought of the model layer. So maybe its not completely accurate but contextually it rang very true to someone like myself, who had used 4-5 other frameworks before using React, and was absolutely one way it stood out to me.
Hmm, did the React team themselves sell it as a library specifically as in "not a framework"? I do remember them specifically calling it responsible for "just" the view layer, but I also seem to recall someone on the React team (I might be wrong there) distinguishing the two as "a framework calls your code, whereas your code calls a library", where React is squarely the former. (Other than `React.render()`, I guess.)
I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility.
And it's also constantly evolving and getting better. Just recently I started a React project with class components only to learn that hooks are now a thing and they remove a lot of boilerplate code. Even with redux, redux supports hooks as well so you can scrap that entire connect() stuff alltogether. Just back to simple function components.
> I am not so up to date with frontend dev but what's with the hate towards React these days?
HN is rarely the place to read constructive comments about JavaScript and frontend development.
Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel productive with it.
I love React and write it, in Typescript, on a daily basis. However:
- It starts you off with about 40kB of minified gzipped javascript; some developers feel that it's too much.
- It is not and probably never will be the most performant framework out there, which upsets quite a few people (although the work that the React core team is doing with Concurrent Mode probably means that from the end user's perspective React will feel fast enough).
- It has become the default way for many frontend developers to write JavaScript; I know I am personally guilty of that. This generates a lot of resentment from more experienced developers who have learned to prioritise minimalistic JavaScript bundles over developer experience.
It’s the price of success. Similarly, a lot of people now vehemently hate Go, and in a few years they’ll be complaining about the problems with Rust. (No idea about frontend because as far as I’m concerned React is still on top.)
I don’t think it’s really too big of a deal, but I wish people would be more realistic and use less hyperbole. Everything has trade-offs, one’s own personal honey moon ending does not mean we were all blind and/or ignoring the faults with things.
Because it's overhyped to the point it's being used everywhere even for projects where there was no reason to ever go beyond basic static HTML + maybe vanilla js, if at all, by devs who want to pad their resume. At the same time, it taxes your mobile battery, and generally leads to a world of overcomplicated appified Chrome-only web sites when actually the web was meant as a straightforward mechanism for self-publishing and exchanging ideas. Finally, reading the umptieth take of a junior dev having his React epiphany, or worse, a staged React consultancy/course ad piece provokes counter-reaction, if only because it's intellectually insulting.
I've been coding and training people in react for a while now, and here is my experience:
- if you learned react by yourself years ago, you had to go through a lot of pain: the doc was terrible, the ecosystem a moving flaky target and conventions were not established. Things are better today, but it's not something you forget. Somebody starting react in 2018, and with create-react-app, will feel much happier.
- if you come from projects were you sparkled JS a bit, and suddenly you move to SPA with react, which is the experience of many, it feels like a wall. In fact, for many, React is the gateway to JS, and it pays the price for it: if you dislike working with JS (which is not uncommon if you come from another language like Ruby, Python, etc), you associate it with React. If you don't do JS full time and suddently must embrace the full stack of it just to make a UI, it's overwhelming. And despite the message you can use bare bone react, nobody does that: you use react, you eat the burger tower with it. Webpack reputation espacially, tainted react reputation.
- react has been oversold and overhyped. It doesn't help that the react community has been in deny of all its problems for years. They fixed many eventually, but before they did, they claimed it was all wonderful. It felt insulting for some people, espacially senior devs from other techs who knew the youngsters in front of them were full of it.
- the whole store concept has been a debacle. First there was a mysterious name (it's a plane, it's a train, it's flux!), but no solution. Then there were too many. Then Redux won. But Redux is so full of boilerplate. But wait, "you don't need Redux". But then people hacked many solutions internally to avoid redux with no guidance. Then redux toolkit and react provider arrived. In general, react and its ecosystem changed too fast. Way too fast. Unless it's your full time job, it's very hard to keep up. If all techs did that, we'll never be working. Combine that with the JS community desire to always use the latest toy, and you get a rat race. People have work to do, they don't want to deal with drama. React ecosystem is a drama queen.
- there is no convention on how to write a react project. Everytime you move to a project, it's a new project. You relearn the layout, the naming convention, the way store is handled, how things are passed around, the libs used for basic things, the testing infra, glue code for said libs, how you deal with css, the granularity of components, API best practices, etc. Not to mention the flavor you are in, depending of the version of react used and the fashion at the time. That's just for react. Then you deal with the other JS techs.
- so now, how do you know what to do? Who to trust? Where to get the gospel from? Thousand of tutorials, many imcomplete, obsolete, unpractical, specialized or dishonest. Just the way to manipulate something as simple as props have so many variants with different implications, and you got them all online. All. Of. Them. If you come from the ordered and well established world of backend frameworks, it's a mad house.
- then there are the gotachas. setState() is asynchronous, auto bind on createClass, but not on extends (but yes if render()). There you gotta call super(props), not here, useEffect dependancy management... React is full of them.
- when the magic doesn't get you, it lets you down. Some basic operations, like settings classes, preventDefault, communicating with the parent, etc. that you do all the time, are incredibly verbose for no good reason ("it's just JS you all!). Most other libs have shortcuts for them. In fact, most react projects add libs to get on par. When I train people in react and they ask me how to do this simple thing, I get desperate looks: "really?".
- integrating react with legacy frameworks like RoR, Symphony or Django is really, really not fun if you don't have a SPA with an REST API. And everybody does it differently.
- react native code reuse was a lie. A damn lie. And its great perfs as well. Nobody likes to be lied to.
- the immutability story is the last straw. I get the benefit of it. But for the vast majority of projects I met in the wild, the cost is way to high. This has so many ramifications I would need another comment just for this one.
Bottom line, if you work with seasonned programmers like it's often heard on HN, you can make the best of react. If you don't, and I work a lot with schools, administrations, average corporate IT deps, etc., the cost of react is going to weight on the team.
The teams that can manage React correctly are not that many outside of our bubble.
And for the ones that can, the price of using react may just be not worth it.
When I give the same exercice to do with Vue and React, beginners doing Vue finish in half the time. So I usually advice for Vue. Life is short, and you are probably not facebook at scale.
A whole lot of people use it at work and witnessed valid criticisms. It’s not like we’re going to have the knives out when React/Angular is new.
Give it a little time, see a few codebases, extend and build a few apps, then come back. Now people have some credible stuff to say. We can’t comment much about how great Hooks are after reading a few Medium posts. I’ll see in a few months when it’s all over the codebase.
HN will be full of ‘we rebuilt our api in GraphQl and boy things are a mess’ in 2 years.
> so you can scrap that entire connect() stuff alltogether
To me that "entire stuff" is about the only thing that is good about redux (barely does dependency injection). See people need to understand that hook is a good API from the library authoring point of view (the react team's and react component library authors') it's not such a clean abstraction for people to write application on top of while unneccesarily make their code depend on magic react functions all over the place.
I cant count how many "data fetching hook solutions" I've seen on twitter. If something does data fetching, then it needs to know about fetch() and may be a reactivity abstraction like promise or rx. A hook is completely unjustified.
I think the number of concepts that need to be understood to be an efficient React developer has grown over the years just enough that it has become slightly frustrating to learn. It is still presented as a very simple small surface area framework but there's a lot of subtly with how many new concepts need to be understood now like hooks as an example. I think it just crossed a threshold and became less intuitive and more tiresome as a result unless you are embedded in React land and do React stuff all the time.
> I am not so up to date with frontend dev but what's with the hate towards React these days?
I don't use React day to day in a big team so I can't comment on the maintainability gains, but as a user all I see is websites degrading the experience when migrating to SPA. If state of the art front end engineering with React is Facebook or Reddit then it's hugely disappointing.
Does this article qualify as 'hate' though? The author acknolwdges that he's new to react and is simply pointing out two things that he found challenging.
Nothing surprising. Infact, I don't understand why the article is so highly upvoted.
To understand React, it is important to understand the difference between imperative and declarative coding. [0] React is a way to write declarative code that use life cycle hooks or effects to do imperative "stuff".
The best explanation oh how useEffect works is by Dan Abramov [1] It is also worth reading his article on React as a UI Runtime as it is a good explanation of React conceptually under the hood.
If you're not doing declarative programming with React then you're swimming upstream.
Problem is that the concept of declarative programming would be very difficult to get beginners to grasp. Once you grasp it though, it's absolutely incredibly powerful and importantly - simple.
And this is where React loses beginners who jump to more intuitive programming models.
You can't drop a bit of it into your project. It distorts how you build the webapp.
jQueryUI is a library. You can add it in and your code is still vaguely the same.
React is a framework pretending to be a library so people can't say "Oh, what? another framework?"
As soon as you use React, you're in the react universe, not the normal webdev universe.
With a normal webapp, I can just import an external js library. With react, I must look for projects that translate those library into the react universe (react-bootstrap etc).
Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.
In my 1.5 years or so of using hooks, I'm finding components with hooks subtly more buggy than their class counterparts - there are a lot of gotchas with that dependency array for hooks, I have encountered nasty bugs both with explicitly declaring all of the dependencies in the array and declaring less than them.
It is much easier to accidentally create infinite loops with useEffect that you would never create with class components, and some of the code you write turns out to be more verbose and less expressive, such as when trying to diff previous and current values of state & needing to create extra state variables with useState for each such value you need to react on.
Hooks seem very appealing at first (I lean more FP than OOP in general), but the bugs and slipshod initial rollout out of beta really does not inspire much confidence. Even today I still encounter weird issues.
The biggest difference is that the class based components are an older iteration of the API into React, one that lies closer with how React internally works (or worked), but one that is not necessarily useful for writing correctly working components.
Say you have a component that renders some data it fetches from the backend, and it received the ID via a prop. In a class based component you might be inclined to write the fetching logic in the componentDidMount or maybe the constructor. However, if you change the ID you feed the component, the component will update instead of being recreated. In the naive class based version it won't refetch the data, and won't behave correctly. With useEffect hooks you don't really care anymore, you can reason about side effects in the same declarative way. You express the fact that fetching new data is a dependency of the prop changing, which holds true both on first render and later on update.
The hooks API fixed a handful of these 'mistakes' that were still present in the class based API. I agree that the syntax might look awkward at first, but the hooks API is much better thought out than the class based one.
(Some anecdata: almost any component that I rewrote in hooks-style has been halved in number of lines of code, the concepts have been much less spread out over the file. See this tweet for an example: https://twitter.com/threepointone/status/1056594421079261185)
No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.
I've worked with both extensively, hooks are way easier to grasp, they allow you to avoid numerous ifs and comparing manually to previous states, you can separate actions according to what properties you're listening changes on, which would be cobbled together in a traditional life-cycle method, and the best part? They can be reused between components
Big picture: React (especially with JSX) can be thought as PHP running on client side.
We can replace mentally any <div> or <span> on the page with <iframe src="someScriptFunction()"/>. When the application state (fuzzy term but still) changes we request these content generating functions to re-execute.
The VDOM is just an implementation detail - agreement on what these someScriptFunction()'s shall return. Conceptually they may return just html and so we can use:
function onDataModelChange(model) {
element.html = provideHtmlRenderingOf(model);
}
can be used instead of reconciliation (diffing). Performance of such updates will be the same, if not better than React's, BTW.
The only problem of element.html = ... approach is that such updates will loose runtime state. For example, if you have <textarea> replaced that way you will loose its current editing state - undo/redo stack, caret positioning, etc.
So VDOM and reconciliation mechanism is a palliative - to do not loose runtime states on updates. But, again, it is not a panacea. Think about <div contenteditable/> based editors, their content cannot be reactive in principle.
That update-only-what-is-needed reasoning frequently used by React people to promote "speed" hypothesis is a bit misleading - it was introduced for different reasons really.
If you look at it from one side, React doesn't have technical problems or the way it's built. If you look at it from another side - React opens up a wide range of possibilities - you can simply drown in them. Adequate things you have done all your life - suddenly feel not so adequate anymore :) For example, it would be fine to use plain old CSS, but with React it just feels wrong. If you look at the number of libraries that try to evolve CSS, there are many. But there is just no winner in sight. Pretty much the same situation is happening in state handling. The number of possibilities! It's amazing. Eventually, though, something gains momentum, like Redux did. This has consequences for React ecosystem, but also everywhere else in JS world. It slowly migrates to Angular, and other frameworks - as the cool kid on the block.
Elegant, simple concepts of React - they are outweighed by the environment they live in. React allows for rapid prototyping, provokes ideas which sometimes break traditional ways. Anyways, I will leave these thoughts with saying that personally I don't have issues with it. I adapt React to what I want - it doesn't adapt my thinking ;)
I can agree. I'd take a bit of SSR and JS + jQuery any day over big and heavy JS frameworks.
Even if I'd write the backend as an API without no SSR, I would prefer to write the frontend in HTML + CSS + vanilla JS + jQuery. It feels more intuitive to me as there are no abstractions to complicate things, no opinionated framework to force me do things its predefined way.
You should try to use it too! If you discover you don't like anything about it, all the better, you can say you've experienced it and not just read about it. If you happen to like at least parts of it, you've just expanded your knowledge and arsenal of tools for UI development.
I write a lot of enterprise apps and I’ve seen many many frameworks come and go over the years.
I personally am not impressed with React and don’t get what all the fuss is about. We’ve had Angular, jQuery and a whole bunch of stuff over the years and each one managed to become a ‘a thing’ for a while
React introduced a whole new way of writing GUI's.
I come from a game development background, and there we had Immediate GUI's for some time now (https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutor...). React basically translates this concept to the web, and does some optimizations to not rebuild the entire DOM from scratch, and only rebuild when state changes and not every frame.
Writing a 'render function' is simpler and easier than building a structure of widgets and letting them handle events. (I like simple and easy)
Anyway, it seems both react and flutter are also gaining on the mobile apps developments, and web developers are very happy using React.
Of course frameworks come and go, but React introduced a shift of mind when programming GUI's.
The mental model for a react component is very much simplified and consistent.
You declare how your view looks like, wire up the state and user interaction stuff and you have a self contained puece of code.
People doing UI stuff, before the advent of React usually highly appreciate it because they know how much work it takes to actually build a usable UI in vanilla JS.
React is a framework though, not a library. I don't mean to be disparaging but this is an article about how someone thought react was one thing, found it was another and then wrote a post of random tidbits about things in react you could learn from its homepage?
(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior.
"Everything an HTML tag" is an insane mantra to have. As author points out, what in the world does a <Query> tag even do? It might make sense to us because we're used to it now, but the semantics of a tag is completely lost in this "new way" of using them (don't call it declarative because that's not what it technically is; it's markup). These days I'm creating HOCs on top of HOCs to support different behavior (from redux stores, to authentication HOCs, to "don't render this thing on the server" async components). It's, simply put, a terrible idea. And everyone just bought into it because the guys at Facebook must be really smart.
The lifecycle hooks are just confusing and unnecessary. They are side-effects of over-engineering. And to add insult to injury, they change every few versions (so old code will inevitably break on new React versions).
SSR. I've brought this point up on HN before, but doing server-side rendering in React is absolutely ridiculous. Every time I need to implement it, I'm constantly battling async stuff, state management, webpack/babel, hot module reloading issues, shimming `window` or `document` on the server side, etc. Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.
It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.
"The way I like to think of it in comparison to Angular is this: Angular is a framework for architecting and building applications. It, for the most part, doesn’t change the way you write your HTML or CSS, but it heavily controls the way you write Javascript.
React, on the other hand, is a library for building user interfaces. It, for the most part, doesn’t change the way you write Javascript that isn’t directly related to your UI, but it heavily controls the way you write HTML and CSS (or the equivalent of it). And this brings me to the next point…"
I love React. In fact I recently gave plain vanilla JavaScript a go and it was so painful that I was glad to get back to React's way of organising a large application.
I don't use Redux or server side rendering - they're not needed.
The only thing that I think it should do differently is leave styles to be handled natively.
tldr; React is a view renderer. It renders views. Getting data to and from those views not included. Navigation? Not included. Persistence? Not included. Styling? Not included. Why? It's just a view renderer, that is to say, it renders templates.
When the only thing your application shares with its dependencies is its view renderer, you're going to feel a lot of pain. This is one of the big reasons why I use Ember.js for complex web-frontends (though holla to phoenix live views). It's a framework-- it has all them pieces you need included in a sane way that's consistent.
Just my two cents...
P.S. If you write JavaScript UI code, and you want to like be better at it, go write native UI code. You'll learn soooo god damn much, write better JS, and understand a lot more about what the fuck all these pieces (like react) are actually doing (rendering UI, managing state, networking etc) in a sane curated (thanks Googs, Microsofties, and Apples) way.
Except that it's not only a view renderer, it reacts to changes in state, and it has ways to do stateful thing after a component is rendered or stops being rendered or at other times.
And in practice some state is specific to some component or group of components and some state is global or the group of components doesn't translate to a subtree of HTML's tree structure. Also the kind of thing that has to happen based on what happens in the app is often deeply async.
And it all becomes a mess.
But it's still not as bad as a mess as without React, I believe at this moment.
agreed. using ember has been instrumental in getting my projects up and running quickly, and then, maintaining them as they grow from mvp to enterprise level.
I tried React and hated it, especially JSX, but I made some decent money working on React projects in the past. I much prefer libraries/frameworks where the view is completely separate and is more “pure” HTML. I ended up creating my own framework that was much easier to understand and manage, but is obviously not generic enough to publish. Maybe one day I’ll clean it up and push it to a Github repo, but then again, does the world need yet another MVC framework? I think not.
[+] [-] genezeta|5 years ago|reply
The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework. It's not a complete Application Framework, sure, and you may mix it with other stuff. In fact, you will generally mix it with other stuff. But I don't think that the difference library vs framework lies in providing for all of the aspects of the application or just for some parts of it.
In this particular case, the author seems to have overstepped that somewhat, saying "With a framework, you’re essentially given all the materials to build that house, and it’s up to you in what arrangement you put them in."
And in there lies the problem. That is not a framework. That's Home Depot. A framework does indeed tell you in what arrangement you're supposed to put the materials. It's in fact this that makes it a framework. It gives you structure. Or at least, the basis for the structure. You put your materials into the arrangement the framework suggests.
React is only concerned with UI, sure. But then again it does give you quite a bit of structure. It does tell you how you're supposed to arrange and build your UI. You extend this class with these methods, or you create this kind of function using these functions in this way. You put your rendering here, and return it in this way... and then the framework will run it.
What is correct is that React is for UI. So, sure, it will not tell you how you should do your API calls. But not because it's not a framework, but because API calls are not a UI concern.
[+] [-] capableweb|5 years ago|reply
So with that in mind, you can use React as both. If you ever call `ReactDOM.render()` just once and then live in React land, with all the lifecycle hooks and whatnot, you're essentially treating React as a framework, as React calls everything after the first initialize.
If you call `ReactDOM.render` in multiple places or have something around that handles that for you, then you're using React as a library.
[+] [-] protonimitate|5 years ago|reply
At the end of the day, what difference does it make? React may not be as opinionated as other application frameworks, but it's also non completely un-opionionated.
If you write a full ui in React, whats the level of effort involved to port it back to vanilla js, or even another framework? It's certainly not trivial. IMO that's the only qualifier needed.
But I agree, it's all about marketing.
I do think the "win" that React has here is that it's easy to introduce React into an existing project with minimal overhead. In that sense I think its closer to library than framework, but after enough time you will inevitably end up with a "React app" and not a "web app with some React".
[+] [-] nicoburns|5 years ago|reply
This is in contrast to frameworks like Angular which try to reinvent to entire ecosystem in an "Angular style". Which is a massive pain if the Angular version has a bug, doesn't implement the feature you need, or is simply far too complicated because it's trying to be everything to everyone. In React, there are usually 2 or 3 options for everything with different trade-offs. And this is amazing, because you can pick the library that works for your project.
[+] [-] cloverich|5 years ago|reply
[+] [-] Vinnl|5 years ago|reply
[+] [-] dvcrn|5 years ago|reply
And it's also constantly evolving and getting better. Just recently I started a React project with class components only to learn that hooks are now a thing and they remove a lot of boilerplate code. Even with redux, redux supports hooks as well so you can scrap that entire connect() stuff alltogether. Just back to simple function components.
[+] [-] ggregoire|5 years ago|reply
HN is rarely the place to read constructive comments about JavaScript and frontend development.
Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel productive with it.
Also, TypeScript is awesome.
[+] [-] azangru|5 years ago|reply
- It starts you off with about 40kB of minified gzipped javascript; some developers feel that it's too much.
- It is not and probably never will be the most performant framework out there, which upsets quite a few people (although the work that the React core team is doing with Concurrent Mode probably means that from the end user's perspective React will feel fast enough).
- It has become the default way for many frontend developers to write JavaScript; I know I am personally guilty of that. This generates a lot of resentment from more experienced developers who have learned to prioritise minimalistic JavaScript bundles over developer experience.
[+] [-] jchw|5 years ago|reply
I don’t think it’s really too big of a deal, but I wish people would be more realistic and use less hyperbole. Everything has trade-offs, one’s own personal honey moon ending does not mean we were all blind and/or ignoring the faults with things.
[+] [-] tannhaeuser|5 years ago|reply
[+] [-] sametmax|5 years ago|reply
- if you learned react by yourself years ago, you had to go through a lot of pain: the doc was terrible, the ecosystem a moving flaky target and conventions were not established. Things are better today, but it's not something you forget. Somebody starting react in 2018, and with create-react-app, will feel much happier.
- if you come from projects were you sparkled JS a bit, and suddenly you move to SPA with react, which is the experience of many, it feels like a wall. In fact, for many, React is the gateway to JS, and it pays the price for it: if you dislike working with JS (which is not uncommon if you come from another language like Ruby, Python, etc), you associate it with React. If you don't do JS full time and suddently must embrace the full stack of it just to make a UI, it's overwhelming. And despite the message you can use bare bone react, nobody does that: you use react, you eat the burger tower with it. Webpack reputation espacially, tainted react reputation.
- react has been oversold and overhyped. It doesn't help that the react community has been in deny of all its problems for years. They fixed many eventually, but before they did, they claimed it was all wonderful. It felt insulting for some people, espacially senior devs from other techs who knew the youngsters in front of them were full of it.
- the whole store concept has been a debacle. First there was a mysterious name (it's a plane, it's a train, it's flux!), but no solution. Then there were too many. Then Redux won. But Redux is so full of boilerplate. But wait, "you don't need Redux". But then people hacked many solutions internally to avoid redux with no guidance. Then redux toolkit and react provider arrived. In general, react and its ecosystem changed too fast. Way too fast. Unless it's your full time job, it's very hard to keep up. If all techs did that, we'll never be working. Combine that with the JS community desire to always use the latest toy, and you get a rat race. People have work to do, they don't want to deal with drama. React ecosystem is a drama queen.
- there is no convention on how to write a react project. Everytime you move to a project, it's a new project. You relearn the layout, the naming convention, the way store is handled, how things are passed around, the libs used for basic things, the testing infra, glue code for said libs, how you deal with css, the granularity of components, API best practices, etc. Not to mention the flavor you are in, depending of the version of react used and the fashion at the time. That's just for react. Then you deal with the other JS techs.
- so now, how do you know what to do? Who to trust? Where to get the gospel from? Thousand of tutorials, many imcomplete, obsolete, unpractical, specialized or dishonest. Just the way to manipulate something as simple as props have so many variants with different implications, and you got them all online. All. Of. Them. If you come from the ordered and well established world of backend frameworks, it's a mad house.
- then there are the gotachas. setState() is asynchronous, auto bind on createClass, but not on extends (but yes if render()). There you gotta call super(props), not here, useEffect dependancy management... React is full of them.
- when the magic doesn't get you, it lets you down. Some basic operations, like settings classes, preventDefault, communicating with the parent, etc. that you do all the time, are incredibly verbose for no good reason ("it's just JS you all!). Most other libs have shortcuts for them. In fact, most react projects add libs to get on par. When I train people in react and they ask me how to do this simple thing, I get desperate looks: "really?".
- integrating react with legacy frameworks like RoR, Symphony or Django is really, really not fun if you don't have a SPA with an REST API. And everybody does it differently.
- react native code reuse was a lie. A damn lie. And its great perfs as well. Nobody likes to be lied to.
- the immutability story is the last straw. I get the benefit of it. But for the vast majority of projects I met in the wild, the cost is way to high. This has so many ramifications I would need another comment just for this one.
Bottom line, if you work with seasonned programmers like it's often heard on HN, you can make the best of react. If you don't, and I work a lot with schools, administrations, average corporate IT deps, etc., the cost of react is going to weight on the team.
The teams that can manage React correctly are not that many outside of our bubble.
And for the ones that can, the price of using react may just be not worth it.
When I give the same exercice to do with Vue and React, beginners doing Vue finish in half the time. So I usually advice for Vue. Life is short, and you are probably not facebook at scale.
[+] [-] runawaybottle|5 years ago|reply
Give it a little time, see a few codebases, extend and build a few apps, then come back. Now people have some credible stuff to say. We can’t comment much about how great Hooks are after reading a few Medium posts. I’ll see in a few months when it’s all over the codebase.
HN will be full of ‘we rebuilt our api in GraphQl and boy things are a mess’ in 2 years.
[+] [-] nsonha|5 years ago|reply
To me that "entire stuff" is about the only thing that is good about redux (barely does dependency injection). See people need to understand that hook is a good API from the library authoring point of view (the react team's and react component library authors') it's not such a clean abstraction for people to write application on top of while unneccesarily make their code depend on magic react functions all over the place.
I cant count how many "data fetching hook solutions" I've seen on twitter. If something does data fetching, then it needs to know about fetch() and may be a reactivity abstraction like promise or rx. A hook is completely unjustified.
[+] [-] have_faith|5 years ago|reply
[+] [-] tarsinge|5 years ago|reply
I don't use React day to day in a big team so I can't comment on the maintainability gains, but as a user all I see is websites degrading the experience when migrating to SPA. If state of the art front end engineering with React is Facebook or Reddit then it's hugely disappointing.
[+] [-] Alterlife|5 years ago|reply
Nothing surprising. Infact, I don't understand why the article is so highly upvoted.
[+] [-] Kiro|5 years ago|reply
[+] [-] zappo2938|5 years ago|reply
The best explanation oh how useEffect works is by Dan Abramov [1] It is also worth reading his article on React as a UI Runtime as it is a good explanation of React conceptually under the hood.
[0] https://courses.reacttraining.com/courses/250055/lectures/38... (Can sign in for free to watch this one video.)
[1] https://overreacted.io/a-complete-guide-to-useeffect/
[+] [-] andrewstuart|5 years ago|reply
If you're not doing declarative programming with React then you're swimming upstream.
Problem is that the concept of declarative programming would be very difficult to get beginners to grasp. Once you grasp it though, it's absolutely incredibly powerful and importantly - simple.
And this is where React loses beginners who jump to more intuitive programming models.
[+] [-] tarkin2|5 years ago|reply
You can't drop a bit of it into your project. It distorts how you build the webapp.
jQueryUI is a library. You can add it in and your code is still vaguely the same.
React is a framework pretending to be a library so people can't say "Oh, what? another framework?"
As soon as you use React, you're in the react universe, not the normal webdev universe.
With a normal webapp, I can just import an external js library. With react, I must look for projects that translate those library into the react universe (react-bootstrap etc).
[+] [-] skrtskrt|5 years ago|reply
(I don’t disagree with anything else you said)
[+] [-] prodave|5 years ago|reply
[+] [-] Bahamut|5 years ago|reply
It is much easier to accidentally create infinite loops with useEffect that you would never create with class components, and some of the code you write turns out to be more verbose and less expressive, such as when trying to diff previous and current values of state & needing to create extra state variables with useState for each such value you need to react on.
Hooks seem very appealing at first (I lean more FP than OOP in general), but the bugs and slipshod initial rollout out of beta really does not inspire much confidence. Even today I still encounter weird issues.
[+] [-] superice|5 years ago|reply
Say you have a component that renders some data it fetches from the backend, and it received the ID via a prop. In a class based component you might be inclined to write the fetching logic in the componentDidMount or maybe the constructor. However, if you change the ID you feed the component, the component will update instead of being recreated. In the naive class based version it won't refetch the data, and won't behave correctly. With useEffect hooks you don't really care anymore, you can reason about side effects in the same declarative way. You express the fact that fetching new data is a dependency of the prop changing, which holds true both on first render and later on update.
The hooks API fixed a handful of these 'mistakes' that were still present in the class based API. I agree that the syntax might look awkward at first, but the hooks API is much better thought out than the class based one.
(Some anecdata: almost any component that I rewrote in hooks-style has been halved in number of lines of code, the concepts have been much less spread out over the file. See this tweet for an example: https://twitter.com/threepointone/status/1056594421079261185)
[+] [-] awestroke|5 years ago|reply
[+] [-] deviantfero|5 years ago|reply
[+] [-] c-smile|5 years ago|reply
We can replace mentally any <div> or <span> on the page with <iframe src="someScriptFunction()"/>. When the application state (fuzzy term but still) changes we request these content generating functions to re-execute.
The VDOM is just an implementation detail - agreement on what these someScriptFunction()'s shall return. Conceptually they may return just html and so we can use:
can be used instead of reconciliation (diffing). Performance of such updates will be the same, if not better than React's, BTW.The only problem of element.html = ... approach is that such updates will loose runtime state. For example, if you have <textarea> replaced that way you will loose its current editing state - undo/redo stack, caret positioning, etc.
So VDOM and reconciliation mechanism is a palliative - to do not loose runtime states on updates. But, again, it is not a panacea. Think about <div contenteditable/> based editors, their content cannot be reactive in principle.
That update-only-what-is-needed reasoning frequently used by React people to promote "speed" hypothesis is a bit misleading - it was introduced for different reasons really.
[+] [-] valera_rozuvan|5 years ago|reply
Elegant, simple concepts of React - they are outweighed by the environment they live in. React allows for rapid prototyping, provokes ideas which sometimes break traditional ways. Anyways, I will leave these thoughts with saying that personally I don't have issues with it. I adapt React to what I want - it doesn't adapt my thinking ;)
[+] [-] pjmlp|5 years ago|reply
[+] [-] DeathArrow|5 years ago|reply
Even if I'd write the backend as an API without no SSR, I would prefer to write the frontend in HTML + CSS + vanilla JS + jQuery. It feels more intuitive to me as there are no abstractions to complicate things, no opinionated framework to force me do things its predefined way.
[+] [-] aylmao|5 years ago|reply
[+] [-] jarym|5 years ago|reply
I personally am not impressed with React and don’t get what all the fuss is about. We’ve had Angular, jQuery and a whole bunch of stuff over the years and each one managed to become a ‘a thing’ for a while
[+] [-] koonsolo|5 years ago|reply
I come from a game development background, and there we had Immediate GUI's for some time now (https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutor...). React basically translates this concept to the web, and does some optimizations to not rebuild the entire DOM from scratch, and only rebuild when state changes and not every frame.
Writing a 'render function' is simpler and easier than building a structure of widgets and letting them handle events. (I like simple and easy)
Anyway, it seems both react and flutter are also gaining on the mobile apps developments, and web developers are very happy using React.
Of course frameworks come and go, but React introduced a shift of mind when programming GUI's.
[+] [-] kumarvvr|5 years ago|reply
You declare how your view looks like, wire up the state and user interaction stuff and you have a self contained puece of code.
People doing UI stuff, before the advent of React usually highly appreciate it because they know how much work it takes to actually build a usable UI in vanilla JS.
[+] [-] AJRF|5 years ago|reply
[+] [-] dvt|5 years ago|reply
"Everything an HTML tag" is an insane mantra to have. As author points out, what in the world does a <Query> tag even do? It might make sense to us because we're used to it now, but the semantics of a tag is completely lost in this "new way" of using them (don't call it declarative because that's not what it technically is; it's markup). These days I'm creating HOCs on top of HOCs to support different behavior (from redux stores, to authentication HOCs, to "don't render this thing on the server" async components). It's, simply put, a terrible idea. And everyone just bought into it because the guys at Facebook must be really smart.
The lifecycle hooks are just confusing and unnecessary. They are side-effects of over-engineering. And to add insult to injury, they change every few versions (so old code will inevitably break on new React versions).
SSR. I've brought this point up on HN before, but doing server-side rendering in React is absolutely ridiculous. Every time I need to implement it, I'm constantly battling async stuff, state management, webpack/babel, hot module reloading issues, shimming `window` or `document` on the server side, etc. Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.
It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.
[+] [-] peter_d_sherman|5 years ago|reply
"The way I like to think of it in comparison to Angular is this: Angular is a framework for architecting and building applications. It, for the most part, doesn’t change the way you write your HTML or CSS, but it heavily controls the way you write Javascript.
React, on the other hand, is a library for building user interfaces. It, for the most part, doesn’t change the way you write Javascript that isn’t directly related to your UI, but it heavily controls the way you write HTML and CSS (or the equivalent of it). And this brings me to the next point…"
[+] [-] andrewstuart|5 years ago|reply
I don't use Redux or server side rendering - they're not needed.
The only thing that I think it should do differently is leave styles to be handled natively.
[+] [-] rubyn00bie|5 years ago|reply
When the only thing your application shares with its dependencies is its view renderer, you're going to feel a lot of pain. This is one of the big reasons why I use Ember.js for complex web-frontends (though holla to phoenix live views). It's a framework-- it has all them pieces you need included in a sane way that's consistent.
Just my two cents...
P.S. If you write JavaScript UI code, and you want to like be better at it, go write native UI code. You'll learn soooo god damn much, write better JS, and understand a lot more about what the fuck all these pieces (like react) are actually doing (rendering UI, managing state, networking etc) in a sane curated (thanks Googs, Microsofties, and Apples) way.
[+] [-] Scarblac|5 years ago|reply
And in practice some state is specific to some component or group of components and some state is global or the group of components doesn't translate to a subtree of HTML's tree structure. Also the kind of thing that has to happen based on what happens in the app is often deeply async.
And it all becomes a mess.
But it's still not as bad as a mess as without React, I believe at this moment.
[+] [-] ibero|5 years ago|reply
[+] [-] DeathArrow|5 years ago|reply
[+] [-] gherkinnn|5 years ago|reply
[+] [-] temporallobe|5 years ago|reply
[+] [-] programmarchy|5 years ago|reply
[+] [-] ivanstame|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]