At our company, we have banned React, Angular and other "overengineered" JS frameworks.
Our HTML is rendered from a standard boring Groovy server page, with some vanilla-js for DOM manipulations here and there.
We have hired developers that were React fans, which quickly changed opinion that this old-school way for developing web applications is indeed better. It is faster to code, an order of magnitude easier to maintain, DOM rendering time is faster, so a click to open a new page/view happens instantly. Our web application is so fast, that non tech people and clients always comment how smooth and slick it behaves compared to Facebook or LinkedIn.
Our clients are very happy with our solution too, as it is very simple for their developers to integrate our solution into their web application since it doesn't mess up their existing web framework. It doesn't block their rendering time, and it is easy for them to override changes.
We also have one complex UI part in our application, which can consume some CPU. This part we render with canvas, and it feels like a native app as it runs stable at 60fps. Who wants to run a lot of slow DOM manipulations when canvas is a lot more efficient.
If your web-app has even a modicum of complexity on the client side, the vanilla DOM based solution is going to get unwieldy real fast.
Consider a simple list of elements to which you can add or delete items. With vanilla DOM, you’ll have to write handlers that will `$.find` the particular element, and then run a `$.remove` to remove it. To insert something, you’ll have to do a manual `$.appendHTML`. And when you have to send the data over to the server, you have to iterate over the elements, collect it into an array and send it across. But if you used something that had an explicit notion of the application state, and allowed you to express your view as a simple function of your state, all you would have to write is an `array.push` and another `_.remove(array)`. The view will update automatically because we’ve already told the 'over-engineered' framework what to render for any given state.
But you could avoid framework and still not fall prey to spaghetti DOM manipulation. All you need is to keep an explicit state variable and have a single `render` function to deal with the DOM. This method will be invoked everytime you change your state, and it'll recreates the necessary DOM from scratch. It is a simple straight-forward implementation, but now you're going to lose cursor position, and with large enough DOM trees, the lag will be noticeable.
To fix this, you can add a virtual-dom implementation that'll maintain the DOM tree in memory and avoid re-rendering things that haven't changed.. and then you can have some sort of immutability checker to skip even the virtual-dom rendering part. And by now you have a home-brewed over-engineered React-like framework, but without any of its documentation or robustness or community.
We definitely need to be conservative in our choice of tools, but React today is a conservative choice to build rich front-end web applications. More than a framework, it is an approach to user interfaces, and it is a damn good one too.
Replies like this are always interesting to me. It seems like you're saying these "overengineered" JS frameworks are useless, but I can't believe thats the case. You must just be saying they don't fit your use case, correct? If so you are not getting that point across very clearly.
Otherwise are you honestly saying you can't see the use case for these frameworks? You would rebuild Facebook with static HTML and a sprinkling of js? You believe all these very smart people who created, worked on, and use Angular, React, Vue, etc. are just way off base and should go back to your method?
I've said it before here, but the best web app I've built was basically Django, with bare minimum js to handle in-page effects.
I've been working on a project which is being ported to React for no reason, just because it's shiny, and it's been worst than expected.
Bundling the entire website into a huge js file doesn't make any sense. In practice, every time you make the slightest change, like adding a div, or changing a class name, your users have to re-download the entire thing.
Webpack takes 1GB of memory and 90 seconds to build it. Firefox Dev Tools eats all my ram if I try to reload the page with it open. And Redux is just bad. So much boilerplate for a dynamic language, with constants and if clauses to decide which action to dispatch. Apparently, it's ok to have presentation logic in a component, but god forbid internal state!
I do believe the reason front-end devs praise it so much is because it allows them to work solely in js, despite the end product being slow and heavy.
I always compare reddit's mobile site, written in react, with Hacker News. The first takes around 7 seconds to load on my cel phone, while the latter loads instantly.
No one but frontend devs care about js. The web hasn't become js centric and I bet it never will. It has become mobile first and all you need for 90% of that is css.
I don't know why fb and google spend money building these frameworks, but maybe because of this:
"But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.
Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP.
The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it’s just cover fire so that they can move forward and you can’t..."
Thank you. This is true, the frameworks are not only trying to speed up the performance, but first and foremost abstract from the DOM. And for quite a while they've been failing on delivering that performance. Things get better with react server side rendering and the like, but they still need tons of javascript loaded alongside the nicely rendered html which still makes it quite laggy.
Recent example of it is gitly.io. It is a beatiful web service which is I believe written in go. I just looked it up and it merely uses 200 lines of vanilla js. When I'm logged in and actually browsing the file tree.
React is for complex/dynamic UIs. By using canvas, you kind of admitted that the old-school way isn't good enough for that case. Having said that, if canvas works and is better than React for your case, then great! Use whatever works.
But how do you handle the encapsulation of views? If I am working on a React app and I want to add a new interface, say a simple view that displays a record and has some controls on the left side, I might write something like this:
This view would be injected into the frame of the app that already has a navbar and footer, the layout would be pre-built via my panel components Left and Right, and if I want to change the control-panel I can go to that file and make any changes I want so long as the API stays the same. Similarly, if the schema changes and we need to update the way we display records, I would go to the RecordView component and change it because it is a decoupled module. I just don't see how you can accomplish this with vanilla HTML and JS.
Might I ask what kind of applications you're developing?
While I generally like the idea of doing web applications the old-fashioned way depending on the requirements manipulating the DOM using vanilla JavaScript can quickly get out of hand.
I am confused why people think Redux is complicated. Maybe you were trying to use React-Redux? Redux itself seems incredibly simple to me, so simple that I sometimes wonder if I need a library for the functionality at all.
I've never been any good at frontend work. Everything I've made has always gotten messy, fast, and eventually it's an unmaintainable mess.
React-redux just made it all cleaner, easier. There was a nice tight constraint on what I could do- want something to happen? Call an actionCreator, let the action change the state, re-render. Constraints free you.
The last four months have suddenly seen me shift from 'leave UIs to the devs who can do that' to 'Oh, we need a whole new page to show some reports? I'll have it done today'.
I was a relatively early adopter of Redux and, while I understand the appeal of the architecture and mental model, I was always annoyed by the boilerplate (to turn plain language functions into serializable events) and unclear approach to modularization (single state tree is too much like a global). For moderately complex apps I found the practical downsides of those heavier than the pros of unidirectional flow and reproducible execution. Haven't touched it in over a year so I can't say if things are better, but somehow I doubt it.
I've had the same experience. It took me about a week to "get" Redux as a new-ish dev back a year or so ago. Why do you think people have trouble with it?
Switching to React definitely has a learning curve, especially if you are coming from old-stool JavaScript or just not used to some of the concepts in React or Redux themselves. That said, once you get your head around it things start falling into place.
We're recently built a React Native app and I feel the benefits it brings to cross-platform development make that ramp-up worthwhile. A single iOS and Android codebase is a glorious thing, and helps avoid needing silo's of specialized developers.
I would say that the maturity (or lack thereof) is obvious when using React. The big ideas are solid, but there is a lot of thrashing - you need to watch each new version for backward-compatibility issues and carefully manage your dependencies. Coming from Ruby/Rails, I also feel like React is still at the point where you're spending a lot of time configuring things vs adopting standard conventions - it's getting there, and projects like react-navigation are helping build up that boilerplate, but certainly can be frustrating at times.
Doesn't mirror my experience at all. Most of the post is complaining about the ecosystem, which you don't need at all to use React "properly". React is just the view piece. But in any substantial project, you will have to figure out routing, data storage, networking and cross component communication.
And you shouldn't write large blocks of conditional logic in the markup code. That's bad whether it's PHP, React or Angular.
And complaining about className? Really? Is the author not aware of reserved words?
I agree. React is a great rendering library which somehow became the core of a mix and match framework, plagued by backwards incompatibility and maintained by plethora of individuals. As a result upgrading dependencies is never safe and and each of tens of them is quite likely to introduce breaking changes or become obsolete, leaving you having to make unnecessary changes in your app.
Don't get me wrong, I think React is good at what it does, which is rendering. I just don't think the maintenance of a react app, which includes dependency management, is worth the benefits. Similarly the current model of reinventing everything in the "react way" is hardly speeding up development.
The best explanation I've seen for why React is such a pleasant experience, is that it's a text-based version of the best parts of Visual Basic - you use React to lay out pre-built UI components, build your own new ones, and the UI behavior is a function of the properties you set.
React, and similar libraries, have the advantage of being parasitic - you can fit them in along with a lot of what's already out there, without necessarily having to rewrite what you've already build. I.e., you can easily use UI frameworks that are agnostic to Javascript library pairings.
As an example of this, I built https://www.findlectures.com/ with TypeScript + React, starting with no CSS library, then added bootstrap, then replaced Bootstrap with Semantic-UI. This makes me appreciate some of the flexibility of the ecosystem now, even though it comes with the pain of having too many options for a lot of the individual components.
it makes me wonder if react devs who thinks react is the greatest thing since sliced bread are somewhat new to web development (less than 2-3 years or so). because im sure those who inherently know, would find that vuejs is just a superior framework (sans native). there will always be new frameworks that comes out and some will be better than the last. and vue to me is leading the forefront and does things that makes sense for web development. once vue releases native, i think there arent many reasons to use react if vue is available.
when ppl say react is the best or that its for complex apps makes me shake my head, as those who believe that may be just naive or dont have much experience to make up their mind.
experience over time, leads you to strive for patterns and elegance, and unfortunately react doesnt have that which makes it feel there is a bit of immaturity in the framework. this is why i wouldnt be surprised if many if the react fans are the way they are in their stance.
its just my two cents from an old js dev who have seen through over 15 years, so your views maybe different from me, but should be similar to those who knows what im talking about.
I don't think that years of experience has anything to do with liking vue or react. I know how you feel, because my colleague had similar thoughts on React, he even created something very similar to vue a few years before vue(jade+css+js in one file). While I just use pure virtual-dom (no jsx) and almost nothing else.
The way you put it, some people look for patterns and elegance, while some look for simplicity (no special v-bind or v-if), modularity and deletability. There is nothing more senior about one way or the other, just different personal preferences.
It would probably help if you provided any kind of actual argument for vue.js being so superior other than the head shaking and vague claims about react not having "patterns" and "elegance".
For the record, I have been in web development for as long as you are, so that alone does not seem sufficient to immediately see the of superiority of vue.js over everything else.
The article shows snippets from the Redux and React Router docs, implying they are realistic examples of the way that typical React code should look, however, they are clearly snippets which are trying to show the entirety of an API on one screen. If your code is just a bunch of snippets copy-pasted from docs without much thought given to the structure of your code, your choice of UI library isn't the problem.
On React Router, React Router is not React. You don't need to use React Router. There are plenty of stable pure JS routing libraries, which don't release new versions often (or ever, because they are 'done'). Nothing about React requires you to use a React-related routing library.
The author found Redux and MobX too complex for their use case. However, Redux and MobX are not required to use React (there seems to be a theme here), and probably not useful if you don't have a big single page app with a lot of client side state. Implying they are intrinsic aspects of using React is wrong.
The bits at the end:
you will need to import in your scripts react-dom and react without never using the last one instance for some wild reason known only by the React team
The react and react-dom packages are being split so react-native doesn't have to pull in dependencies which are only used on the web. Not that different to Rails splitting up into a bunch of gems.
you can render functional components just by using js functions but you will need to wrap all your markup always in a wrapper tag to properly allow the Virtual DOM creation
This was an architectural limitation which is going away in the next major version.
its apparent simplicity is hidden behind a whole toolchain you need to configure before you can even writing 1 line of code
Why complain about this but refuse to use create-react-app? It literally solves this problem.
I started my app with React 15.5.0 knowing that my code is deprecate before even starting because facebook has just announced that for the next major release they are planning a complete rewrite of the framework and this means that they will likely nuke the current source because it can be no longer maintained.
This is FUD. The team has said that the next version of React will have some small breaking changes, but the API will remain almost completely the same. Not sure what they mean by 'nuke the current source' though.
The trick is - don't try and learn all this shit at once. Make a react app without any extra state management. Just store your state at the top and pass shit down. Add more stuff until it starts to get annoying passing all the callbacks back up. Now you are ready for redux cos you understand what it is saving you from.
React itself is actually really simple and a nice way to make complicated UI.
1. If PHP coders did component driven development it might not be so bad, the problem is most PHP apps mix code and HTML in a way that resembles speggeti so we (I've tought a lot of PHP courses) teach separation of concerns as to encourage maintainable code.
2. In React you're not really supposed to (as a matter of best practice) mix presentation and business logic. Typically most components are for presentation only with business logic done via event handlers and props. If you need state you should wrap your display component in a business logic component (typically called a container in the Redux world).
Regardless of these complaints, the job market for React is just too damn good to ignore. I bit the bullet and began learning. As a newbie, I understand the sentiment of this article. However, it's really not as bad as the author makes it out to be.
Also, className instead of class took all of 3 seconds to learn.
className is a small inconvenience when porting over an existing app to react (e.g. pasting in existing html), as is the requirement for style parameters to be objects. className is a quick find replace, but style is a more lengthy transpose process.
These are small frictions, but in the same way that every ounce/gram counts to a hiker, minimizing process frictions makes a big difference in productivity during times you already have a high cognitive load.
"what do you expect from a framework with more than 1000 issues on github that will let you install alpha dependencies by default ([email protected]) to develop your native app?!?"
The recurring pattern seems to be some new tech gets introduced, preferably by a well known SV company. Usually it matches their use case and is a struggle to adopt generically.
People scramble to learn it anticipating demand for jobs or contracts and become part of the hype cycle. If they can kick start the the cycle then everyone benefits and they are too vested to discuss quality, architecture, design or anything that risks the gravy train.
Things can become haphazard. Technical or complexity issues take a back seat and are hand waved away, apologism thrives. Discussion becomes heated as is wont when it comes to money.
There can be 100 articles like this about React but it won't matter. Because this is not about quality but economics. Even the most hardcore react fans know the ridiculousness of its setup is not tenable technically or otherwise.
Experienced people won't respond to fads and certainly not badly designed one as they have no need to. If the market for work was stable and less heated it would be much more difficult to pull off these hype cycles.
I don't think the `className` argument sticks. `class` is reserved so you can't use it. It's annoying but not a difficult concept
The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state?
I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN to decipher ES6 syntax), but I wonder if that's not an issue of style. Just like you can write PHP inline with HTML and you can write JS with HTML in JSX storing snippets of logic in a variable increases readability.
> I don't think the `className` argument sticks. `class` is reserved so you can't use it.
But you can use it. JSX nodes get compiled into React.createElement calls with object literals[1], and {class: "foo"} is a perfectly valid object literal in JS, s there's nothing stopping `<div class="foo" />` to get compiled into `React.createElement("div", {class: "foo"})`
In fact, other frameworks that support JSX syntax allow the use of `class` instead of `className`[2], so it's not a limitation of JSX per-se, it's just a design decision on part of React (and an annoying one at that).
It's valid. className was a frequent annoyance with React. That's one of the nice things about Vue. I can paste HTML snippets and they just work. I can't say it's the reason I switched, but it was some icing on the cake.
> what's the alternative for small-to-medium React applications that still need to store state?
I've found that with small React apps, you normally organise each component to be responsible for handling its own state.
If you need a global shared state but your app isn't large enough for Redux then lots of people pass callbacks down to child components as parameters. True story.
Am I doing something wrong on small-to-medium applications by simply using setState? I always worry about this, even if Dan Abramov blessed it.
Sometimes I need some more global stuff, which I have solved in the past using context but I feel like maybe I'll just hook up some small mobX store in the future... Not sure
The stampede to React has probably gone too far but it was very much a reaction to the domination of Angular which from personal experience had made web development a nightmare.
React proved you didn't need a huge overbearing framework to get things done Vue and Riot takes this even further (even if Riot predates React)
Both HN and article title are misleading - this talks mainly about learning mobx, redux, and react-router, and then has 4 little nitpicks about react at the end.
Exactly my experience, but with Angular 2+ instead of React.
To me, in comparison with Vue.js, both of these frameworks are grossly over engineered.
I'm keeping a list of things that are, in my opinion, unnecessary or badly designed in Angular 2+. After around two days of hacking I have seven position and the list will probably keep growing.
In general the React approach works best if you are willing to build out a handful of utilities on your own sometimes, rather than always choosing from pre-existing open-source solutions. You don't need React Router. You don't need React-Redux. Heck, you don't always need Redux, you can just throw a state object on the window (or make a state module or whatever you do these days).
Here's a React 15 app in a single HTML file, using ES5 and the old in-browser JSXTransformer:
I had high hopes there, but I don't see an app, I just see enough boilerplate to put a <span>Hello, world!</span> into the DOM, which could have been done by just writing that into HTML. I can understand what it's doing, but I don't think it's a good example of how you can write an actual app without the parts people are mentioning.
Thought I'd post this as a skim reveals no one has discussed testing.
While I am sure it is very possible to achieve this in other ways, the React-Redux structure (dumb components handling presentation and redux handling state) enforces a discipline that makes testing your client-side app far easier than other solutions I've seen where logic and presentation are far too often coupled. Recall that true vanilla ES5 does not even have modules.
There is certainly a lot of cargo-cultism surrounding React, but I'll be always be grateful for it making the vdom and functional style of coding more mainstream.
[+] [-] olavgg|9 years ago|reply
Our HTML is rendered from a standard boring Groovy server page, with some vanilla-js for DOM manipulations here and there.
We have hired developers that were React fans, which quickly changed opinion that this old-school way for developing web applications is indeed better. It is faster to code, an order of magnitude easier to maintain, DOM rendering time is faster, so a click to open a new page/view happens instantly. Our web application is so fast, that non tech people and clients always comment how smooth and slick it behaves compared to Facebook or LinkedIn.
Our clients are very happy with our solution too, as it is very simple for their developers to integrate our solution into their web application since it doesn't mess up their existing web framework. It doesn't block their rendering time, and it is easy for them to override changes.
We also have one complex UI part in our application, which can consume some CPU. This part we render with canvas, and it feels like a native app as it runs stable at 60fps. Who wants to run a lot of slow DOM manipulations when canvas is a lot more efficient.
[+] [-] jasim|9 years ago|reply
Consider a simple list of elements to which you can add or delete items. With vanilla DOM, you’ll have to write handlers that will `$.find` the particular element, and then run a `$.remove` to remove it. To insert something, you’ll have to do a manual `$.appendHTML`. And when you have to send the data over to the server, you have to iterate over the elements, collect it into an array and send it across. But if you used something that had an explicit notion of the application state, and allowed you to express your view as a simple function of your state, all you would have to write is an `array.push` and another `_.remove(array)`. The view will update automatically because we’ve already told the 'over-engineered' framework what to render for any given state.
But you could avoid framework and still not fall prey to spaghetti DOM manipulation. All you need is to keep an explicit state variable and have a single `render` function to deal with the DOM. This method will be invoked everytime you change your state, and it'll recreates the necessary DOM from scratch. It is a simple straight-forward implementation, but now you're going to lose cursor position, and with large enough DOM trees, the lag will be noticeable.
To fix this, you can add a virtual-dom implementation that'll maintain the DOM tree in memory and avoid re-rendering things that haven't changed.. and then you can have some sort of immutability checker to skip even the virtual-dom rendering part. And by now you have a home-brewed over-engineered React-like framework, but without any of its documentation or robustness or community.
We definitely need to be conservative in our choice of tools, but React today is a conservative choice to build rich front-end web applications. More than a framework, it is an approach to user interfaces, and it is a damn good one too.
[+] [-] titobrown|9 years ago|reply
Otherwise are you honestly saying you can't see the use case for these frameworks? You would rebuild Facebook with static HTML and a sprinkling of js? You believe all these very smart people who created, worked on, and use Angular, React, Vue, etc. are just way off base and should go back to your method?
[+] [-] xmatos|9 years ago|reply
I've been working on a project which is being ported to React for no reason, just because it's shiny, and it's been worst than expected.
Bundling the entire website into a huge js file doesn't make any sense. In practice, every time you make the slightest change, like adding a div, or changing a class name, your users have to re-download the entire thing.
Webpack takes 1GB of memory and 90 seconds to build it. Firefox Dev Tools eats all my ram if I try to reload the page with it open. And Redux is just bad. So much boilerplate for a dynamic language, with constants and if clauses to decide which action to dispatch. Apparently, it's ok to have presentation logic in a component, but god forbid internal state!
I do believe the reason front-end devs praise it so much is because it allows them to work solely in js, despite the end product being slow and heavy.
I always compare reddit's mobile site, written in react, with Hacker News. The first takes around 7 seconds to load on my cel phone, while the latter loads instantly.
No one but frontend devs care about js. The web hasn't become js centric and I bet it never will. It has become mobile first and all you need for 90% of that is css.
I don't know why fb and google spend money building these frameworks, but maybe because of this:
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
"But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.
Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP.
The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it’s just cover fire so that they can move forward and you can’t..."
Replace Microsoft with Google or Facebook...
[+] [-] noway421|9 years ago|reply
Recent example of it is gitly.io. It is a beatiful web service which is I believe written in go. I just looked it up and it merely uses 200 lines of vanilla js. When I'm logged in and actually browsing the file tree.
[+] [-] rpedela|9 years ago|reply
[+] [-] jhedwards|9 years ago|reply
[+] [-] amnah|9 years ago|reply
1) inline with your view files
2) write them in separate js files and include them depending on the page
3) concat them into one big js file which gets included on every page
4) something else?
[+] [-] BjoernKW|9 years ago|reply
While I generally like the idea of doing web applications the old-fashioned way depending on the requirements manipulating the DOM using vanilla JavaScript can quickly get out of hand.
[+] [-] wavefunction|9 years ago|reply
We have groovy in my stack at work and everyone despises it. Fortunately that's a legacy we're moving away from.
[+] [-] kasbah|9 years ago|reply
This "Redux in a nutshell" sums up the simplicity nicely I think: https://gist.github.com/MarcoWorms/30758235f05faec844b8c06ce...
[+] [-] mabbo|9 years ago|reply
React-redux just made it all cleaner, easier. There was a nice tight constraint on what I could do- want something to happen? Call an actionCreator, let the action change the state, re-render. Constraints free you.
The last four months have suddenly seen me shift from 'leave UIs to the devs who can do that' to 'Oh, we need a whole new page to show some reports? I'll have it done today'.
[+] [-] Jare|9 years ago|reply
[+] [-] sotojuan|9 years ago|reply
[+] [-] ckorhonen|9 years ago|reply
We're recently built a React Native app and I feel the benefits it brings to cross-platform development make that ramp-up worthwhile. A single iOS and Android codebase is a glorious thing, and helps avoid needing silo's of specialized developers.
I would say that the maturity (or lack thereof) is obvious when using React. The big ideas are solid, but there is a lot of thrashing - you need to watch each new version for backward-compatibility issues and carefully manage your dependencies. Coming from Ruby/Rails, I also feel like React is still at the point where you're spending a lot of time configuring things vs adopting standard conventions - it's getting there, and projects like react-navigation are helping build up that boilerplate, but certainly can be frustrating at times.
[+] [-] jinushaun|9 years ago|reply
And you shouldn't write large blocks of conditional logic in the markup code. That's bad whether it's PHP, React or Angular.
And complaining about className? Really? Is the author not aware of reserved words?
[+] [-] darth_mastah|9 years ago|reply
Don't get me wrong, I think React is good at what it does, which is rendering. I just don't think the maintenance of a react app, which includes dependency management, is worth the benefits. Similarly the current model of reinventing everything in the "react way" is hardly speeding up development.
[+] [-] garysieling|9 years ago|reply
React, and similar libraries, have the advantage of being parasitic - you can fit them in along with a lot of what's already out there, without necessarily having to rewrite what you've already build. I.e., you can easily use UI frameworks that are agnostic to Javascript library pairings.
As an example of this, I built https://www.findlectures.com/ with TypeScript + React, starting with no CSS library, then added bootstrap, then replaced Bootstrap with Semantic-UI. This makes me appreciate some of the flexibility of the ecosystem now, even though it comes with the pain of having too many options for a lot of the individual components.
[+] [-] jaequery|9 years ago|reply
it makes me wonder if react devs who thinks react is the greatest thing since sliced bread are somewhat new to web development (less than 2-3 years or so). because im sure those who inherently know, would find that vuejs is just a superior framework (sans native). there will always be new frameworks that comes out and some will be better than the last. and vue to me is leading the forefront and does things that makes sense for web development. once vue releases native, i think there arent many reasons to use react if vue is available.
when ppl say react is the best or that its for complex apps makes me shake my head, as those who believe that may be just naive or dont have much experience to make up their mind.
experience over time, leads you to strive for patterns and elegance, and unfortunately react doesnt have that which makes it feel there is a bit of immaturity in the framework. this is why i wouldnt be surprised if many if the react fans are the way they are in their stance.
its just my two cents from an old js dev who have seen through over 15 years, so your views maybe different from me, but should be similar to those who knows what im talking about.
[+] [-] masiulis|9 years ago|reply
The way you put it, some people look for patterns and elegance, while some look for simplicity (no special v-bind or v-if), modularity and deletability. There is nothing more senior about one way or the other, just different personal preferences.
[+] [-] balfirevic|9 years ago|reply
For the record, I have been in web development for as long as you are, so that alone does not seem sufficient to immediately see the of superiority of vue.js over everything else.
[+] [-] mambodog|9 years ago|reply
The article shows snippets from the Redux and React Router docs, implying they are realistic examples of the way that typical React code should look, however, they are clearly snippets which are trying to show the entirety of an API on one screen. If your code is just a bunch of snippets copy-pasted from docs without much thought given to the structure of your code, your choice of UI library isn't the problem.
On React Router, React Router is not React. You don't need to use React Router. There are plenty of stable pure JS routing libraries, which don't release new versions often (or ever, because they are 'done'). Nothing about React requires you to use a React-related routing library.
The author found Redux and MobX too complex for their use case. However, Redux and MobX are not required to use React (there seems to be a theme here), and probably not useful if you don't have a big single page app with a lot of client side state. Implying they are intrinsic aspects of using React is wrong.
The bits at the end:
you will need to import in your scripts react-dom and react without never using the last one instance for some wild reason known only by the React team
The react and react-dom packages are being split so react-native doesn't have to pull in dependencies which are only used on the web. Not that different to Rails splitting up into a bunch of gems.
you can render functional components just by using js functions but you will need to wrap all your markup always in a wrapper tag to properly allow the Virtual DOM creation
This was an architectural limitation which is going away in the next major version.
its apparent simplicity is hidden behind a whole toolchain you need to configure before you can even writing 1 line of code
Why complain about this but refuse to use create-react-app? It literally solves this problem.
I started my app with React 15.5.0 knowing that my code is deprecate before even starting because facebook has just announced that for the next major release they are planning a complete rewrite of the framework and this means that they will likely nuke the current source because it can be no longer maintained.
This is FUD. The team has said that the next version of React will have some small breaking changes, but the API will remain almost completely the same. Not sure what they mean by 'nuke the current source' though.
[+] [-] tomwilson|9 years ago|reply
React itself is actually really simple and a nice way to make complicated UI.
[+] [-] darth_mastah|9 years ago|reply
[+] [-] bryanlarsen|9 years ago|reply
Why is mixing HTML into your code in React good? Because it isolates all the view code for a single component in a single file.
[+] [-] throwaway2016a|9 years ago|reply
1. If PHP coders did component driven development it might not be so bad, the problem is most PHP apps mix code and HTML in a way that resembles speggeti so we (I've tought a lot of PHP courses) teach separation of concerns as to encourage maintainable code.
2. In React you're not really supposed to (as a matter of best practice) mix presentation and business logic. Typically most components are for presentation only with business logic done via event handlers and props. If you need state you should wrap your display component in a business logic component (typically called a container in the Redux world).
[+] [-] tigershark|9 years ago|reply
[+] [-] autoreleasepool|9 years ago|reply
Also, className instead of class took all of 3 seconds to learn.
[+] [-] AndrewNCarr|9 years ago|reply
These are small frictions, but in the same way that every ounce/gram counts to a hiker, minimizing process frictions makes a big difference in productivity during times you already have a high cognitive load.
[+] [-] xyos|9 years ago|reply
[+] [-] danabramov|9 years ago|reply
https://medium.com/@dan_abramov/hey-thanks-for-feedback-bf95...
Thanks for sharing!
[+] [-] bigato|9 years ago|reply
"what do you expect from a framework with more than 1000 issues on github that will let you install alpha dependencies by default ([email protected]) to develop your native app?!?"
[+] [-] throw2016|9 years ago|reply
People scramble to learn it anticipating demand for jobs or contracts and become part of the hype cycle. If they can kick start the the cycle then everyone benefits and they are too vested to discuss quality, architecture, design or anything that risks the gravy train.
Things can become haphazard. Technical or complexity issues take a back seat and are hand waved away, apologism thrives. Discussion becomes heated as is wont when it comes to money.
There can be 100 articles like this about React but it won't matter. Because this is not about quality but economics. Even the most hardcore react fans know the ridiculousness of its setup is not tenable technically or otherwise.
Experienced people won't respond to fads and certainly not badly designed one as they have no need to. If the market for work was stable and less heated it would be much more difficult to pull off these hype cycles.
[+] [-] arenaninja|9 years ago|reply
The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state?
I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN to decipher ES6 syntax), but I wonder if that's not an issue of style. Just like you can write PHP inline with HTML and you can write JS with HTML in JSX storing snippets of logic in a variable increases readability.
[+] [-] Bahamut|9 years ago|reply
[+] [-] epidemian|9 years ago|reply
But you can use it. JSX nodes get compiled into React.createElement calls with object literals[1], and {class: "foo"} is a perfectly valid object literal in JS, s there's nothing stopping `<div class="foo" />` to get compiled into `React.createElement("div", {class: "foo"})`
In fact, other frameworks that support JSX syntax allow the use of `class` instead of `className`[2], so it's not a limitation of JSX per-se, it's just a design decision on part of React (and an annoying one at that).
[1]: As noted in the first code snippet on the React homepage https://facebook.github.io/react/
[2]: E.g., Mithril https://mithril.js.org/jsx.html#jsx-vs-hyperscript
[+] [-] jazoom|9 years ago|reply
[+] [-] thaiphanvevo|9 years ago|reply
I've found that with small React apps, you normally organise each component to be responsible for handling its own state.
If you need a global shared state but your app isn't large enough for Redux then lots of people pass callbacks down to child components as parameters. True story.
[+] [-] arcticfox|9 years ago|reply
Sometimes I need some more global stuff, which I have solved in the past using context but I feel like maybe I'll just hook up some small mobX store in the future... Not sure
[+] [-] darth_mastah|9 years ago|reply
[+] [-] darth_mastah|9 years ago|reply
[deleted]
[+] [-] hazza1|9 years ago|reply
React proved you didn't need a huge overbearing framework to get things done Vue and Riot takes this even further (even if Riot predates React)
[+] [-] thatswrong0|9 years ago|reply
Both HN and article title are misleading - this talks mainly about learning mobx, redux, and react-router, and then has 4 little nitpicks about react at the end.
[+] [-] Tade0|9 years ago|reply
To me, in comparison with Vue.js, both of these frameworks are grossly over engineered.
I'm keeping a list of things that are, in my opinion, unnecessary or badly designed in Angular 2+. After around two days of hacking I have seven position and the list will probably keep growing.
[+] [-] baxtr|9 years ago|reply
[+] [-] idleworx|9 years ago|reply
[+] [-] guscost|9 years ago|reply
Here's a React 15 app in a single HTML file, using ES5 and the old in-browser JSXTransformer:
https://gist.github.com/guscost/27736c5f0913184695492ac40fd3...
[+] [-] rikkus|9 years ago|reply
[+] [-] yomly|9 years ago|reply
While I am sure it is very possible to achieve this in other ways, the React-Redux structure (dumb components handling presentation and redux handling state) enforces a discipline that makes testing your client-side app far easier than other solutions I've seen where logic and presentation are far too often coupled. Recall that true vanilla ES5 does not even have modules.
There is certainly a lot of cargo-cultism surrounding React, but I'll be always be grateful for it making the vdom and functional style of coding more mainstream.