I encourage anyone who likes React and doesn't mind lisp to check out Reagent, an awesome Clojurescript library built atop React that manages to completely hide its complexity. It's by far the most fun I've ever had with web development; the way I feel now is like how I imagine people who've had religious epiphanies must feel when trying to show potential converts the proverbial light of god.
It essentially combines all of React into a single component, the Reagent atom. It's used exactly like a normal Clojure atom, but whenever it's updated, Reagent will automatically update all Reagent components that depend on it. I find this quite elegant, as it allows one to write pretty much any reactive ui using only three functions: deref, update and render-component. Reagent atoms can even be passed between Clojurescript async threads, and will still work as expected, which completely eliminates the need for any kind of callback hell.
So what it eliminates is the need to learn React. Anyone who understands how Clojure atoms work and how to use Hiccup-style HTML templating will be able to use Reagent with almost zero learning curve.
So Reagent is like React + Baobab (https://github.com/Yomguithereal/baobab)? Since Clojurescript has to compile to Javascript anyway, I can't think of a reason why Javascript can't have a counterpart to Reagent.
I'm not familiar with Clojure, but it seems like atom is the data tree that holds the state of the entire application. If so, could you give an example use case of when you'd pass the data tree between threads, and what advantages it has over promises or es7 async/await.
Just to be sure, I'm not questioning the validity of your claims, I'm genuinely curious about how things work in reagent.
There doesn't have to be a single atom holding the whole application, that's just an approach some people take.
An example of passing data between threads: imagine a forum that allowed indefinitely nested comments. It also loads comments lazily; one must click to load a comment's child comments, in which case they'll be loaded from the backend. However, if the child comments are minimised again, then expanded again, another backend request won't be made, as the data is already loaded.
I approached this by having a separate 'thread' running that just listened for messages (maps) on a channel. If it was a :get-children message, this thread would check the local cache for the parent comment's ID, and if it found it then it'd add the data to the atom provided in the request, otherwise it would fetch the data, add it to the cache, and then add it to the provided atom.
The comment component would then take a copy of that channel, which it'd pass to its children, and to get comment children data it'd just pass a :get-children message into the channel with an empty atom for the other thread to fill. If a button was clicked that changed a comment somehow, then it could send a :update message through the channel with the parent id, and the other thread would re-fetch the relevant data from the backend.
Of course, there's nothing here that couldn't be done with promises/async. I just personally find Go/Erlang style message passing between threads to be simpler and easier to reason about than async/await, and I believe Reagant/Clojurescript would appeal to others who feel similarly.
I'm a big fan of Clojure and React, but haven't used Clojurescript or Reagent. I find React pretty easy to grok so I'd be interested in how you think Reagent makes it easier to use.
Reagent means you don't have to grok Reagent at all. If you know how Clojure atoms work, how to use Hiccup-style templates, and understand that all templates ('components') that dereference a Reagent atom will be automatically updated when the atom is, then you know how to use Reagent.
I think you meant "grok React". But yes, Reagent is super-nice. I'm surprised much of the community has gone for Om, since Reagent strikes me as much cleaner 98% of the time. Om maps closely to React, when most of the time it doesn't have to.
I recently worked on my first React project, after working with Angular code for a while. I'm willing to accept that as an app gets more complex, React/Flux really pays off. But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React. When you want to get a 10,000-foot-view of how it all comes together, you can (generally) do that in the code in Angular, but you're better off doing it in the browser with React. Which may not be bad, but it's a difference worth mentioning.
To each their own, I guess. I think that any template that's more than 4-5 lines (not including closing tags) is generally a mess and can benefit from being split into more components. AKA the single responsibility principle.
Structuring a program with a large number of small components is very awkward when templates and code are in separate files.
As far as that 1000 foot view, a nice tree view of React components is vastly superior to a wall of text cluttered up by meaningless implementation details like "div".
> Structuring a program with a large number of small components is very awkward when templates and code are in separate files.
I agree. We've developed a fairly complex Ember application, and the component hierarchy feels cluttered with everything separated by component and template. E.g. I have /my-component/component and /my-component/template instead of just my-component.js. Its funny coming full circle in MVC apps, but I find myself frustrated writing 1-5 line templates -- that I have to import. Why can't I just put it in the same file as the component, and have one file? Subjective to be sure, but I'd much prefer React style components in our project.
You should look at ember pods - it's already built into ember-cli. It basically organizes your project's folder structures live you've described. All 'posts' related items go into a posts folder - its routes, components, templates, controllers, etc.
Because you're still tied to thinking in terms of master templates and interpolating strings - maybe because of how designs are handed off to you?
The smallest unit in UI design is a component, and React maps well to that, allowing you to treat components as functions (you can compose, specialize). You'll realize the power of that once you work with real UI designers who understand designing from inside-out as opposed to dumping a PSD mock of the entire page.
> But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React
I'm not sure what you mean. There's nothing in React that would prevent you from making your pages just one huge component. You can split the code any way you like.
There is a reason for that and it is because it makes for simpler code. Simpler code is easier to test and simple tested code should have less bugs. Also you get the advantage of reusability from all of the small components you build. If you don't want to follow the recommended programming practices, you don't have to but I would like to encurrage you to adopt them because they really are helpful.
I want to +1 the "makes for simpler code." I'm working on a side project in my free time on nights and weekends. I find the simplicity of React makes it very easy to jump back in after not working on it for a week, or when coding while I'm tired. Working with simple components allows me to constantly move forward, even if it's only for 30 minutes or an hour a night
Agreed - I also found React a bit clunky with the explicit getters/setters compared to Angular.
JSX is a bit of a weakness IMO - I absolutely rather have templates in separate files to reduce complexity/concerns located in a file. It also adds build tool complexity, which there is too much of in frontend currently.
Otherwise, working in React is generally clean, but one can get that benefit by utilizing ES6 modules in general. React brings a lot of good things to the table, which is probably best exemplified by Angular 2 pulling a lot of ideas from it.
Build tool complexity is what I dislike - it's certainly possible, but the trend I dislike is build tooling increasing complexity of the build system of the frontend, decreasing accessibility for onboarding developers. JSX is an unnecessary offender in this department, bringing us farther away from plain HTML.
> But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React.
Good point; How does one view the resulting react-page anyway? CTRL+U shows <body><script.../></body> no matter what state the SPA is in..
You want to look at the DOM structure of the page as it exists in the loaded page and have I got a treat for you! Figure out how to open the web inspector for your browser; the keyboard shortcuts are ctrl-shift-I or cmd-shift-I or cmd-opt-I on a few (platform, browser) pairs.
(This will show you the actual DOM, not the React components... but since you were talking about 'view-source', this might help you too.)
Using the web inspector has been such a massive and continuous boost to my learning/work with webpages and I'm extremely glad to share it with someone it might help.
That's actually better than looking at the HTML output, unless you're debugging something really weird. With React you should treat HTML as an implementation detail and work in terms of component trees.
The new Glimmer engine in Ember.js gives you React-like DOM diffing without the use of JSX, and baked into a very organized and easy to grasp framework to boot.
Ember might be well organized and a great framework but I'm not sure I agree with "easy to grasp". There is so much automagic that when something tries to deviate from the common Ember patterns I worry that you are going to have a bad time. I say that having hardly used Ember outside of the intro tutorials so please someone correct me if I am wrong.
While I like the tooling around Ember, I don't know how much I actually like Ember itself. I mean, there are routers, controllers, templates, views, and components. How many different concepts do you need?
If you use react-router (port of ember's router), you get a view of the components on the page for each route. Then you can drill down into your component of interest.
I may be alone on this, but I've enjoyed working with Mithril much more than I ever did React. If you haven't given it a shot, I highly recommend you do.
A lot of people praise Mithril for its small file size and speed, but one of its greatest and perhaps most overlooked advantages is its small learning curve. You only really need to understand two things to get started: what a component is (a plain JS object with controller and view), and when a redraw happens (once on m.mount, and once after every event handler).
Why is a low learning curve important? Several reasons. If you're a developer, it's not a huge investment to learn (how difficult was it to learn backbone / angular / ember?). If you're a startup / company, you don't need to look for X developers, where X is a difficult-to-pick-up JavaScript framework. You also save money by having a shorter on-boarding period for those non-X developers.
I've worked in a hackathon group that picked Mithril up and created amazing results with it right away. I teach at a coding school, and by far Mithril has been the easiest JS framework for my students to learn and work with. For being so powerful, Mithril is quite easy to get started with – and that means a lot.
We went with Mithril over React too. Both are good, but React + all of the libs needed to match Mithril is a fairly large payload for mobile-optimized websites, whereas Mithril is tiny.
Mithril didn't quite have everything we needed, though, so we made a small wrapper that provides nicer templating, event delegation, etc.: https://github.com/dailymuse/mithril-coat
I like Mithril a lot, but the only thing that puts me off it over React and Angular is I don't really know how to tie in third-party libraries like d3 and dropzone.
You can use the same approach for other libraries:
Add a function as `config` attribute to your virtual DOM element. That function gets the real DOM element as a parameter, and you can act on it with third party libraries.
I'm very interested in more modular, simpler alternatives to react / flux. Essentially I'm looking for reactive "isomorphic" component based, virtual dom solutions like react - mainly to integrate with a node.js workflow.
I was wondering if anyone had tried both Mithril as well as Deku(https://github.com/segmentio/deku) who would like to share their experience?
What makes you like Mithril more? I've been looking at it for a while, and it seems very nice and lightweight.
All I really want is an easy way to get performant DOM manipulations. With React I have to build the whole view around the component system, which isn't so flexible. Am I right in thinking that Mithril allows you to put the view together any way you want, as long as the end result is an object it can diff into the DOM?
D3 can do DOM manipulation a. It's more well known for its charting (SVG) functionality. But I've used it to build tables and other data-based DOM structures.
It's not ideal for all use cases. But for updating the DOM based on changes to the data, I find it to be a useful option.
Square built and fast library on top of D3 called Crossfilter. Speed is pretty amazing when you see the data source. http://square.github.io/crossfilter/
> Am I right in thinking that Mithril allows you to put the view together any way you want, as long as the end result is an object it can diff into the DOM?
That's correct. Virtual DOM nodes are plain JS objects with `tag`, `attr` and `children` attributes (the last two being optional).
The `m()` helper gives you some sugar on top of that.
Idiomatic Mithril view code, however, is more about declaratively generating vDOM nodes based on a model and/or a view model than, say, jQuery-style DOM manipulations...
Next up - how I stopped learning how to be a real developer and accepted what framework farcebook ejected today. Tomorrow - abdicating database decisions in favour of whatever I read about on HN today.
Wow, author here. Woke up to a lot of unexpected traffic on the blog. I hope you like this article. I took a long time to understand React and, now I do, I hope other people don't take as long as I did!
Thank you for writing that article. To me, the article is pretty much how an ideal technical article should be: it doesn't assume deep knowledge of the subject matter and uses lots of examples and comparisons to make the case. It takes a lot of work to write that sort of article, I really appreciate that you took the time to do it. Looking forward to seeing the one about Flux!
I clicked through to a few of your other recommended posts and ended up emailing myself a bunch of links to read later. I particularly enjoyed 'Promises Are Not Optional' (http://firstdoit.com/promises-are-not-optional/)
You have a talent for clearly explaining complex abstractions. Nice work!
Nice overview, I like how the article has the same code demo in Knockout and Angular to show how they both solve the same problem in slightly different ways. Would be nice to see the firstName + lastName demo in React too, I know the onChange stuff can be a little verbose, but would be good to show how it can be used to actually update a single central model.
I've never used react but from what I read it's a more intuitive organization of components.
The separation of the view and logic is an arbitrary separation that isn't always efficient. It's like owning a bunch of power tools and organizing by color instead of by function.
Templates have components like search bars and login forms and they have logic related to those components. Why should component logic and template code be separated when both the logic and template components serve the same function? Code should be organized by segregating things into widgets. This, to me, makes more sense.
I think the only thing missing from React is the ability to incorporate local css styles into the widget. Again like I said if there are styles associated exclusively with a widget, there's no point in segregating styles into some separate css file.
Logic, structure, and style should be unified and organized by function, not by category.
Question for experts: why Browsers do not get the idea of updating changes the way react does automatically possibly with a start, stop transaction or better without.
It would be wonderful if browsers acted more like game engines. Collect user input and at the beginning of every rendering "frame", allow JavaScript to process the input and modify a virtual DOM. Then, render the virtual DOM. It would be so much easier to reason about web applications this way.
I'm messing around with ideas for an experimental hypertext engine, now you've got me tempted to try building it on a game engine. Looks like Unity might have halfway-decent text support.
Whenever a change is made to the raw DOM, the change has to be immediately visible to the code running after it. React sacrifices this.
When the DOM is treated as the source-of-truth for the page's information, the synchronously-visible changes are very useful. However, getting away from treating the DOM as the source-of-truth, which React forces you to do, gets you a lot of power as changes to the DOM can be batched more efficiently automatically.
Ugh, for my sanity as a JS newbie I have to ignore all the other JS frameworks/libs mentioned in this discussion and just master React and JS, perceived warts and all. I recommend the same thing to other newbies who come here.
I finally got into React after being told by a friend for months that I need to. I'll be honest the whole thing just looks like premature optimisation to me.
I still find the structure of an angular app a lot easier to grasp, it might be that I'm used to it but I remember the first time using Angular that it all made sense to me. I liked it instantly. Coming from Backbone, it certainly was a breath of fresh air. I can't say the same thing about React. Sure it's faster, and if you think your app is going to mutate into something big, consider using it. But I personally wouldn't make it my default choice.
For me, it isn't about the optimization, it is about the way it lets you break your app into simple reliable components. There was a moment when building my first React application where it just clicked and I realized how much I was enjoying the reusability and ease of testing all of my components. I have never been able to write such well tested front end code. Also, the reusability of my code has skyrocketed.
For someone whose strong point is not JS, is it a good idea to ignore all other frameworks (like ember, angular etc) and just go with react? I find it easier to evaluate server side frameworks than JS frameworks.
If you think React could be a good fit, simply use it. Comparing frameworks is very time-consuming and doesn't get you any closer to your goals. Actually, any framework is better than pause-deciding-which! :)
> However, all template languages are inherently crippled: they can never achieve the same expressiveness and power as code. Quite simply, {{# each}}, ng-repeat and databind="foreach" are all poor replacements for something that is native and trivial in JavaScript: a for loop.
On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using JSX I need to calculate the result of a `for` loop before the actual template and it looks much more complex and cumbersome.
> On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using JSX I need to calculate the result of a `for` loop before the actual template and it looks much more complex and cumbersome.
You can inline eqivalent JavaScript statements in JSX, without typical template language limitations in terms of allowed expressions or scope:
You've gotta admit though that inlining isn't the usual case. Especially if you're not using ES6 and the component your inlining is a few or more lines long.
That's not been my experience - multiple lines nest quite nicely - but even when directly inlining isn't suitable (e.g. multiple if/else checks or rendering a list in a way which doesn't suit a straight .map()) I prefer creating another method and inlining the call to it, e.g. from my Hacker News API clone:
It depends on who's doing the coding. I've got some inlined loops that are ~20 lines long, and I think it works & looks better than assigning the loop to a variable before the render and inlining the variable.
So, besides the virtual DOM, I feel like it's east to write React-like code in Angular. Just make directives that are real tight, with unidirectional flow of events and get passed only the values they need. Perhaps I'm missing something.
The virtual DOM is nice, although the only time I've seen a noticeable difference from two-way binding in speed is for tables with 1,000's of rows. The whole bit about React being more predictable than two-way binding is just an opinion though. Since any component can emit an event and change data, it's just as prone to loops and unpredictability. It's really just two different ways of thinking through the process. One's not better than the other.
There is a lot of good and even awesome things in ReactJS universe, except JSX. Thousands of developers took their lessons in PHP/Perl/Python about mixing logic and representation, and now in nightmares they will generate HTML from logic, especially by parts and in worst case - using conditional cases. Everybody who tried to change design of website, written using something like "if ($birthday) $html .= getBirthdayButton()", will understand me.
Maybe JS developers should go through it, through this circle of hell, to avoid it in future, so JSX is necessary evil.
//despite of that, I sincerely thankful for people behind React, for their new ideas and how they changed fields of JS frameworks and mobile apps. Big respect!
You might be confusing programming languages with concepts.
Don't think of React as "a container for logic and a system for doing views". Think of it solely as view logic.
It's not mixing views with program logic. It's only view. There's nothing to mix. It just happens --- wonderfully --- to use a real programming language to represent those views.
The notions of logic, controllers, models, storage, and all that jazz are why there's also Flux (or Backbone or whatever else it is you want to use; we use Flummox, it's fine).
You might be confusing "logic" and "business logic" terms, I talk about "logic" exactly.
Any logic and conditional cases makes design very difficult to change, because you can't anymore just move one piece of HTML (tags) to another place, or replace all classes with ctrl+f - it becomes very complicated with logic used to build it.
In practice, it is extraordinarily easy to move a React component from one place in the UI to another, most especially if you're using Flux, so that components are decoupled.
That's been one of my favorite things about working with React: it actually works to design bottom-up, factoring low-level components out and then moving them around like cutouts.
I could not do things like that in Knockout, or, god forbid, Mustache and server-side templates; not without changing the application logic to account for the move.
I get the feeling that you're just arguing for the sake of arguing. You can't in one comment say that it's hard to move things around and then in the other comment say that of course it's not hard to move things around.
Maybe if you will read my comments more closely you will see the difference between moving parts of HTML inside component and moving components. "Moving things around" is too broad term.
The distinction you're making between "HTML" and "facility for encapsulating generated HTML" seems pretty arbitrary.
I was making a simpler point, though.
Some of the reactions I see to React seem to come from the notion that it's mixing application logic with view logic. That's an easy misconception to get from reading the tutorials and quick-start documentation: after all, it's using raw Javascript to generate HTML, which is the same language other frameworks use for application logic.
The misconception comes I think from comparing React to Angular. Angular is an application framework. React is solely a view framework. It happens that React uses Javascript --- which works amazingly well in practice! --- to express views. But that doesn't mean it's mixing application logic and view logic.
That's all I was saying. The semantic argument between "components" and "HTML" is totally uninteresting to me. The important point, regarding ease of moving "bits of UI" around, is that React makes it astonishingly easy to do that. It's one of the selling points of React.
If you don't know yet reasons to keep them separate, please google about it before arguing without arguments. For example, read about Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns
Separation of concerns and separation of technologies are a different thing. It would appear you haven't done your research. See Pete Hunt's famous talk:
Hm.. I didn't say a word about separation of technologies. If you have one non-broken piece of HTML and related piece of JS to make it "live" - it's one thing. If you use JS/php/python/ruby/lua/whatever to generate HTML, composing it by small pieces into one (inside one component) - it's another thing and it's exactly what I'm talking about.
You are just throwing unrelated links around. Parent's point was that in this case, logic and representation are one and the same concern. What you're doing is similar to using SoC to defend having to split up class definitions into .h and .cpp files.
Don't put your words into my mouth with "allegories", I hate it.
I don't talk about cpp and headers at all, I talk about view templates and view logic.
You are using your gut feeling, but that's not how React works at all.
JSX is not HTML, mixing logic/presentation is not a concern because you're not dividing your rendering between backend/frontend, and finally you don't even have to care about the final HTML representation of your component, it's just an implementation detail.
Finally, it's all declarative since you're never modifying a DOM tree - and declarative is a pre-requisite for good UI frameworks.
I use my years of experience, I don't need gut feeling for it.
I really don't talk about backend, absolutely. While we have "createElement", we will use it with conditional cases and as result we will have mess of NOT-BUSINESS-logic and HTML code.
I am playing around with React and if you want to keep it JSscripty (being the only dev who actually likes JS) or you want to use coffee script then createElement isn't actually horrible to use.
Especially not if you make an alias to ce or something like that.
I thought JSX was just a cosmetic overlay to regular JavaScript functions. I'm not a react expert but I'm pretty sure `return <div>whatever</div>` just returns an object with a property of div and value of whatever. Exactly the same as writing `return React.DOM.div(null, whatever)` or whatever the vanilla version is.
https://reagent-project.github.io/