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 can give a production example of migrating to React.
We needed to do it incrementally from a server side rendered Java application, with jQuery and a lot of custom spaghetti code.
At first we migrated the server side templates to JSX and started to use React as a library by calling ReactDOM.renderToString. The first thing our JavaScript did was render the React templates similar to using Handlebars. Then the rest of our code kicked in using jQuery bindings and it’s events logic.
Now that our templates were all JSX. It was simple that start converting leaf “components” with simple state into ReactDOM.render instead. Often needing ReactDOM.unmountComponent to “refresh” the state And rerender everything like the jQuery based code needed.
Finally, we worked our way up the stack of components so that more and more were “just normal react components without calls to ReactDOM.
The last thing we did was migrate the top level to use ReactDOM.render and we were fully React based.
FWIW, we thought about Redux but didn’t use it. We used the patterns from Redux, but felt we didn’t need a library to manage our data. This was also pre-Hooks.
All in all took 1 dev on a team of 9, that all kept working on the codebase, about 4 months working on it off and on 50% time focused on the migration.
There were no issues caused along the way, the automated tests didn’t need to be changed (except for the new features - which were orthogonal to the React migration), and customers had a (unnoticeable) latency improvement comparing the metrics at the start and end of the migration.
The incremental use was a huge reason we picked React. Not only to migrate to React but also because we can do the inverse process when we want to migrate away.
P.S. We finished this migration Jan 2019. Since then the productivity of the team has noticeably increased. Even new hire “ramp up” has been reduced with them producing production code faster, on average, than pre-React. I’m sure these successes would be true for a migration to any modern UI tool e.g. Angular or Vue.
Nah im sure if you look close into, say angular's docs, you'll eventually find out how to bootstrap their app container manually. It's usually the fact that a framework comes with some conventions that you "must" (not should) follow in order for things to work. Like having an IoC container in angular, you can't opt out that.
Excellent description. I'm going to borrow this when talking to new gophers about the difference in attitude between Go and $other_language_that_emphasises_frameworks.
Hm, I'd say in a framework you usually work with the Hollywood principle, but when using something like a library, you're not. So you're 50% correct :)
> If you call `ReactDOM.render` in multiple places
Nobody uses React that way. Besides, React is still very much the one calling you when you're dealing w/ lifecycle methods, useEffect/useCallback, suspense, etc.
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.
Its reaching the point where it is becoming standardised, and therefore not interesting, and so it must pass, and a new framework will become the one to use for web development. It's axiomatic that web development must be cool and new and therefore no framework can ever become a standard.
My impression is that for a lot of developers on HN, a kind of front-end fatigue has grown stronger and stronger. And as a result, there's a preference for various solutions that reduce the amount of 'dynamic javascript' work required.
While I'm not particularly hostile to javascript or React myself, I do notice that over time, I tend to avoid it whenever I can. It wasn't too long ago that I made (gentle) fun of Intercooler.js (what happened to that person and their tireless efforts to insert it into any vaguely relevant conversation?), for example.
But nowadays, I'm fully on the Phoenix LiveView bandwagon (React/js on the server!), and I would absolutely use Svelte or Intercooler if LiveView wasn't an option, I grumble whenever I need to deal with my js pipeline (Webpack, PostCSS, etc.), and whenever I do need to deal with it, I get an almost existential 'where did things go wrong' feeling. Maybe I'm just getting old, in front-end developer terms anyways.
All I know is that for the past year I've barely kept up to date on the latest in React (Hooks?!), CSS (grids? flexbox?), js bundlers, browser features (webworkers? the latest in LocalStorage? webcomponents?), and so on, and instead I've been dealing with databases, servers (nginx, linux, etc.), and other 'back-end' things instead.
I feel much, much less frustration because suddenly things stop working and I need to dive into the complex world of webpack and its loaders, CSS and it's various browser incompatibilities, and so on. But I also feel that the things I /do/ learn will probably be valuable for years to come.
The insane amount of stuff I've learned about jQuery is practically worthless now. The same goes for Bootstrap and Backbone.js. Or various CSS layout tricks (dear god the floats). But what I'm learning about Postgres and Ngix and Railsy back-ends seems like the kind of stuff I'll be able to use (and make a living off) for a long time to come.
I do really like TypeScript though. I'd love to use that more :).
Related question: Does it still require hanging around and waiting for an invite to create an account? If yes, then I’m not going to try again and waste my time.
I've been considering the jump into TS, but I don't want to end up in a coffeescript situation (i.e. language is dead, but code lingers on and has to be converted back to JS at some point, rather painfully). Do you think it's worth it?
Typescript offers almost no runtime behavior. With a few exceptions, everything is stripped out, and it only offers to transpile modern JS features to older browsers. CoffeeScript was all about an alternate syntax for runtime behavior.
JS isn't going to get compile time anything. There was an attempt at adding "strong mode" by one of the google / chrome teams iirc and that went nowhere.
All I really wanted was to allow type annotations in JavaScript. So you wouldn't need a compile step while running (JavaScript would just ignore the type signatures), but TypeScript could check it whenever. I believe this is the approach Python uses.
I think there were discussions of doing that at some point, but it seems to have gone nowhere.
I just switched a pretty huge project into TS, and I'm seeing for this team and project, probably 4 units of saved time in the PRO column, and 3 units of lost time in the CON column. Still worth it, but you'll need to learn and maintain a new thing, and sometimes doing a totally normal JavaScript thing would force you to write some pretty eldrich type signatures.
You may also consider Flow. It is literally JavaScript plus type annotations. The annotations can be even put into comments turning the files into vanilla JS making this very clear. So there is no danger that if FB abandons it one ends up with code that needs to be converted.
On the other hand Flow is much less cool than TypeScript these days. Plus using it for development under Windows have issues, although FB has started paying attention to them.
TypeScript annotations can also be put into comments. I like TypeScript's approach (JSDoc) better, actually, because it's how you'd want to annotate them even if you didn't have a typechecker, anyway.
Although I still hit enough annoyances that I'd go straight to `.ts` files for my next project.
We started out with Flow, but moved to Typescript not because it's "cool" (I suspect it's the Flow users who are smoking clove cigarettes in black berets), but because the language improvements and tooling support are a huge productivity boost.
The killer is how flexible it is, it incrementally scales from straight JS to full-on type religion. You only have to use as much as you find useful.
I've been doing less and less JS stuff, but I actually miss TS at times. I think it won't end up like CoffeeScript, and it's absolutely worth using if you need to write javascript!
I agree and won't repeat this point in a sibling comment, but just a slight nuance is that there are in fact some extra features/syntax TS has that JS doesn't, such as enums.
You have to be aware these features would need to be manually converted back to JS were you ever to switch back. Honestly this would likely not be a significant amount of work, especially if you don't overuse them, but just to make you (GP) aware.
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.
Your last point is a cause of some apprehension for me. In the team I'm currently working with one of my coworkers calls himself a React Developer, and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes.
I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm wrong. In these instances, I see the framework existing both in the code as well as the mind, and operating outside of it is often a leap too far.
> and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes.
this has been my experience too, I'm a full stack engineer playing a devops role right now on a greenfield govt project. Getting our CI/CD pipeline going within our environment constraints with react has been a pain in the ass. Every time something goes wrong the front end dev just kinda throws his hands up and basically tells me its my problem. I ended up having to go through all the issues opened on github to find solutions and implement them myself. I'm no javascript expert but to me the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully.
I was on a project supporting legacy code for a long time before this, and was quite looking forward to working with newer js frameworks but this left a sour taste in my mouth. And I already had a bad impression of react prior. I might look into pushing for some of the alternate frameworks out there.
There's a slew of workarounds offered in that github issue, most people (including another team in my org) opted to just rebuild the app every time a docker container is created which kind of defeats one of the major pros of using docker IMO.
> So the issue I'm referring to is this, which has been open since 2017
I probably don't appreciate the complexity of the issue, but I would say environment variables are not React's concern; it’s up to you how to architect your code. If you want runtime environment variables, then either add them to the html that React will render into, so that the javascript code can read these variables in before rendering, or have an api endpoint that your app will query before or during rendering and will get all the relevant config information from it.
> but I think next.js and nuxt.js does
Probably because they server-side-render. And even if your app renders on the client side; even if you don't use next, nuxt or whatever, there is no-one stopping you from dynamically serving the html skeleton with the relevant variables in it.
But then, it all probably has been mentioned in that issue. I wonder why it wouldn't be a good solution.
> but I would say environment variables are not React's concern; it’s up to you how to architect your code
I don't consider it part of the "code" but part of configuring the application based on the environment you're deploying it on(Precisely why the FE dev basically said its not his problem). The fact that a lot of people are suggesting you just build the app every time you deploy a docker container is really concerning to me.
> I wonder why it wouldn't be a good solution.
it just feels dirty. it's the fact that I have to add these into the code that it feels like a hacky solution for a production app. using a shell script to read read the OS environment variables to create an ENV file then convert that ENV file to a javascript file that is then read, it seems like many things can potentially go wrong.
Ideally they would just deal with this within the dotnev library
Dotenv runs on the server. If a part of your application also runs on the server (such as with Next, Nuxt, etc.), and your responses are generated dynamically, then it is trivial to use the dotenv. If, however, the runtime of your application is confined entirely to the browser, and what you are serving to the browser is only static assets, such as with create-react-app, then, if you still want your environment variables to be defined at runtime rather than at build time, you need to design a bridge between your server and your client specifically for injecting the environment variables.
Here, for example, is an article describing such an injection at the nginx level: https://medium.com/@jans.tuomi/how-to-use-environment-variab.... Or you can serve index.html using a full-fledged dynamic server, such as Node, and inject environment variables there (and probably cache the response for good measure as well, not to overstrain Node). This really is not something that is React’s responsibility — although it may very well be the responsibility of the frontend developer to set this all up.
yep i know how it works after looking into it since I didn't know anything about react before, just makes me not want to use react or vue for any enterprise level software.
All those solutions you mentioned I've considered and are mentioned in the github issue. I just think its way too much work and overly complicated for what is basically a prototype. Which is why I opted for the simple hacky solution.
> This really is not something that is React’s responsibility
This is why I'm already pushing for our team to move off react I don't think its the right fit for us. We also don't like JSX
Personally, I'm super wary of any ____ developer. It's a fixed (vs growth) mindset that tells me they are specialists. I think specialists are best to be consulted by generalists, but not trusted with larger decisions outside their scope.
This is usually a smell that the person is competent at what they do, but doesn't know what's going on under the hood. Funny enough, I'd rather work with someone who doesn't know the specific technology, but knows what the language was built on top of, because they'll have a better intuition for how it actually works and be able to learn it relatively quickly.
I'd rather work with someone like that, too. All is well and good when one can crank out React components, but if that same person doesn't know how to find, for example, the tag name of a element from an event handler, a little red flag goes up for me, and as you said, probably doesn't know a great deal about what's going on under the hood.
I agree. Though this person can be a bit touchy when constructive criticism is aimed at them, this would most likely be beneficial for them, and also the team, in the medium/long run.
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.
I don’t think it’s necessarily success, but novelty. C++ and Java are immensely popular and get nowhere near the vitriol that the thing you mentioned do. Often there’s a number of people on the opposite side cheerleading the thing as well, which underlines the apparent conflict. (Rust is already being complained about, by the way.)
That's true because the more first-mover-y languages that came to dominate are shit compared to subsequent, more innovative ones.
When the latter become dominant, there should be even more subsequent, innovative ones.
And the cycle will repeat.
But it's less net shittiness with every generation. And how many generations are we even in so far? C is '70s security gore, C++ is an '80s attempt to force OO memes that we've come to regret onto the '70s security gore, Python and Java are '90s OO memes in earnest, JavaScript and PHP were kludgy mistakes slapped together in a fit of desperate confusion to get some web shit to run, aaand...
As a C++ developer who occasionally helps a friend hack on a Rust hobby project, I've been waiting for the other shoe to drop on Rust.
Not necessarily because I have many complaints about it, but because I consider it in essence very similar to C++17, with (not-too-)different syntax and a few different but important design decisions in the core language and standard library. Seeing it sold as a radical paradigm shift from C++ has always left me feeling that some people are in for disappointment down the line.
C++ has no notion of a borrow checker and I am not aware of static checkers for the language that provides a coverage close to that of the Rust compiler.
As I continue to see how very experienced C++ programmers make exploitable bugs that passes all reviews and that are compilation errors in Rust saying that Rust is C++ with a different syntax is very naive.
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.
Best summary of the state of react I have read so far after programming with it for 2 years. You should write an article about it!
Stuff like this is rarely part of the sales pitch for any framework. You only find out after being locked in neck deep. Still from all the browser gui frameworks I think react is the safest choice.
Why? Well it is reliable and scalable enough and create-react-app makes the whole experience acceptable. It will not get you into trouble.
Choosing any of its non-mainstream competitors might get you into deep shit if the project fails.
Choosing any of its mainstream competitors like Vue or Angular seems like not a big improvement over react (if it even is) and will make you go into defensive mode anytime a junior dev knows that feature x would have been easier to implement in react.
React native code re-use is possible just not in the way people imagined. You can reuse your Redux code, you can reuse higher order components you just can't reuse the atomic UI elements.
React native performance is good too it just doesn't come for free. You need to know how to do native animations and you need to do late binding and all the other performance optimisations you should be doing with React anyway.
The only thing that lets React Native down is the tooling. I've had the debugger repeatedly push stale code on refreshes, the source mapping is atrocious and sometimes the network debugger just refuses to work. Also sometimes the app fails to load and you need to reload the app and or restart the debugger and or restart the packager in the right order.
Is React Native performance really good? Compared to what?
I've found RN performance passable but underwhelming. It seems generally worse than a good native UI, and no better than a mobile web UI.
I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and leads to unavoidable glitches in native widgets used as controlled components.
Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.)
> Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.)
My experience was that RN was way more helpful on Android than on iOS, in general. But that has more to do with Android than RN, which achieves its utility on that platform by papering over a pile of bad decisions, inexplicable awkwardness, and half-finished-apparently-by-the-Summer-interns APIs, none of which should be problems in the first place. I'd seriously consider using it for just for Android even if I wrote a separate, native iOS version of the same app.
The JS is run in a separate thread because the real-time operations are meant to be handled fully native. If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. You can't code it like a web app where you just replace one large node tree with another if you want it to be instant, you have to mount both and keep one invisible, either using a navigation library or custom code. This way layout changes are smaller packets so it doesn't saturate the low bandwidth of the thread bridge.
The extra latency for a layout change is most noticeable if it's an animation hence why you should use native animations not JS polling animations. I agree the Animations API is not as easy as CSS. If you want to do complicated stuff you need a lot of experience with it. This is one of the major hurdles for new RN devs.
Its possible to get good performance our of it, better than mobile web UI, you just need to have some experience with what costs and what doesn't.
> If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong.
I’m working on an alternative to React Native that does exactly this, and it works absolutely fine: React NativeScript.
In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated.
If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong.
If I'm coding in a style that works fine on web, and also works fine in native code, but is slow in React Native, then I'd suggest I'm not the one doing it wrong, it's React Native itself.
This way layout changes are smaller packets so it doesn't saturate the low bandwidth of the thread bridge.
Even if they were to stick with the multithreaded architecture, it should be possible to build a layout structure in the background thread and just hand ownership over to the UI thread. I believe the RN team are working on doing this with their new Hermes runtime (sharing objects directly rather than marshalling them into and out of the JS engine), so that ought to help a bit. But I really think the threading model is just wrong-headed in the first place.
Its possible to get good performance our of it, better than mobile web UI
Is there a case study or even just an example that demonstrates that? I'm skeptical. Mobile browsers are very fast these days, so there's no obvious reason why RN should necessarily be faster.
I suppose RN might have an edge if you're making extensive use of native code. But then calling native code from RN is very laborious, so RN doesn't exactly pull its own weight in that scenario.
There are no benchmarks I know of, it's accepted wisdom that React Native is faster than mobile web even when not optimised and comes close to native when optimised. That has always seemed self evident to me but maybe it's time someone did some benchmarks.
I think the reason RN is faster is because mobile browsers have to support decades of crufty CSS in their layout engines while native layout engines are much more lean and ripe for optimisation. React Native uses Yoga layout engine so there may actually be benchmarks available on that.
> I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and leads to unavoidable glitches in native widgets used as controlled components.
Totally agreed. I’m working on an alternative to React Native that addresses exactly this: React NativeScript.
In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated to begin with.
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.
Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge to rewrite a complex REST react app to GQL, since you'd be discarding a ton of data shuffling code, but we've been happy with the resulting simplification of our frontends.
I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest.
For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux.
In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer.
I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested.
The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy.
In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.
> For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it.
Apollo is for GraphQL. I'm not sure why you'd try to use it's internal caching system to add local application stuff. Note that using Apollo does not stop you from continuing to use Redux.
> The Query component can be fine for simple use cases, but it still ties your API calls directly to your component.
The convenient thing about the Query and Mutation components being in your markup is the access to the loading and error states within that context. With Mutation, I often end up just passing the mutate callback to an event handler method. There's always direct access to the client when you want to make normal procedural API calls.
The Apollo caching system hasn’t been all roses; it can be pretty easy to wipe out parts of a cached entity you were needing on a view with the response to a mutation on a different view if you’re inconsistent with query and mutation response structure. But I find it convenient after getting the hang of its pitfalls.
> 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.
Hooks definitely lead you towards a different approach for writing components with a different set of tradeoffs. I talked about this in my post "Thoughts on React Hooks, Redux, and Separation of Concerns" [0], and my ReactBoston 2019 talk on "Hooks, HOCs, and Tradeoffs".
For React-Redux specifically, `connect` still works fine and we will be supporting it indefinitely. However, we're now recommending that people use our hooks API as the default approach, because it's typically simpler to work with and there's less indirection.
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.
This was my first thought, but the parent comment is probably referring to the comments that were on top at the time it was written, rather than the article (which I agree, is fairly mundane, although I think it’s fine.)
Most jokes I see are downvoted and I can't recall seeing a single joke comment. That's not to say there zero humor here, just much much less than other less serious discussion forums.
Well being nice and polite is part of the guidelines here, which is not such a bad thing.
But the pretentiousness annoys me sometimes, at the end of the day it's another forum of people who don't think they're part of a hive-mind... which we definitely are
if only, for all their sins (which are lots) 4chan is a very fascinating place. The other day I was fantasizing (lol) about giving a talk to out-of-touch academics/journalist boomers and explaining them the 4chan phenomenon.
There are lot of very smart people there. You compare the recommendations in music/books/cinema between them and reddit and it is "People" vs "Cahiers du Cinema".They tend to create lots of Internet culture, the humor is caustic but it can touch genius from time to time and they are very open regarding topics like sexuality,depression, economics and so on.It is proof there is always more that meet the eye.
>You compare the recommendations in music/books/cinema between them and reddit and it is "People" vs "Cahiers du Cinema".
My point is there are affectations in both communities (4chan and HN) that are strange opposites of one another. Here, people often pretend to be more polite and erudite than they are, there, people often act more rudely than they normally would, because that's the culture, that's the mask you're expected to wear.
And on both sides there's a pretension which you're kind of displaying. You're talking about a site as vast and varied as Reddit as a whole as if it were a single forum, and dismissing it as qualitatively lesser than an anonymous imageboard that has shitposting as a central part of its identity. Find some well moderated subreddits for any particular genre and you'll find quality of conversation equal to anything on 4chan, or even HN.
Also, you know, 4chan has been around long enough at this point that a lot of "out of touch academics" and "journalist boomers" have probably been there.
On the contrary, that is the refreshing part of 4chan, the unpretentiousness, a guy can talk about Nietzsche using memes and somehow make a good argument. Reddit is pretentious without any reason for it to be, at least here in HN there are competent people. And I was comparing the lists of recommended books of r/books vs its equivalent in 4 chan, as far as an apple vs apple comparison goes.
I'm not sure if the stuff I see in HN threads qualify as hard feelings. They are more like jabs, prods, cheap shots, demands, begs and lots of bikeshedding with a smither of useful information here and there. I do appreciate the fact that they try to discourage the reddit style of rimshotting.
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 design all the declarative things you want, but someone will eventually come up with a requirement that doesn't appear to fit a declarative structure, such as an event that fires 2 seconds after something else happens.
And so to resolve that you can construct state machines with transition states to get back to a declarative model, but those state machines can quickly become a bigger headache to maintain (yes, even with redux) than if you'd just been able to setTimeout from the component in the first place.
And you start with the best of intentions of re-usable components but find more things that ought to be owned by the component pushed up to the store and suddenly there isn't a neatly re-usable component but an empty shell of something that still needs the other half plumbed in manually every time.
I love the idea that you can abstract everything happening in an application to state and render reproducibly from that, but the reality is that it's really hard and time-expensive to do compared to jquery.
But that would be fine if the tooling was there. If React had a CLI like the AngularCLI it wouldn't be such a problem to add new actions, or new pieces of state, or new components.
But it doesn't, so each new component ends up adding a little more state into the state machine which ends up breaking types in far off places.
Now there's probably an assumption about how state is built up or how reducers are typed or how actions are defined that I'm missing some reason why this shouldn't be happening. But it is happening, it's the reality for the project I've been working on and it's a real headache.
I’d use an event handler to work out when something happened. This would set the timeout, and the handle would be stored as a ref. I’d have a use effect hook to clean up the timer, so when the component is unmounted the timeout is cleared.
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).
If you want to use the javascript components, rather than just the styles, you need the react library version. There are various other UI libraries as well that require you use the react conversion library, which sadly lag behind the vanilla js versions.
Fair enough if you love react then this is acceptable. But it pushes the definition of a library, when just using react means that other libraries need to conform to react to properly work with it.
React does some things nicely. But it's not "It's just a library. Drop it into your existing project. And you're done."
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.
Adding to this, hooks make it much easier to pull related state management code out of the component. They help make state logic just as composable as UI logic.
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
My superficial understanding is that React components as classes are far more complicated than they might seem at first. You're not in control of creating the class instances, rendering them or destroying them. React is in control of that.
The constructor is the wrong place for data fetching in React class components as far as I remember anyway. I don't remember the exact reason, but it always has been somewhat non-obvious and you always needed to understand the React lifecycle to avoid bugs in that kind of code.
Classes in React are confusing because they aren't actually classes, just something shoehorned into classes. For example you wouldn't write your initialization code in the constructor, you would do it in componentDidMount.
Yeah but how is that different from any other UI framework?
onCreate/onStart/onResume and onComponentDidMount, onPause/onStop/onDestroy and onComponentWillUnmount are basically the same. Be it Android, Swing, or Qt, everywhere it's the same pattern.
React is the first framework which actually feels like UI development on the web, not anymore like JS spaghetti.
In fact, having internal state, externally given props, exposing events, and being declared through markup is exactly the same between React, Android or Qt.
The only thing React brought to the table was allowing you to basically just recreate the children every time something changed, and it'd diff automatically.
For us native devs this thread is hilarious, because it's just JS decs complaining over things we've always done
> JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.
You've been tricked into thinking you're using a class, but you're really not. I understand it's a useful trick, but hooks are more idiomatic for JS as a language.
I disagree. I think that's like saying C++ doesn't actually have classes, it's just syntactic sugar around structs of function pointers.
It may be technically correct, but C++ and now JS have a "class" keyword for a reason, and that's to steer you towards organising your code into classes which operate in certain ways. In both languages you can avoid using classes, sure, or abuse classes in various ways. But fundamentally they do have classes.
> steer you towards organizing your code into classes which operate in certain ways
But that’s the point. The way in which classes operate in JS is different from the way classes operate in OOP focused languages like C++, Java and C#. That’s because the language doesn’t have classes, but rather syntax to make it look like it does. On the surface your code will be organized in similar ways but the underlying behavior is different.
But what good are classes if you're not doing object-oriented programming? React classes are just stateful wrappers around a pure render function. It's not idiomatic and frankly dangerous to do anything you would with a regular ES6 class with a React.Component.
Can you clarify on that last point a bit? Not that I extend React.Component these days, but far as I'm aware, the only "gotcha" of React.Component (vs other classes in JS) is that they shouldn't be extended.
I guess, yes, there's different semantics between the constructor and componentDidMount, but it's UI library, this is common that "when a constructor is call there is no guarantee the component has actually mounted".
Sure, what I mean is you'd never use a React.Component like you would a class in Java or another OO language. You never instantiate it, pass instances of it around, or call any of its public methods. It serves just as a container for some functions and provides a binding for `this`. Dealing with `this` caused things like componentWillRecieveProps to be buggy so hooks allow you to use a function as the container and remove the need to reference `this`. The move from classes to functions was not a paradigm shift just a different implementation of the same approach.
Actually, you can pass instances of it around just fine, if you know how it works. It’s not any different than a view subclass on Android, or a widget in Qt.
Instantiating it does nothing useful, though. `React.Component` is basically an empty shell with a marker flag on it so that the React renderer recognizes it, and the `setState` method just delegates to the actual renderer implementation. There's no reason to ever instantiate it yourself.
But that's the point. All UI frameworks are like that.
You can't `new MyRecyclerView(...)`, you've got to `LayoutInflater.inflate(MyRecyclerView, parent)`, which isn't any different from `React.render(MyApp, parent)`.
> as I'm aware, the only "gotcha" of React.Component (vs other classes in JS) is that they shouldn't be extended.
Facebook recommend composition over inheritance, but you can totally extend React.Component and even get abstract classes involved. In my custom React renderer, all the components in the library are based off React.Component class inheritance.
I think lifecycle methods in general, no matter what the framework is, are a suboptimal way of doing things. React works quite differently and shoehorning it into a lifecycle thing was holding it back, or at least that's how I feel. YMMV.
At least it looks like we agree that React is a decent framework :-)
That said, for us devs who do both native and JS code, the condescending part is quite hilarious as well ;-)
I'm doing JS (vanilla and with React), Android and native (well Qt) myself.
It's just funny when pure JS devs go all "no you won't convince me to compile my code / use classes with lifecycles / etc, that's against the natural order!!!"
I remember ASP.NET Webforms, and the reason most of the community moved towards MVC-ish frameworks is exactly that most of the time, you ended up shoehorning functionality into different lifecycle methods, which made them much harder to reason about. Most of the time, for anything more complex than just performing the initial databinding, you'd just be looking at the lifecycle chart and trying to figure out which place would be best to put which part of your code. Page_Init? Page_Load? Page_PreRender? I remember the pain of trying to add dynamic controls to a site right in time before ViewState was hydrated but AFTER something else had happened.
I agree that for the easiest of use cases, lifecycle methods make sense. But you very quickly leave that comfortable zone and then it just becomes painful and confusing.
Don't worry, I'm not espousing lifecycles as a panacea or solution for the modern programmer, I just wanted to share that experience with lifecycle methods meant that I was less tripped up by the pitfalls of react lifecycles.
Less so than I've been tripped up by react hooks certainly so it's been a surprise that many here are describing them as being much easier and simpler than classes.
Classes had limits and some pitfalls but it's been frustrating that lifecycle methods have been retired and deprecated because sometimes they felt like the natural place to do something.
THIS is what I wish I knew about React. As a Java user, I made incredibly wrong and damaging assumptions because "classes, I know what these are"! I still can't make heads or tails of hooks, but in due time!
Imo, hooks present an API that is much less difficult to internalize, but maybe holds your hand less? I used react for a few months on a sideish project and had trouble knowing which component method I needed for something, whereas with react now it's all covered by hooks.
Class components feel like a spaghetti mess to me whereas Hooks are obvious, straightforward, and clean. I understand that others feel differently but I personally cannot stand working with class components.
Hooks don't change the meaning of const. The whole render function is re-run each time something is modified. There is ZERO internal mutation going on in render functions.
I suggest researching and learning how something actually works before calling someone else's work a "dirty hack" or "f'ing joke".
(And afaik hooks were Sebastian Markbage's idea... f'ing genius if you ask me)
const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change.
const is not "constant".
In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.
The fact that `setState` modifies state outside of the local scope does not mean that a local variable is not const. This is really basic programming, it doesn't have anything to do with React.
Here's the exact same scenario without React to show why you're wrong in your original comment:
Imagine that this is a typical database where values can change, so that every time `foo()` is called, `bar` can have a different value. Do you think that this is a dirty hack that is overruling the const type declaration as well?
No, it's not. React is iterating that piece of code of your function internally to modify the value of the const, there is no other way to do it. And it is especially confusing because you can use that const 'variable' in the scope representing a changing value. And the change is magically made by its 'setState' method.
If you do this yourself in a loop then it is of course totally clear what's going on, but now we're writing functions where parts of it are being iterated by React, and that's not functional at all, IMAO it's a hack.
React does not "iterate over parts" of your functions, it simply calls the entire function. There is no magic happening.
You've already received a lot of responses explaining how both const works (which you still seem to misunderstand) and how React works, I hope you can take this as an opportunity to learn and perhaps not be so confident in the future when criticizing something that you clearly haven't taken time to even understand at a basic level.
`Foo()` will be called on every render, `useState` will only use its argument the first time it's called (and then after that just remember its value), and `a` will be a "new `a`" every time, after which, like all variables declared in a function, it's discarded when the function returns.
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 just can't get myself around to use anything by FANG just due to their licenses.
Using a framework means your project will never purely be yours.
React license:
> The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.
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.
React introduced this concept ‘to you’ perhaps but it wasn’t the first. The framework I used has been doing this in the very early 2000s.
Don’t get me wrong it has a lot to like about it - but the only revolution is that Facebook’s might propelled this in the minds of developers all over.
Just curious, which framework are you referring to?
Every time I see someone claim such a thing, it's usually only distantly related. Like it too has a render() function.
I mean, you can find old FRP phd/whitepapers but I don't think they prohibit you from ever saying "$X introduced $concept" without a disclaimer that it wasn't the first. So if you're going to insist, then why not share some prior art for the discussion?
I started my career in 2002 (been programming since '93), and back then there was no client side rendering. So my guess is, he's talking about server side rendering that spits out html.
Since those things really miss the 'react' part of React, it is still quite different.
I used SmartClient when it was launched in 2002 and that did client-side rendering back then: https://en.wikipedia.org/wiki/SmartClient - I've recently taken the JS version (not GWT) and ported it to a set of ES6 classes and modules.
I used to work for a portal vendor called Plumtree in 2004 (later acquired by BEA and then Oracle) and much of their stuff did client-side rendering.
The idea of making web interfaces more declarative and less tied to DOM manipulation has been evolving since then. Many developers I'd encounter back in those days moaned that we were not using jQuery or MooTools or whatever.
React is very nice - don't get me wrong - but its popularity has much to do with the mindset of developers shifting away from seeing JavaScript as a way of 'adding spruce' to 'web pages'.
The revolutionary part of React is not client side rendering, it's the composition (and reaction) of GUI through state changes.
A quick look at SmartClient shows that it still uses the old OO way of widget composition (widgets having .show() and .hide() methods, etc). This is not at all how React works. In react you render your GUI based on state, and events never manipulate widgets, they manipulate state. It's a functional way of approaching GUI's instead of an Object Oriented way.
The React way of building GUI's is now used outside of the web, for mobile apps through React Native and Flutter. This is completely different that any pre-existing GUI frameworks.
It does have show and hide methods - but inside the framework it is deeply compositional. If you have a chance to look at the docs search for ‘autoChild’ which achieves much the same as react and co but using different terminology.
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?
React's marketing (such as it is) has pushed the "it's just a library" and "it's just the V in MVC" hard. I think folks can be forgiven for thinking those notions won't entirely fail to describe the real world experience and use of React in ~100% of actual projects (and even more so now that ditching legitimately-actually-quite-portable Redux for hook-centric logic is trendy) and being a more than a little surprised and perplexed when they do.
(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.
I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience.
With Hooks I’m happy in that most of the “business logicky” stuff can be split out into those and my components have returned to being pretty much entirely UI code - I don’t really use any of those weird in-between tags like <Query> anymore.
Transpilation will happen if you want to use new JS features at all. If you use React without JSX and not using any ES6 features, then you can certainly support old browsers without those transpilation steps - just include the compiled CDN-distributed script in a script tag like jQuery, it’s even advertised in the React getting started docs. Just turns out nobody wants to do that.
I agree that SSR is a crazy story though and I hope someone makes something better - but jQuery doesn’t really help with that at all, bootstrapping state from a different machine than the runtime and not incurring state weirdness/security vulnerabilities seems like a generally difficult problem, not a React-specific one. NextJS (and maybe prerender snapshotting) seems like the only decent options right now.
> I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience.
Respectfully, that's not at all what HTML is supposed to be, but even so, as it turns out, sometimes you do need state to drill pretty deep down (say you need an icon to be green if you're authenticated). So people started just passing state as props everywhere, but oh no that's an anti-pattern. So now people are using redux, mobx, or the context API to do essentially the exact same thing. Three new tools were developed by dozens of engineers to basically re-invent "global state." It's ludicrous.
If you want the hypermedia-concept of mostly static documents with links to each other, feel free to turn off Javascript or not use React.
If you’re using the web as an application delivery platform that works cross platform without installs and instant updates, then HTML is the base of your UI framework, and as such it helps to have predictability that frameworks like React offer.
Re state, for me the “bad thing” about global state is usually the same “bad thing” about jQuery-based apps - that anything can mess with anything. But all the solutions you mentioned, and especially the Context API, force components to declare their dependencies and update shared state in restricted ways, which makes that “bad thing” much less bad.
If you don’t like shared state at all, feel free to not use any of those, and pass around state throughout the app - but don’t complain to me when synchronizing state throughout your web app becomes a problem, or that boilerplate becomes a drag, because those are the problems these solve.
Let’s put it straight: HTML is a Hypertext Markup Language by definition, it’s not an application UI markup language. We are living in a very confused world where inappropriate standard is used just because nothing better got sufficiently big market share. ES, TS, CSS, all the libraries and frameworks in the ecosystem are all just attempts to make the whale fly. For last 20 years we should have been focusing on building semantic web on HTML, while RAD tools should have been standardizing APIs and UIs across platforms on different, probably similarly looking standards (I’d prefer seeing there some DSL with C-like syntax). Unfortunately we have to deal with what we have - jquery, React, Angular etc, the tools that have not invented anything that we haven’t seen yet, but which pretend to be a silver bullet for solving complexity which should not exist in the first place.
Totally agree! Additionally I think it goes beyond HTML, it is also HTTP protocol that has been bent and hacked to make proper event-based UI to work with (originally) stateless request-response concept in responsive and secure way. It often deeply frustrates me when I find myself struggling to solve some stupid problem that was completely non-issue 20+ years ago when I was writing applications in Delphi on Windows 95. What happened, guys?
Browsers also don't provide the necessary tools to actually build interactive UIs without reaching for external libraries. If you want to allow the user to select date or time in a decent user-friendly way... you just have to pull some JS thing in. Dropdowns/select boxes still only provide the most basic capability; multiselect sucks, need to pull in another JS thing. The list can go on.
Even if your application is 90% non-interactive, the remaining 10% could end up introducing a lot of complexity only because browsers haven't advanced on that front at all in the past decade. And that 10% could easily outweigh the 90% when it comes to the architecture of your application - you get frustrated with the jumblefuck of JS littered randomly around to support X feature on Y page and so you just grab React and build a more manageable thing with it.
The standards committees for the Web have seriously dropped the ball.
It would be a strange choice to not use the best tool for the job because one of the acronyms that’s related to that tool stands for something that for historical reasons doesn’t precisely describe the job.
> using the web as an application delivery platform that works cross platform
Therein lies the problem, understandable as it is. If you're using React (or any other modern UI/MVw/whatever for that matter), you're still describing your app as mutating a grossly inappropriate scene graph of divs and spans held together with CSS tricks when your conceptual model is probably more adequately represented in terms of panels, fields, and canvases. On top of that, you pick about the weakest language out there, and over the course of decades, morph it into becoming more like a real programming language with runtime type info, accidental async patterns, decorators, compilation pipelines and whatnot, giving up the two benefits that JavaScript has, namely ubiquity and running OOTB on browsers by simple page reloading.
I don’t understand. Prop drilling or global state libraries like Redux don’t change the fact that the HTML of your site is a function of its inputs. Those are just two different ways to implement this concept of the HTML being a function of inputs.
Use your example of the icon that’s green if you’re authenticated. With React (regardless of whether you’re prop drilling or using something like Redux and context), you just update your state with isAuthenticated: true and the changes to green. There should only be one way to set that Boolean, and the icon will update regardless of where that Boolean is set. That’s all that’s meant by this concept of HTML being a function of inputs.
The SSR data fetching story really isn’t much different than the story for managing global state in React on the client.
It’s true than a client-side React application could just do AJAX requests on component mounts (or in a useEffect hook) to keep that data in local React component state, and that wouldn’t easily translate to React SSR (because the server renderer can’t know when your component tree is “ready”).
But most complex app-style web sites are already going to need some global state management similar to Redux, where data fetched from the network is stored not in local React component state but in a global store, and when you have that (as well as a JS router, something else you’ll probably be needing anyway), the React SSR story really isn’t that crazy at all.
There’s other problems too - all components need to be runnable serverside (which adds complexity to otherwise simple operations on the dom), forcing yourself to put all state into a redux store even if you’re not planning to share it is more unnecessary boilerplate/overhead - and there isn’t any clear canonical way to achieve this for arbitrary apps.
I’m finding it tricky to implement cleanly in my company’s fairly large React codebase, though I do think the fundamental problem is not a simple one and requires tradeoffs.
It’s true that there’s no official React guidance on doing this, and doing so would probably require official React choices for routing, global state management, etc. which the React team is clearly not interested in doing.
But there are popular frameworks like next.js that have pretty simple patterns (like getInitialProps) that can probably be adapted to any React codebase.
I don't really understand why suspending server rendering to load data is still an unsolved problem for React. Ember figured this out 4 years ago with FastBoot.
It’s not an unsolved problem. There are very many React apps with SSR, and popular frameworks that use React and provide straightforward SSR data fetching patterns.
> 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.
I think everything in this sentence is incorrect.
jQuery started out as syntactic sugar to smooth over the cumbersome and inconsistent DOM manipulation APIs in various browsers.
No one ever seriously says React is a replacement for jQuery. It was a replacement spaghetti-and-meatballs on top of jQuery, Backbone, Knockout, Angular, and whatever other frameworks were popular at the time.
> 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.
This has nothing to do with React. To get a sane dev environment, you have to do these steps even for a simple site. It's a consequence of browser standards moving slowly and of JS and CSS being awful.
If I can't write front-end code (even for a simple static site) with a decent Webpack flow, TypeScript, and SASS, then I'm doing a lot more work and delivering a lot later. Those tools can be buggy, but most of the time you can just stick with some boilerplate and not end up with anything terrible happening.
> Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.
You can still do this with PHP (or any other server-side language). It's still a first-class citizen of the .NET world.
Agreed with this - I think it all stems from the browser standards issue, which to me is a general issue about distributing control. It’s design by consensus, which naturally takes a long time, and forces updates to web standards to be conservative and backwards compatible in perpetuity to support every random stakeholder, which is a great recipe for a bloated and abused platform.
So at the core I chalk the situation up to people problems, not technical ones.
> "Everything an HTML tag" is an insane mantra to have.
I don't think this is a React mantra at all. Maybe "everything is a function" would be a modern React mantra? Seeing how React code is mostly hooks and components, and both are nowadays generally written as functions.
JSX is not even required when writing React, by the way. It's just syntactic sugar.
> 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.
There's nothing about React that requires this. You can simply include the react.js script at the beginning of your HTML document and write all the React code you want, no transpilation required.
If you want to use JSX, then you need transpilation, but again, JSX is not required to use React.
You seem to confuse "normal" with "required". dvt (correctly) states that "it's normal now to have like 3-4 compilation/transpilation" which is indeed true for most React codebases (open source and not) I've came across. In fact, I don't think I've come across a single React application that is seriously built without using JSX and without a bundler (like including react.js in the beginning of HTML).
While not required, most people use JSX + bundler, at least for anything that resembles a serious application.
People who use React tend to want to use modern browser capabilities - and anyone who does will need transpilation because browsers have different API support - the cost of not having an all-controlling monopoly.
People developing on other platforms love to complain about the build tools on the web, but those same people only have the luxury of simpler build pipelines because they have greater control over the machines their code will be run on.
I don’t see React as having caused this problem in any way (feel free to include React via a script tag from a CDN and worry about the compatibility of your code yourself), and I also don’t see this as a problem that will go away any time soon for web development.
That all said, I do think it’s getting better - all the major browsers have switched to be auto-updating, so it’s feasible for many projects to drop support for IE altogether and only support ES6; if you manage your CSS in JS, you don’t need to downcompile languages like SCSS; the two of those together mitigates a lot of the need for sophisticated build tools.
Those two commands are not just "zero config and two commands", think about the entire stack you're pulling down behind the scenes. Sure, it's easy when you want to render "hello world" but there is so much context and abstraction happening here, that is hidden. Then we haven't even started thinking about HOCs, SSR and lifecycle hooks, none of them addressed by your terminal snippet.
Actually everything is done after this. This is the way I am building a huge SaaS project. Of course it downloads some code, or would you argue that using Javascript is not simple because it needs to run in a browser? Server rendering is trivial to set up with Parcel, but I don't see the point of your remark - you don't have any option of server side rendering with Jquery.
It adds complexity. Software rots faster. You are more likely to git clone a 7 year old front end project and be able to run it successfully than a 7 month old project. It’s hard to find projects that successfully pin versions down so that you can build them after regular work on them has stopped.
I have projects from 7 years ago that got dependencies stuck on an old major (that's the default) and the webpack I put there in 2013 still successfully builds. The original versions are noted in package.json, so all you might need to do is fix it to the minor/patch (1min task with search/replace). I wouldn't be afraid of parcel - you can do the same thing.
If you don't want to use any of them, convention is to use:
const h = React.createElement;
I don't know of anyone who actually uses `React.createElement` directly.
Personally, with all the other things needing a transpile step (TypeScript, and support for older browsers), I've just gotten used to having one in every project nowadays.
Hooks, to an extent, improve some of your complaints. For example, with hooks, lifecycle methods are gone and you’re forced to use “useEffect”. This helps you rethink if you needed that side effect in the first place. Additionally, it allows you to remove HOCs. Today, I just refactored a lifecycle-side-effect-filled HOC into a simple hook and I think it reads much better. Plus, it doesn’t confuse the fact that the hook has nothing to do with rendering and so it doesn’t abuse markup tags.
> from an architectural point of view, jQuery is by far their superior.
What do you mean by this? The architecture of the sites I’ve worked with has been much improved by React. jQuery mostly seemed to be used for direct, script-style dom manipulation, which you can do with plain JS these days. You did it in so many places across your app that it was impossible to tell what caused what change and it isn’t immediately reactive to data source changes either. So from an architectural point of view, it certainly didn’t help your code. React is solving a problems that jQuery doesn’t claim to solve.
If you’ve got a basic website that needs a tiny bit of interaction, definitely use plain JS. But if you need to build software running in the browser, you’ll run into the kinds of problems that jQuery and plain JS don’t solve out of the box. If you don’t use a modern library, you may end up writing your own state management and reactivity later anyways.
I’m glad I made it to the end. Why use React for a simple JS-based app when you’re very aware of many reasons you don’t like it for this purpose? If you’re being forced or pressured to by an employer or even the entire job market, that’s not really React’s fault other than for existing.
React (at least many of the features and use cases you mention) is for complex applications and developers that care deeply about the hairy details of user interfaces. (It’s also pretty easy to use without a build step for simpler applications, but that’s another argument.)
Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.
I started my career with jQuery, and soon after moved to Angular v1. There was nothing simple about those tools - the mental models involved were complex, different parts of an application were difficult to isolate from each other and optimizing performance was a nightmare.
Compared to all that, React is ridiculously simple - it has a very small API surface, different parts of your app are isolated by default and performance optimization is generally very straightforward. As somebody who really loves simplicity, React is by far my favorite UI library at the moment.
I think when people fondly remember simpler times with jQuery, it's not because jQuery itself was simple, it's just that they remember working on less complex applications.
When people say "web development used to be simpler", they're probably not referring to the front-end tooling (which has certainly improved) - but when most of the functionality of web apps were built and rendered on the back end, with new state being displayed after full page refreshes or simple AJAX calls.
> when most of the functionality of web apps were built and rendered on the back end, with new state being displayed after full page refreshes or simple AJAX calls.
Most websites (including this one for example) still function that way. It works fine. JS frameworks simply are not required for most of the work the web does nowadays - you can add interactivity and immediate feedback where it makes sense very easily with vanilla js.
Certainly, the software we write for the browser is much more complex these days. Sure, plenty of website don’t need react and shouldn’t use it. But many of us find react very useful because we are building software with similar creature parity to desktop apps, which wasn’t the case in the early days of the web.
Not only that, but the “simple sites” that used to need a dev to build (like for a local restaurant or business or something) can now be done by the restaurant owner on WordPress.com or Wix or something without much effort
It’s not more difficult now to make dynamic server-rendered web sites than it was 10 or 20 years ago (I don’t know about PHP these days, but it’s never been easier to start a new Django or Rails app), but your clients will probably want features they’re accustomed to in modern web applications that are not easily implemented in server-rendered web sites.
None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.
I sincerely think that dichotomy is not a useful one - that's not a choice you have to make. You can have server-rendered apps with significant interactivity (where it makes sense).
Many large websites still use server side rendering (in whatever language they want), and js to refresh data client-side as required and respond to user actions, pulling data from the server side. There is no need to attempt to move everything to client-side, it doesn't make the UX better IMO, sometimes it makes it worse.
Keeping most logic and templates server-side works just fine on large complex sites serving millions of people, and it's significantly simpler and more stable for development than react or other frameworks, which seem to be in a permanent state of flux.
I should be more clear. I mean the dichotomy between a web site that is only rendered on the server (which is not more difficult to build now than it was 10 years ago), and web sites that have significant client-side interactivity (which are usually and understandably more difficult to build than the former).
Of course, there are different versions of the latter: you can have an entirely client-rendered site, or a site that runs largely the same client-side code on the server for initial HTML renders (like React SSR), or a site that renders HTML from the server and then has separate client-side code to enhance interactivity, or any number of combinations of these and other approaches.
I have been doing web development for over two decades now, and honestly things were only simpler if your expectations were much, much lower. If you have the same expectations today, everything is still just as simple.
If you see no added benefit to having your page run in the browser, then by all means do things the old way, and you'll find that even doing the things the old way is today much simpler than it used to be.
If you do want to create a web application that for a large part runs in the browser, I can only see things getting better every year. The perceived added complexity is simply because we are now doing stuff that's more complex.
TL;DR: Building horse carriages was a lot easier than building autonomous cars.
completely irrational comment - the web of the past was garbage and simplistic, and no amount of spaghetti jquery will ever change that HN is full of "le wrong generation"and nostalgia blinded devs who think everything in the past was better when it was complete rubbish just like the 90s
Ending up with HoC on top of HoC is also an extremely salient point. While it's not strictly required, the structure of larger React projects highly encourages you to create or use non-visual higher order components to manage connections to state stores, APIs etc - or make use of the Context API to achieve the same result.
In both cases, you end up with non-UI wrapper components to provide the plumbing in a tree of components that would ideally be entirely presentational. That leads in turn to trying to separate presentational vs. container components, trying to avoid nesting any kind of container component within a pure presentational component to keep it easily testable, creating more HoCs in an attempt to separate concerns, etc.
I certainly wouldn't describe React as garbage like the OP - but I think whether it's the best choice is heavily dependent on the kind of app you're building. The design choices it has made comes with significant challenges and trade-offs and we should not pretend otherwise.
True, but it's important to remember hooks were only released about a year ago - many large projects in existence before then will either not have migrated or be in a state of partial migration.
I'm glad they're putting the effort into making the API simpler and easier to use to address some of those concerns, but React itself has been around for seven years now - the vast majority of existing developments will have been started using versions of React created before hooks were introduced.
> "Everything an HTML tag" is an insane mantra to have.
JSX isn't HTML, it's an HTML-like syntax for JS (it's essentially XAML for JS), and React doesn't have a mantra of “everything is JSX”. It has a mantra of everything is JS, and some of it is conveniently expressed in JSX. It does strongly favor a declarative, functional style whether it's expressed in the form of JSX or conventional JS syntax.
> SSR. I've brought this point up on HN before, but doing server-side rendering in React is absolutely ridiculous.
Yeah, it's basically a client side SPA library. You can do SSR with it, and it supports it, but that's not really it's happy place.
> Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.
PHP is still around and widely used. If it fits your needs better than React, use it.
I understand this is an opinionated comment, but I thought I'd reply because IMO there's some conflation here regarding what "React" is.
> As author points out, what in the world does a <Query> tag even do?
This is not "React". This API was Apollo's decision, but just like you see libraries that lean heavily in the "everything is a component" direction, others don't. I personally use and like React quite a bit, but find this heavy use of HOCs in some 3rd party APIs a little weird.
> And everyone just bought into it because the guys at Facebook must be really smart.
Facebook builds and uses Relay which doesn't do this, which doesn't use HOCs like these ones Apollo does.
> The lifecycle hooks are just confusing and unnecessary.
It's fair to call them confusing if you feel that way, but I don't think you can say they're objectively unnecessary. They've all come pretty handy at some point or another in my use of React. Learning the lifecycle of a React component allows you to effectively integrate it with libraries that were never built with React in mind— I've used D3 + React extensively and and being able to do different D3 operations at different points in the component lifecycle makes it all work seamlessly.
> they change every few versions (so old code will inevitably break on new React versions).
Do they? React is pretty good about backwards-compatibility as far as I have seen. Wasn't the last breaking change with the release of 16, like 2-3 years ago? They also tend to make code-mods available to automatically migrate things, which can come in pretty handy.
> Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.
I do miss this too (although it hasn't gone away!), but this is not endemic to React. It is really is a traded-off to make when choosing to make a site rendered by JS (with all the advantages and disadvantages it brings) or the server (ditto).
I am suspect of any argument that says React is better or worse than jQuery. The < or > sign will depend on what problem you are trying to solve.
React and optionally react-redux is more complex in itself, but it is really trying to tame app complexity you'd get with lots a jQuery sprinkled around. With react, you can reason about the state of the app, and know the current view is calculated by a (hopefully!) pure function f that maps state to the view.
Don't really see the issue with HOCs. I am not seeing why they are a terrible idea. I think they are quite elegant actually.
SSR I might have to agree with you. I haven't yet understood why it is needed honestly. Is it SEO or something? Or is it speed of deep linking into a 'page' of your SPA.
As for the compilation steps - meh. This sort of stuff is done a lot on the back end in larger projects too - pre compilation steps and wat not. It's not a big deal with a bit of webpack watching.
It's not made for "simple JS based apps", it's meant for large complex ones. Sounds like you're using React while you literally never had a use case for it. It doesn't mean it's garbage.
In the context of a website, I completely agree with you. No blog needs react. Reddit is worse because of react.
However, given websites aren’t the only use of react I strongly disagree with your overall sentiment.
My organisation uses react in place of desktop apps, and it’s been a game changer for us. We work faster, we train devs faster, deployment is easier, we can painlessly hit everything from desktops through iPads, and we make far fewer mistakes.
I really don’t see an alternative, at least outside SPA-land.
This is that moment that proves we’ve made no progress on desktop. In 1990s we had Borland Delphi and CBuilder, in 2000s we had .Net and Qt, now this? How on Earth this is better?
We can look at this from multiple angles. Everything I write below is not React-specific, but concerns all browser-based applications (by browser-based app I will mean here both SPA websites and SPA wrappers).
1. UX
SPAs do not offer native user experience and it's generally harder to provide it on all platforms at once, even with solutions like Cordova or React Native. Usability and accessibility requirements differ, interaction patterns differ, and sometimes you have to produce completely different designs on desktop and small touchscreen devices. On desktop specifically there's a rich history of rapid application development tools and UI frameworks aligned very well with platform guidelines and design patterns. Native development on mobile still beats everything else when it concerns UX.
2. Development
The development cost for browser-based apps and React specifically is definitely one of the lowest, due to popularity of this technology and availability of the tools. RAD and technologies like JavaFX can be inexpensive only if you already have the team familiar with the stack.
The development speed of RAD tools was and still is impressive when it concerns UI. The interactive prototype of a screen created in 15 minutes in a visual tool IS the application that can run. All you need to know as a developer, is the component library and programming language. I do not really see, how React could be better here. One big advantage of browser-based apps is ability to develop both for desktop and mobile platforms at once, but this has UX consequences (see above).
The architecture of native or imperative-style frameworks is generally better than of any of JS solutions. JS ecosystem tends to reinvent the wheel by gradually introducing best practices which are pretty standard everywhere else for decades. E.g. it took some time to build Redux, which is quite similar to the UI event dispatching mechanisms in Java and the like, but uses its own unique terminology - reducers, stores etc - for what is actually a combination of classic design patterns like Observer.
3. Deployment and support
One major benefit of SPAs is instant delivery of new version to all users, achieved by design, but the SPAs packaged in desktop wrappers do not even have this benefit. Also, is mitigated by the existing approaches on distribution of standalone desktop apps via update infrastructure (which also allow canary deployments).
One of the rarely visible costs of WebView apps is the resource consumption on the client, which is usually ignored by the developers of online services. Browser engines are not the most efficient VMs for running application code and they require A LOT of RAM. Just compare Slack and mIRC - similar chat functionality (Slack may have better support for rich content and integrations), but how different they are in utilization of resources!
> 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.
This is why I stick with Vue. One <script> tag later you're good to go, and all of the extra stuff (like .vue files) isn't necessary to use the framework.
It's a godsend. I can't imagine how many hours I've lost to obscure webpack errors before switching.
What webpack errors are you getting with basic create-react-app?
Any production-destined app is going to have to go through some baseline transpiling, linting and minifying, and CRA really shouldn’t be giving you much trouble with the defaults.
>> This is why I stick with Vue. One <script> tag later you're good to go, and all of the extra stuff (like .vue files) isn't necessary to use the framework.
One of the reasons the virtual DOM exists is because it really tries to get around the browser limitations on DOM rendering. We were also all trying to manage templates and data binding. If you remove these three things, most of us could architect very simple JS apps with a singleton object.
It’s as soon as you need to define the dynamic template structure, bind data to it, and do everything in a browser performant way, is when we started trading away the simplicity for off the shelf complexity that solves mostly these three problems.
I've gotten by using a templating engine like Handlebars along with jQuery for async behavior for pretty much all of my apps. Reduced the time I spent building UIs a huge amount.
There are actually very few websites that 'require' an app-in-browser experience. And for many of those, clever usage of jQuery plugins works well enough.
I completely share your opinion here. I've had very little encounters with react but in those few 2 or 3 instances, I hated it with a passion. There are many things wrong with it. Some by design and over-engineering, some inherited from the garbage that is js to begin with.
* jsx: I've been very open about the utterly flawed notion that html should be treated as assembly or cobol: something that only old people with long white beards know and use. As a consequence you have to rely on post-market plug ins for your browser just to figure out where element X comes from. As opposed to what the "old people" would do: grep -rn {pattern} which will genuinely give you the answer in a few seconds tops even for even the largest of projects. As opposed to clicking your way through tons of elements in a browser and staring at a second screen to figure out which is which.
* The endless "compilation" just to get something show up on the screen. Not to mention the ridiculous amounts of system resources required to do said "compilation".
* 5-6mb js files. Holy crap!!!!!!!!!!!!!!!
* Everyone's obsession with mocking data. This is in all cases a terrible idea and leads to tons of "well it works on my machine". In essence you end up with two different applications, one being the frontend and one being the backend and you rely on getting everything right and magically turn that into a "they lived happily ever after". Well... That happens only in fairy tales. That's not to say you can't develop both in parallel without mocking data but for some reason I've hardly ever seen people do this.
IMO, the web is turning into a bigger mess than ever because of this. Even bigger than the flash and coldfusion days. IMO all of this needs to be scrapped and re-done. There have been plenty of attempts to replace js with something that is not garbage by design. But all those attempts were greeted with "No, U fragmentin DA web!!". Well yes, naturally. The point of a migration is to slowly ditch a horrible X for a better Y. Annoyingly, because of this, just like react, it seems js is here to stay.
A real shame really, given several much better alternatives. For instance, I used dart(pure, clean dart, no frameworks or anything) to build my personal page and while I still had to rely on transpiling, there's a strong type system which behaves as you'd expect and pure html and markdown. Yes, even for a simple thing, the generated js is 90kb gzipped but given it's entirely self-contained, no additional code needed and renders markdown out of the box, I'm fine with it. Is it ideal? Hell no. Can I add or remove stuff on the go if I ever need to? Absolutely. I may not be able to add an entirely new functionality while I'm hiking or whatever but add a link or something small and trivial without having to install a ton of crap or have a complex ci-cd setup?
1. vim a.html, add X.
2. git commit && git push.
And just like that, 15 seconds later I'm back to hiking. My argument here is that with some additional tweaks, things like these would be significantly more useful and manageable even for large projects than the huge lumps of fat that the "modern" frameworks enforce us to use.
"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.
You absolutely can, and I almost always do, styles things with native css (well, I use sass compiled to css) to style your react application (or widget!).
To my knowledge, React itself has no opinion on styling. It's more the ecosystem around React that's gone css-in-js.
But, yes, if you want to do your styling natively that's really not a problem.
Well, for me it was the opposite. Trying vanilla js was empowering!
There was no; tool chain, bundling, virtual DOM, render function, countless layers of library abstraction, sourcemaps, node_modules... etc. Just a simple index.html file
Some projects don't require a state of the art virtual-DOM-diffing-machine, just to display a list of ToDo items...
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.
> I ended up creating my own framework that was much easier to understand and manage, but is obviously not generic enough to publish.
You lost me there.
Cute for a solo/learning project, but when other people are touching the project or you're trying to build a business, you have to answer for why your project was so special that it needed its own ad hoc framework. As opposed to, say, a framework with real documentation. Or one with an ecosystem so you can escape this culture of NIH.
When I hear someone building their own JS framework, I see someone who wanted to procrastinate the hard part (building a business, shipping a product, appealing to users). Like when game developers decide to build an engine and never make the game, aka the hard part (https://www.voxelquest.com/).
They say it often but it's not true. React forces you into an entire workflow with JSX, bundling, source mapping, babel transpilation and often restricts you to using components that are designed specifically for React; accessing the raw DOM is nasty business.
If it was a library, it would not hijack the DOM and override it with its own; that fact alone is more than enough to call it a framework. Any tool which takes over the execution environment is a framework by definition.
A library is something you use, a framework is something you work inside. You could argue that react could be used to target only specific components but this would be missing the point that 99.9% of the time, React is not used like this; as soon as you have a hierarchy of components, it's a framework, not a library.
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.