I'm curious what Angular 2 is like for developers who normally write React? I hear 2 is a lot better than 1, but I'm still turned off by the amount of Angular-specific terminology, whereas most of React terminology is not necessarily React-specific.
Lets see what happens to react. I hear React is building in support for Relay, React Native, other facebook stuff. I <3 <3 <3 react, they have done an amazing job so far, as a React.js consultant and early adopter I owe my financial well-being to React, but big projects from big companies have weird incentives, Conway law, everything made by big companies inevitably goes to shit, yada yada. Maybe Relay ends up being not the best solution to the client/server query composition problem (IMO its not). Maybe people will get burned by 50-shades-of-flux (IMO the Great Flux Wars have barely started) and for the type of company that writes a ton of javascript, the framework pattern will come in vogue again (IMO). Maybe there will be an explosive patent lawsuit where Facebook decides to weaponize its "defensive" patents for whatever reason. I personally believe all of the things in this paragraph will happen in the near term.
In my mind at least, the so called Great Flux Wars have already been won by Redux.
I just finished my first non-trivial app built with Redux + ImmutableJS a few days ago, and it was pure bliss. Finally, we're able to build entire applications as a mapping of pure state transitions on top of immutable data in JS. Redux is by far the biggest reason why I haven't yet completely abandoned JS for ClojureScript.
I'm someone that initially hated the look of JSX (the html markup inside of Javascript thing).
But I've learned to like it. React encourages you to keep components very granular and small and so the amount of markup in each component doesn't really get in the way I find. I've also learned to appreciate how easy it is to reason about what React is going to spit out onto the page because the view is right next to the logic that dictates the various states of the view. Feels very concise.
I still don't like the idea of it, but in practice it works quite well.
..I feel the same way. I prefer creating dom with code syntax.
You can replace JSX by hand-coding with React classes - take a look at the compiled jsx and mimic that. I find it as easy to work with, and less cognitive dissonance [ a personal preference ]
I actually am looking seriously at Mithril in preference to React for my next chunk of work.
I might swing the other way if React native became stellar [ and viably crossplatform ]
> Never understood why people liked React so much. I don't know why, but mixing javascript and HTML just looks... gross.
But you never write HTML with JSX, that's the point. XML like syntax is just sugar that gets transformed into functions. This is not HTML. With angular you need to use string templates which cannot be easily validated by IDEs for instance. JSX syntax validation is straight forward because it's directly integrated in the language.
Your end product has both HTML and JS so there's no way around mixing them somehow at some point. You could do it by keeping them separate and linking between them by means of CSS classes and magic strings in HTML templates. Or you can generate the HTML using JS functions. JSX just gives that latter option a pretty syntax.
If you don't like mixing logic into HTML you're free to create dumb components that only contain as much logic as you would want to put in a template. Such a component would accept properties and output a representation of the resulting HTML. A smarter component that does not generate HTML will provide the logic required for the template to function. That approach actually encouraged and is the right way to do React.
The bonus of this whole generate-HTML-representation-with-functions thing is that you pass around native JS values instead of stringified values and magic strings. Want to provide an onClick callback? Pass a callback. Not some magic string that represents a key which holds the callback in some object defined by framework-specific convention. No, you just pass a raw javascript function that will be run on click.
This might seem like a trivial distinction, but it's the difference between writing native JS vs writing magic framework code. I vastly prefer the former.
Thats the paradox you either go one way or the other. The problem with Javascript or something that turns into Javascript in HTML is it can inevitably lead to magic variables. I don't know how many times I have went in to support another developers angular code and found a variable who's origin can be traced to a scope variable which has been declared and initialized in an HTML file and all the sudden is magically being used halfway thru a routine. It's just shy of globals.
At the end of the day you go one way or the other, my preference is the template not having the ability to affect logic as it is not natural to look thru templates to find what is mutating the state of your application. I liked Dojo and I think react is a step back in that direction which in my personal opinion is the right direction for large web application.
React providing a mustache-like format (like ractive.js uses) would be great - more familiar than JSX and less clumsy than createElement().
Edit response to person below (rate limit): there's no 'problem', just that mustache is still more familiar. Moving JSX into a different file doesn't change that.
JSX/createElement is not just syntax sugar though. It avoids the whole step of parsing the template. Because JSX is JS code, you can pass native JS values to it including callbacks. Whereas anything you could pass to mustache-style templates will be stringified.
So for example in case of parsed templates, to pass a callback to onClick you'd need to define a convention on how you're going to locate the callback by a given string (since you can't pass the function itself, you need to pass some "name" of that function). Whatever logic that will be, the result will not feel like React anymore because you're back to typical framework-specific template magic instead of using plain JS.
This is not what I'm doing. JSX is JS. I'm not putting any logic "in HTML". If I were able to express what I'm doing in mustache-style syntax, it would be:
So, once again, JSX is JS. You're free to write the exact same thing without XML syntax. If you don't like that either, then what you're really saying is "Don't generate HTML using JS". Why not? The benefits are obvious:
* With React & ESLint you get basic checks to make sure you're not passing non-existent variables
* Your IDE understands what you're doing and lets you jump to callback definitions
* You understand what you're doing because you have one obvious place where you do templating and data binding.
* Your actual behaviour logic is still separated from your template, living in some other JS file.
On the other hand, if you add event listeners to HTML from JS the classic way, you get other problems:
* You're querying the DOM tree by CSS classes or some custom attributes. It's surely a familiar way of doing things, but also fragile and unintuitive.
* It requires your JS to know the structure of your DOM to some extent, and that structure is defined elsewhere. So it's basically the same problem as with mustache templates – passing around magic strings – but the other way around.
Mixing of logic and presentation is bad for application, but so don't use <font> tag in your code, because it will be hard for _designer_ to change appearance of hardcoded page.
React mixes logic and structure, which causes no harm, because both are written and maintained by same developer.
Me too. Impression, admittedly only from reading about it and looking at a few code samples, is that Angular 2 is over engineered and complected, as is 1.x, which I have worked in daily for over a year. ReactJs is much more appealing these days.
I've used and followed Angular 2 somewhat over the past year. My take is that React is better for engineers familiar with JavaScript, while Angular may be more comfortable for engineers with a preference for Java/C#. I don't mean that in a bad way; it's simply been my experience that people coming from those languages love what they see of Angular 2, and are repelled by React.
It's not hard to see why. This code[0] from Angular 2 would just be a function in React:
@Pipe({
name: 'tempConvert'
})
// The work of the pipe is handled in the tranform method with our pipe's class
class TempConvertPipe implements PipeTransform {
transform(value: number, args: any[]) {
if(value && !isNaN(value) && args[0] === 'celsius') {
var temp = (value - 32) * 5/9;
var places = args[1];
return temp.toFixed(places) + ' C';
}
return;
}
}
There's also the fact that Angular is a framework, whereas React is a library. Those of us in JS land typically (but not always) prefer smaller libraries.
let's be fair, Pipes can do a little bit more then pure functions. E.g. the async pipe which lets someone directly use Observables in the view is really helpful. And a simple function in combination with Observable.map() or Promise.then() won't bringt that functionality to React (you need to write lifecycle hooks or mixins, and in the end it would look similar to your construct.
I've spent a lot of time with Angular 2 (alpha)[0] and React (redux flavored).
All in all it is fairly similar, and feels pretty good. You have to remember more syntax, because of the configuration, but it isn't as conceptually difficult as Angular 1.x
The templating syntax is "weird", and it definitely adds to the list of things you have to know specific to Angular 2.
React and JSX is nice because logic is just JS, and not special template syntax (directives).
I'd be happy to build an app with Angular 2 or React for different reasons. What's hard is looking at Angular 1 now.
[0] I've given multiple Angular 2 workshops, built large scale Angular 1 apps, and build React components daily for my business (a popular web developer video tutorial site).
We use Angular 1.4 at work, but your reasons are exactly why I'd prefer React. It is mostly just Javascript without a lot of Angular specific conventions. At least Angular 2 looks nearly as good as React and work is planning on upgrading.
