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.
To be fair diffing virtual dom is not the only way - you could also be diffing the model and only update the parts which need it. Knowing the model well allows you write an efficient diff. The problem of course is that dom diff is universal while model diff is specific to application.
The good part about React is that given a `messages` data structure and a `render` function, it implements `addMessage`/`addMessageBefore`/`updateMessage`/`removeMessage` on its own. Writing once and not multiple variants of the same is good.
Another good thing is that that there are a lot of components someone already published, that are ready to use (immediately, or after a few small fixes/PRs).
The bad part is that React has a lot of code on its own, and somewhat strongly suggest use of even more. It's orders of magnitude more than that your `{add,update,remove}Message` snippet has. While React tries its best to hide all that complexity, it's still there. Designing, writing, reading, debugging and rewriting (if necessary) those few functions is all trivial (but somewhat routine) - not so much with React.
all the add/remove list stuff can be implemented by a simple templating library (handlebars/mustache) which doesnt mess up the whole client side architecture
Templating libraries can't update documents, they can only overwrite them completely. This either loses state (entered-but-unsaved text, cursor positions, <detail> collapse status, etc.), or requires a lot of watchers and extra state information.
Those DOM updates is the whole point of React.
There are other libraries that work in a similar fashion, but React has more traction thus reusable components and recipes available...
no, the point of the template engine is not to push all the logic into the templates. as you say you still handle the state yourself. the template render just skips the messy output building step, which for many cases is all you need
React is a templating library. Nothing more, nothing less.
It takes a state ("props"), a template ("component") and renders the DOM tree. That's all it does. (Non-templating uses like react-router are kind of hacks, rather than intended use. YMMV, of course.)
However, it's more complex than previous-generation templating libraries (that had emitted strings, rather than operating on DOM trees), because DOM trees are stateful. This is why React is so huge, when compared to, say, Mustache.
(And, of course, it's really easy to mess things up by putting application logic right in the component class. And, I'd say, sometimes it's really tempting to do so. Mustache/Handlebars doesn't have this only because they're specifically designed to disallow such things.)
no disagreement on what react is. yes, I understand react can be used just to template (no one uses it this way). yes, react is powerful. yes, react provides a good mechanism for handling state and events. what i am saying though is that for some apps, you can get by with simpler templating and avoid the conplexity/power react gives you, handling state and events yourself manually. does it sound crazy? if you know it will work for your particular use case, i dont think its crazy, and you avoid a bundle of complexity that react gives you, in essesnce you own the complexity now
> react can be used just to template (no one uses it this way)
I don't know about the others but I do. Got bad experience when I've shoved logic where it didn't belong, don't repeat the same mistake again.
As the templating "got data, want a form, a table and a chart" engine it's good - exactly in a sense that I can write one template instead of multiple partials (add+update+remove). The complexity hidden underneath doesn't strike my fancy, but... it works, and saves coding time - especially because a lot of components are already written by someone else and is available on npm.
Still, it's really really easy to shoot yourself in the leg. And I found a fair share of tutorials and examples teaching those sort of things.
> react provides a good mechanism for handling state and events
No, it doesn't have those. Unless you count react-router/Redux/Mobx/whatever as React-the-umbrella-naming.
Well, there is some basic internal state management (via constructor + `setState` + `componentWillReceiveProps`) but that's about it, and IMHO it best very used conservatively, for approximately the same reasons why having logic in, say, Jinja2 templates isn't the best idea in Python world. Or maybe I just don't know how to cook stateful components properly, but last time I made a stateful component I ended up rewriting it some weeks later, extracting the state away, because it became a problem.
There is no event handling at all - except for the "props are changing, this is going to update" event, of course. All React has is `onClick`-like attributes and handlers bound to those are best left as some dispatch calls to the outside, with no logic inside the React component code whatsoever.
> If you consider 40LOC complex I don't understand why you work as a dev.
Goodness, your snark that questions the parent's competence is not only unwarranted, it is based on an incomplete understanding of the value of abstractions in programming.
It is not about 40 lines of code, it is about a basic programming model that allows us to understand and create user interfaces irrespective of how complex or large it is. It lets you compose your UI based on a tree of state and pure functions. If you don't have this abstraction, you do not have a coherent programming model to build UIs.
Actually, I wonder if there's something out there that has all the declarative state-to-DOM manipulation goodness, but does this at build time.
React is a runtime that works on the client, and its compile-time stuff is just syntax sugar (JSX) and some minor optimizations. As I understand, this runtime is the complexity that some complain about. At least I perceive this as a downside.
If there's something that can, given a component definition, generate those sets of add/update/remove functions and appropriate calls on state updates (preferably, as human-readable as possible) - I think that would be interesting to see and compare.
(I hope no one normally dynamically mutates their components at runtime?)
I haven't ever used it because I find React quite adequate. I share your concern about the complex runtime layer that React introduces, and it is getting even more complex with the introduction of Fiber.
However, the test of an abstraction is whether it leaks undesirably, and whether it lets you escape to the lower layers when you need to. React scores well on both counts.
So while the implementation might be complex and will get even more elaborate over time, the abstraction is as water-tight as I can hope. In that case complex implementations with better performance might even be a good thing.
Also, I strolled through the React codebase in its early days and found it eminently understandable. So if it ever comes to it, I'm confident I can contribute a patch for the things I need with enough time and effort.
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?
There is a story called The Emperor's New Clothes, the morale of that story is that you should question your decisions and not blindly believe what other people say, even if you look up to them.
When I saw the "light" about React, me and friend were coding our own e-commerce system each for fun. Him with Ruby and Rails and jQuery, me with Grails and React. When we implemented the shopping cart, I wrote like 200 lines of code in React that would dynamically update that shopping cart. My friend did it with just 5 lines with jQuery. Yeah most of my React code was boiler plate, but still...
What I do, is not at Facebook scale, complexity or size. I have no idea about how challenging their issues are technically. What I do know as a user of Facebook though, is that Facebook is annoyingly slow these days, and makes my Macbook pro fan spin at full power.
You are comparing apple to oranges. Why use react or angular or vue with fun hobbyist projects meant for a team of one developer that is going to throw that code out and move on to another hobby.
In the real world you're going to have to come up with a homegrown vanilla approach for all the things that a good framework does for you: escaping user input, provide setup and cleanup hooks for your DOM manipulations, maintain state and I'm not even touching routing because you seem to be focused on server-rendered apps although the community does prefer hybrid apps that start out server-rendered and load more data while the user is browsing.
I've worked in companies that started out homegrown and it's a bitch to maintain, evolve and for that matter teach to new hires.
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..."
If you can build your application without a framework, do it. It's the right call every time. Not every web project calls for React, but for the ones that do it's a god-send. The alternative to me is not a minimal Django app -- it's nigh-unmaintainable jQuery spaghetti.
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.
Its more like that we needed to display A LOT of data, that you also needs to interact with, much more than you can fit in a screen. So we present this with a simple way to navigate this data by using simple pan and zoom operations! Our clients love this!
I had a client request we put an entire 10k+ searchable and sortable product table on a single page (with thumbnails for every product). After much reservation and trying to convince them otherwise, we just did it.
After a few seconds of the browser creaking the page renders fine and runs great. This is a page with over 10000 images on it.
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.
Yes, we do a lot of inlining at the end of a view. In every case when the javascript is only usable for that view we find this very clean, every developer can immediately see what javascript is running on that particular view.
We have our own small library for the more common operations, for small things like more effecient navigating of the DOM three or more complex "components" that for example convert a select element to a nicer selectbox with built in full text search. That library is included for every view. This library weight around 50kb gzipped.
Some companies go for that 'disciplined javascript' style. It's a nice paradigm to follow, but every time you'd want to make it slightly more advanced (as the app grows) you'd have to implement tooling on your own.
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.
But is it joy for customers to use the stuff you wrote in it? So many of these opinions always focus on the developers having fun instead of wondering what experience is for the user and maintainers.
It's not the new hotness anymore. Scala came along. The author of Groovey says Scalia is better. It's also semidynamic. So if you don't like that, you won't like that (tautology of the day).
You mean James Strachan? That was 8 years ago. In November last year he said "I still love groovy (jenkins pipelines are so groovy!), java, go, typescript and kotlin. I don't use Scala anymore." [1]
Sounds like he uses Kotlin instead of Scala, and only uses Apache Groovy in Jenkins pipelines. And given that the Groovy collections methods are disabled so they don't actually work in Jenkins, I imagine he uses Java 8 or Kotlin for that purpose.
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?
As a dev learning about it for the first time, "Action Creator", "Store", and "Reducer" don't mean anything. Is "Store" a database connection? "Reduce" sounds like functional programming, sounds hard. Why "Action Creator"? Aren't actions objects that I can create with "new"?
For me, I also didn't understand the value in splitting it into those pieces - when I was learning Redux, I kept wondering "why aren't these just pub / sub events? Can't you do this with an event bus?"
I think most devs aren't used to learning new high-level patterns. Most know MVC, maybe a couple others, but I think Flux / Redux are a bit more complicated (by nature) than that. I doubt anyone interested in Domain-Driven Design or Clean Architecture would have an issue picking Redux up, but those devs are the exception.
I've found it really easy once I stopped thinking about it in the way it's presented at all. The use of the term "action" is especially misleading. Easier to think of it as two event dispatchers hooked together (which is more or less what it is).
I watched a talk at a meetup on Redux. Loved the idea. Tried to try it out with React or Vue and had a lot of trouble getting going. I'm still fond of Redux as a concept but I've mostly had trouble trying to get the rest of my needs met. I'll try again at some point.
I don't think people are having problem with understanding how redux work, but having problems with the shear number of boilerplate files you have to write to get anything done. Often times the speed at which you can get things done is equated to productivity.
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.
I saw a fascinating talk on Redux, I like the idea of how it manages state and the whole event sourced approach to that.
I've repeatedly tried to get Redux going with either React or Vue but have found it surprisingly hard. Many outdated seed projects and installation instructions made it somewhat painful.
I've played a bit with React from the more recent create-react-app and that got me started with some of it. I haven't been sold yet, I realize that I want something to cause the events and update the DOM but I haven't been sold on why React is best for that yet.
Always annoying when you try to approach some tech and have a hard bounce off of it.
If you've got questions on using React or Redux, please feel free to drop by the Reactiflux chat channels on Discord and ask. I hang out there most evenings, and there's many others happy to help as well. The invite link is at https://www.reactiflux.com.
In addition, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, and much more. I also published an "Intro to React (and Redux)" presentation at http://blog.isquaredsoftware.com/2017/02/presentation-react-... , which is a good overview of the basic concepts for both React and Redux.
How much of your code is OS focused? When I tried other approaches such as Ionic, the views started to be come heavily OS focused. Do you just forgo the native appearance?
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.
There are like 13 exposed functions in React: render, componentDidUpdate, componentWillUpdate...It's as simple as it gets. What breaking changes? The core API has changed little. And what they have changed is simple to adapt to. They've added stateless functions and switched to ES6 style classes and removed mixins.
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.
This makes a lot of sense. In practice each component can function as a complexity-hiding layer, making integrations with other code a breeze compared to the status quo.
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).
I thought that was irony, nuanced by a sly dig at Facebook.
The gist being that React is what happens when a PHP shop creates a client-side framework, with all the architectural warts that this might imply, if you're on the PHP-lowers-the-bar-to-web-programming-too-far bandwagon.
(FB engineers would probably tell you that their variant, Hack, is a far cry from PHP, and their coding standards are well above that of your bargain-basement wordpress drudge, but you get the idea)
You can have complex logic and functions in JSX but that doesn't mean that you have to, so the example is very contrived. That way of writing the code is completely discouraged in the documentation and I haven't run across it often or at all in the real world.
It wasn't lifted from the docs. The tutorial is a tic-tac-toe game, while the example in the post is an AddTodo function [edit: there appears to be an add todo section, but the code is completely different]. Furthermore, all the examples in the tutorials show a pattern where you reference functions instead of writing them inside JSX.
" Using props and state, we can put together a small Todo application. This example uses state to track the current list of items as well as the text that the user has
entered. Although event handlers appear to be rendered
inline, they will be collected and implemented using event delegation. "
Fair enough - it's a todo app. The code isn't structured in the same manner as the author's, however, so my point stands. It doesn't look like the code was lifted from the docs, as you said, but instead transformed to look like spaghetti.
The third paragraph was one that said that good PHP looks like React and bad React looks like PHP, but I deleted it because I thought it was stronger letting the reader make their own inference.
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 (React@16.0.0-alpha.6) to develop your native app?!?"
>The version of the the react package is generally not relevant because it contains very little code (Component and createElement). The reconciler code is synced to React Native separately. So this an artifact of the different release cycles of RN and React, and doesn’t at all mean that RN apps are using an unstable version of React.
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.
A few reasons. The render() functions were unweildly. The ecosystem of router/state libraries were in constant incompatible flux. Difficult transition animations. Complex server side rendering setup. Probably some other things I can't remember.
> 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.
Yes, that's what I do. Managing the global state in the main component, setting up functions to change the state via the update helper [1] and pass these functions down to the dumb components.
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.
https://www.depop.com/ = React + Relay + React Router (probably not needed, might switch to Next when I upgrade to Relay Modern). Redux is technically in the codebase, but for such a minor feature that I think I'd now be comfortable removing it.
I appreciate the site is relatively simple, but honestly React + Relay + [insert router here], is sufficient to build this out to something of relatively high complexity. Obviously, I have more dependencies than this (JavaScript lol), but they're mainly ones for solving very specific requirements, rather than key architectural libraries.
You'd include all the modules as separate script files. Each script file is a revealing module[0] that exports its API to a global variable. If you're interested I could put together a more complete boilerplate. I don't actually use this approach much in front-end work these days, but it can be nice to work with just text editor and browser.
As for building it, you're on your own. You could run jsx from the command line, concat them all together and minify.
I may be wrong, but I use webpack to remove exactly the the pain point of running jsx from the command line, concatenating files and minifying them. It does good job there and saves me time.
It's a good solution, but webpack can be overwhelming to newcomers, and it sometimes can lock you into working with associated dev tools like webpack-dev-server and all the various loaders.
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.
> Then imagine to meet a dev from the future telling you that in 10 years anyone will be writing their app routers in Javascript in this way
Yeah. The first time I saw JSX presented as something Super Serious and Obviously Fine, We Don't Even Need To Talk About It I thought I was being trolled.
I'd agree that if you'd floated this sort of syntax anonymously, even shortly before React came out, the overwhelming response would have been "LOL what talented but horribly misguided junior high student thought up this nightmare-haunting terror? Lurk moar n00b."
Immediately had high hopes that someone is going to try and give a well researched, novel critique that maybe can spur out some constructive conversation.
And then, sadly, the author goes on to write exactly what countless other articles have already covered and discussed to the death for years now. "HTML in JS", "JSX is bad", "Redux is complicated", "The tooling is too much". And then here we are again in the front page of HN for some reason.
To me, this is, again, an extremely common case of "trying to learn everything at once".
Still, a couple of points I'd like to try to mention:
JSX: Has been argued about so much it's pretty much useless to try and add anything to this discussion at this point honestly. For whomever likes it, fine, for those who don't, thankfully the JavaScript ecosystem provides with a multitude of alternatives. For new-comers still trying to reason about it, this talk by Pete Hunt is a good start https://www.youtube.com/watch?v=x7cQ3mrcKaY
Redux:
> Anytime I work with redux I need to go back to its documentation because its core concepts are so complicate that my mind struggles retrieving them back puking them out as soon as I stop working with it.
While I agree that working with Redux at scale can be complicated, the core concepts are extremely simple: Async Action -> Action -> Reducer -> Connect data to your components -> Display -> Async Action -> enter an extremely simple data flow paradigm (flux).
(state, action) => state
Redux can get complicated when you add to the mix schemas, normalization, selectors et al. My advice and I can't stress this enough: Don't try and learn everything at once, start with simple core concepts, iterate later, add tiny new pieces when it makes sense. You don't always need Redux anyway.
RE: Redux boilerplate: It's a lot, yes, but that's by design. Redux is simply a tradeoff between boilerplate and repetitive, dead simple management of your complicated state. I'd rather write a few lines of code more if it means I'd avoid having logic bugs or getting confused where my data comes from.
RE: React Router:
[...] the maintainers had the great idea of bumping 3 major versions in 5 months completely not backward compatible to each other
This is simply not true. React Router has had a single major breaking API change in 2 years. RR 2 and 3 where the same thing and 4 has just now been released after 2 years of stability.
RE: Final complaints:
[...] you must use className instead of class to define the DOM css classes
This is an extremely weak point to complain about.
[...] 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
You only need react-dom once, to the point where you ReactDOM.render your application. You need React because you're using it implicitly with JSX. I'm not on the React team by the way, it's a simple google search: http://stackoverflow.com/questions/38206646/do-we-need-to-im...
[...] 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
Valid point, although it's a nitpick. In any case, this is going away with the newer version of React's reconciler (Fiber).
[...] its apparent simplicity is hidden behind a whole toolchain you need to configure before you can even writing 1 line of code
create-react-app is great, officially supported, and does everything, is it the fault of the ecosystem that the author is reluctant to try the official CLI?
I've had really bad experiences trying to get going with React but I just found this article ranty. I was also expecting something more interesting. No feeling of depth to the analysis, just "I did not like this and now I will complain about it".
I'm guessing english is not the authors first language so I won't dwell on it but I found it somewhat hard to follow.
I agree on everything except what you're saying about React Router. I've been working on projects that tracked React Router since it was first announced. Understandably, every pre-1.0 release broke something, 1 to 2 broke things, 2 - 3 was compatible but slower in enough scenarios that it's questionable whether you should upgrade. RR4 just isn't the same library, and due to its reduced scope has thrown a few problems back into the realm of being unsolved.
It's fairer to say that the year during which RR2 and RR3 were the primary releases, was a relatively stable time.
I've generally been pretty tolerant of the amount of library churn within the React ecosystem, I'm the kind of person who will happily keep dependencies up-to-date and upgrade apps to newer/better tools when they emerge (I'd even say I enjoy it more than actual day-to-day coding), but React Router has been a major source of frustration for a long time now. Hopefully, the version 4 API is going to be stable for a while (even though getting efficient data-loading with Relay is now an utter pain).
'skeptical of letting doing my job to cli tools like create-react-app'
I am also uncomfortable with magic boilerplate, reminding me of some enterprise Java and Microsoft tech like DirectPlay.
That said, for some applications large libraries and frameworks can save a lot of development cost, increase speed of development, etc. I find myself using both very high level libraries and also working on stuff where I build most of what I need 'bottom up' style.
Things about the React ecosystem pretty much anyone will tell you -- outside of complaining about why you use className. Yea all the libraries and tools get confusing. But, you don't need redux, mobx or react-router for most applications; hell, if you don't like them use some other flux library or router. That's what people like, React is not an all encompassing framework it's just the view piece.
I am glad it works for you and you are happy with it I get your point and I agree with it. In this post I don't shout against React.js I just wanted to tell you my experience with it without the need of convincing anyone about using anything else instead
His point about React Native at the end is very reductive.
As an experienced (6+ years) iOS developer, my experience putting together a dual platform app in React Native has been very positive. For the majority of content driven apps, it seems to me that React Native is a no brainer.
I had similar thoughts when I first learned React. After building several UIs with it, I think the core thing that trips devs up is that it's very easy to make things far more complicated than they need to be. Beginner resources often don't help, either. Many of the boilerplate and starter pack examples you can find online have a ridiculous level of complexity in the file folder structure, component structure, dependencies, etc. - for example, no, you don't need half a dozen components spread across as many files to render a simple header or footer.
If you try to stick to a minimalist approach, it can be a pretty convenient framework. Definitely beats trying to do the same thing the jQuery way.
Those are great points, my solution don't use Redux, Mobx and React Router and webpack if you can. React itself is great thought, but for some reason it's surrounded by over-engineered yet popular projects.
Contrived example at the beginning of the article makes everything after it suspect. My markup in JSX rarely looks horrible and in fact, it made my life easier as a fullstack engineer.
React popularity seems to me the result of wrongly-headed thinking: that because facebook is popular, any technology behind it must be good, and because react is popular (allegedly), react must be good.
I've always been very sceptical of react, and I'm glad I didn't invest too much time looking into it, as it seems both a time sink and a boilerplate-filled approach. I wonder why some people like it, writing no-framework javascript isn't difficult at all, and you can organise it in a nicer, readable way, plus there are many alternative frameworks that seem better. Is it because of too many choices, people would hang on to the one they think will stick?
>writing no-framework javascript isn't difficult at all,
If anyone recommends this without any concrete source code to illustrate the superiority of the advice, be skeptical for 2 reasons:
1) the programmer who rejects frameworks ends up writing another invisible framework that doesn't happen to have a name. Because the author is intimately familiar with his own code, he many not even realize that an implied framework emerged from it.
2) the programmer truly avoided coding an "accidental framework" but only by duplicating code everywhere.
In short, if you organize code in any coherent way with consistent abstractions to follow principles of DRY[1], it becomes a framework whether you give it a name or not.
It doesn't mean the framework-called-React is perfect. What it does is raise the quality of discussion from "plain JS is better than ReactJS" to the more realistic comparison of "my unnamed-framework is better than React-framework because ... see my source code at github, etc".
>I wonder why some people like it
I think for some, they truly chose it for the wrong reason. However, there are others who look at the problems React solves (efficient DOM diffing algorithm, 1-way view update, etc) and conclude that they would rather not reinvent that themselves. Therefore, they use React so they can start solving other more specific problems relevant to their business domain.
Imagine if I flipped around your statement and said - don't trust anyone who recommends the superiority of a framework without comparing absolutely every possible framework at their disposal and showing sample code to explain why a certain framework must be chosen. Are you up to this comparison task? Suddenly, the problem changes from "finding better tools for my job" to "evaluating some fairly opinionated peoples' views on how the rest of the world should write their code". The second scenario is best avoided because
a) you don't want to take the word of someone who isn't going to face the consequences of all your framework-induced overcomplicated code razzmatazz
b) for too many people, this also means skipping the part where they learn to walk and start trying to run
c) not to mention, the companies creating these frameworks are surreptitiously doing everything possible to change the nature of the web, so by not using the frameworks (however "open" the "source" is presumed to be), you register a little bit of a protest at a fairly low cost
Besides, have you ever considered the following: the person creating the invisible framework is actually best suited to find better ways, assuming they do want to improve their coding abilities. Such a person is more likely to naturally gravitate towards the solution. If they fail to do so, those who end up maintaining such code will end up gravitating towards the best solution. How do you think the converse scenario plays out, where someone did use a framework without really needing it, and then it was found to be overcomplicated and unmaintainable?
There are some traditional upsides/downsides to writing your own framework, but they should be evaluated for each case without blindly espousing one view or another - that said, for almost all business needs, you are probably better served by using an established framework.
Frameworks
1) Solve more difficult problems that most developers are not qualified to implement optimal solutions in a timely manner for (i.e. efficient algorithms, creating parsers for correctly parsing templates and avoiding security pitfalls, cross-platform rendering, avoiding cross-platform bugs such as browser-specific issues, etc.)
2) Have a publicly documented and established set of patterns/concepts (good for hiring - most developers do not want to learn a homebrewed system that likely brings less professional development benefits for their careers. Whether this is accurate or not in how it affects their careers is irrelevant, this perception is pretty strong from what I can tell anecdotally)
3) Avoids the significant cost of committing to R&D to reinvent the wheel, which most companies are not willing to do and/or does a disservice to companies financially
Homebrewing a framework, which is what you do when you avoid an existing one has these upsides
1) Building something that is potentially easier to understand (especially if built by one or a few people)
2) Potential for smaller JavaScript payload sizes
The upfront cost of creating a homebrewed framework is significant, and to be honest, going that route is probably technical malpractice for an engineer for almost all situations, even at bigger companies. I would be far more wary of any recommendation of homebrewing a framework than adopting an existing one maintained in the open by a community. The downsides of a framework not controlled by you are far outweighed by the downsides of creating one from scratch almost all the time. It is far more productive to participate in the community for a framework that is close enough to your ideal and influence the process that way than it is to burn it all down and suffer trying to solve the same problems in a more limited and likely worse way.
I dislike being the guy who things that 'everything sucks' but the things I've seen come out of React have been horrifying. Very few websites even require anything that React provides nor do most webapps need to be webapps.
I've come across bugs where simple text boxes were crashing the browser. Fixing that bug took the front end three days because they simply had no idea how to fix it because everything was buried in the React abstraction layer.
Sure, but the question that always lingered in my head was, how it even possible to mess up a text box? It was a simple input form that crashed the browser by taking up all its memory. I could literally see my browser GC spike during every single keystroke.
If it's possible screw up the most basic element of a website, I shudder to think what other simple elements are out there that are horribly written
Asana (ugh, not my choice) once prompted me for feedback. The whole thing's performance is always worst-in-class god-awful, but the feedback textarea lagged nearly a full second before registering each keystroke. A textarea. A textarea.
My feedback was... a little mean. Having read some of the stuff about their NIH-induced in-house framework I suspect they've got several things hanging around in it that belong on Accidentally Quadratic, assuming they're still using that thing. If they're not still using it then I don't know what they're doing wrong. Possibly most things.
Meanwhile I use Basic HTML gmail because full page reloads are way faster than Ajaxy-Gmail and (especially) Inbox. And those are from a company with "only" "A players". I hate the modern web so very much.
I am working on a web application that is dynamic enough that the standard way to build websites makes it really hard. So I started building my own version of React. Found React some time later and switched because it was better than my crappy code.
Why was I trying to build React? I wanted a framework that behaved more like a video game render loop or a desktop UI framework. I wanted a framework where I could simply update the data and the complicated view would update itself efficiently (as few draw calls as possible). I wanted a framework that felt like those much better tools (in my opinion) I was used to on the desktop.
React is the very first web framework to do that and it was a huge breath of fresh air for me. However that does not mean every website needs to be built with React. In fact it is probably overkill for most websites.
I can only speak for myself, but I only use React because it solves massive problems with building complicated apps in Javascript. (This value has been explained in countless other places here, so I won't repeat it here.)
I actually use it in spite of Facebook, not because of it.
I am not a js dev, but isn't the issue of no-framework that you have to write a bunch of code to deal for various browsers? And a bunch of more code to deal with basic web patterns that you'll end up copying from project to project?
I don't see where the parent suggested no framework. It's likely he or she prefers working a different framework or library, like vue.js or even jQuery.
For me, jQuery is the bare minimum requirement. I would never attempt to write a large app in pure JS, even with babel. You would definitely run into some of the problems you mentioned.
EDIT: I see now where he mentioned no-framework JS
I have written relatively large (35k lines) project in pure JavaScript (without even jquery) and have never faced any of the issues mentioned by the parent, (Babel helped). I write native first and then run babel to appease my older browser faring users.
The advantages of native are that it's extremely snappy to use and fast to load. Bears smaller memory footprint (have to use angular.js at work and god it's awful) and with newer things like async await, ES16 classes, etc code management is very good. Can't recall the last time I had to take care of a specific browser quirk.
I really don't see how jQuery would help you much there. It doesn't provide any sort of common structure at all, and it's nowadays arguably not very helpful for its helpers either.
My point is you can forgive someone for that kind of error when there are articles making the round from semi-reputable sources that include quotes from sources that appear to back up their claims. Especially when it doesn't seem to have a political slant or angle to it (aside, possibly, from someone at Facebook deciding for PR reasons they should frame this as a complete rewrite, in which case you're being lied to by the people doing the work, so where does that leave you?)
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.