To me it really feels like Polymer is taking all of the pros from both of these "libraries" or "frameworks" or whatever you want to call it and none of the cons. Why aren't we talking more about that? Polymer is a fraction of the size. It's one of several ways right now to write custom components. React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For what?
Sorry, no. My 2016 isn't going to come down to me deciding between React's perverted DSL and crazy toolchain or Angular2's massive cluster$&!% of a bundle with cringe-inducing template syntax. No thanks.
I have followed this long enough. To a lot of people, adding Flux, Webpack, TypeScript, whatever, might seem like the beginning of the future of front-end development, but I see something different. I see 2016 as the year that people slowly begin to realize that while components ARE the future, you don't need big frameworks or libraries or 4000 node modules. This is the year of pure, well-written, and fast web apps. This is the year of framework fatigue.
Polymer is a polyfill for web components, which is an imperative way to sandbox JS/CSS/DOM. It's a very useful tool.
Poylmer doesn't simplify UI development like React does, the components have to be statefully managed, and always will be because creating/destroying polymer/web components is expensive. The beauty of virtualdom is the previous state doesn't matter in deciding what the new UI should look like, or if a component should be added/removed. Simply render off the current state, which is cheap, and then the previous & current virtualdom is diff'd and applied to the real DOM.
Web components are exciting, and React can leverage it to do CSS sandboxing, though people are already effectively doing this [1]. And the cool thing with declarative programming is we can swap out implementations with more performant ones.
To clarify, Polymer relies on web components polyfills. The polyfills are separate and usable by any other project.
Also, components don't have to be stateful. An element can be viewed as a function invocation which accepts attributes, properties and children and returns DOM. An element which deterministically renders some DOM based only on those inputs is very much like a pure function.
React still eventually creates DOM nodes eventually, so I'm not sure what you mean.
How a custom element produces its DOM nodes are entirely up to it, and several approaches fit with a pure functional view of elements: 1) re-render and replace the entire component DOM, 2) Use a VDOM to patch the component DOM, 3) Use incremental-dom to update the component DOM, and yes 4) template systems like Polymer's can be easily used in a pure functional approach.
The key to being "stateless" isn't in abstracting away the DOM, it's in only using the inputs (attributes, properties, and children) to determine the DOM structure, and only allowing the host of an element to modify inputs so that the element behaves more like a function.
It's similar to mutable object that never modifies its own state, only has public state, and whose methods are pure. Method behavior is fully determined by state that the owner controls.
I think they meant that, if you build your stateless web component, you're likely going to have to either recreate DOM elements on every tick (if you're doing something like ng-repeat) or set a bunch of attributes and whatnot... unless you set up some caching mechanism
Next year is the year everyone realises why we had frameworks and tries to salvage the mess they made last year, when they wrote an app 'without a framework' and ended up with an under-specified, incomplete, undocumented, informal framework.
Maybe not. Maybe there is something else on the horizon.
I actually think frameworks are too monolithic, and we feel the pain of that, but no one has figured out how to do something more granular yet. To a large extent that's a community administration problem, not a technical one, which is why you don't see a lot of computer scientists trying to do it. Though it will require some technical chops too.
Node/NPM, and UNIX before it, are attempts in this direction. It's not really gelling yet though. The various component systems are trying, but inevitably fail because they are trapped in a single layer of the framework stack. I think we need a few more breakthroughs in social organizational strategies (things like Flickr, Uber, Bitcoin, etc) before it becomes obvious how to do it.
What we really need is a web standard that allows devs to plug-in a custom templating language extension.
It's dumb that the browser renders HTML, a framework bootstraps, parses the template, then re-renders the view.
90% of the front-end frameworks exist to provide templating + some special set of features.
If we standardize a pre-render hook to plugin custom templating engines then frameworks can shift to focus only on their implementation specific strategies (ex data binding).
I've been programming since I was a kid in the 80's, after a while you learn to stand back sometimes and let the bandwagon roll on past or as I've joked in the past "these days I simply get on every third bandwagon".
Yes, it would seem as a developer there is a certain amount of bandwagon jumping going on in the last few years.
You're very right, you really have to pick your battles. It's interesting since I'm doing more contract work and finding out that one shop uses Angular and another Backbone and a third React. Which one should I really learn and focus on, when nearly every shop has a totally different philosophy??
Even trying to pick the winners in these framework battles is getting exhaustive.
Truth is, it doesn't fucking matter. People are still building jQuery apps. The key is solving real world problems with nicely designed solutions. Doesn't matter what you do it in, how you do it. Just solve a problem.
Sounds like a viable strategy. That's basically my device upgrading plan. Wait for three new releases (in the same series) then "Alright, time for a new tablet/phone/laptop!" I haven't quite jumped on the watch bandwagon yet.
Generally I wait for a winner or something I like then stick with it.
I'm still using knockout.js since I've used it for two years, it's maintained and each release is a big improvement in features and recently speed (massive improvements in 3.4).
Its not that react et al don't interest me but the switching costs are real and I'm not sure what they'll look like in a year.
Yes this may have been true a few years ago but no longer...we are in the of age of programming-trend warp drive where they may reverse every 6 months or less.
How about, everything shifts to isomorphic rendering. Generate an interactive view stub to display on the client while the app bootstraps.
There's no justifiable reason why we should have to refresh and completely re-render the page every time the view changes.
From a 'business perspective' it's worthwhile to have front-end devs build all of the view logic (incl templating, routing, etc) on the front-end while the back-end team focused solely on building APIs, microservices, and data management infrastructure.
If back-end devs are responsible for everything incl templating, the front-end devs responsibilities are limited to... Photoshop, HTML, and CSS?
> React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For what?
State control. The most important thing about a React app is that you can write your code to have every bit of application state inside a single variable. It gets you hot code loading, trivial testability, and session recording/replay. I can actually test the app without having to use selenium (which I hate). These aren't really benefits from React per se but from the vdom approach. My apps are in Clojurescript and don't use the majority of React's features so replacing it with an alternative vdom implementation is on my todo list for this year.
I haven't used it in anger, but Polymer is at the top of my list if I needed to write an app to integrate with a third party or something where I didn't have app state control.
Note that mithril is much more lightweight than react, offers a similar vdom model, but has a completely different algorithm for deciding when to redraw.
I actually think that mithril's redraw algorithm is less intuitive to use than react, but it is way simpler, which has its own advantages.
[edit]
No time tonight to make it pretty and publish it, but here it is[1]. Usage is identical to my parenscriptx[2] (a React tool I wrote that I based this off of).
I was thinking more along the lines of lispyscript[1]. It's not as good as SPOCK[2], or clojurescript[3], but there's less overhead than clojurescript, and SPOCK is known to stretch your javascript implementation in odd ways.
parenscript is quite low overhead; it's approximately lispyscript with common-lisp macros instead of whatever lispyscript has (it looks like some kind of pattern-matching style; there's only one macro example on the lispyscript documentation and the link to an article about more details is dead). In any event if you know lispyscript you can probably translate my code; it took me only a couple of hours to write the initial react version, and another 45 minutes or so to translate to mithril.
Also, thank you for the mithril blog. It is amazing.
Everybody else, if you haven't read the mithril blog[1], YOU SHOULD BE READING THE MITHRIL BLOG. Even if you never plan to use mithril, you'll probably learn something interesting.
Typically, Mithril uses raw JS lists, function calls, and objects to create its vdom, which you have to directly manipulate. Like using react without JSX. With a lisp syntax, you might write the end of an expression as )))))), as opposed to in JS, where you might write )])]}); or something similar.
But it's not strictly parenthesis that bother me. You're right in that )]}) is actually far more annoying. I try not to nest that deep in JS if I can help it.
Arrow functions reduce the pain. Not passing array literals in function calls helps as well. Angular seems like the big culprit that injects [] into the middle of an argument list, for me anyway, and using that syntax is optional.
Well, mithril requires a LOT of array literals and object literals in your function calls. http://mithril.js.org/getting-started.html shows todomvc in mithril. That template would be much more compact, uniform, and readable with a lispy syntax.
I've actually considered the idea of hacking a JSX compiler to spit out Mithril output.
If you're going to mix mark-up in your JavaScript, may as well do it with "real" mark-up instead of some imitation language. I'm still on the fence about whether I like mixing mark-up and code, but I'm leaning more toward at this point.
It did seem like an obvious thing to do. I probably would have searched for and found this before doing any actual work on JSX, but I'm glad to know it exists already. :)
If you want just the vdom model, look at https://github.com/Matt-Esch/virtual-dom
I remember at one point mithril's vdom implementation was based on virtual-dom but I can't seem to find any documentation to back this up.
There are a bunch of alternative implementations. The vdom benchmark [1] is a fairly good list but I've run across at least two more that aren't tracked there.
It's missing ractive, which is one of the oldest virtual DOM implementations build by the interactive team at The Guardian. I use it daily for CertSimple.
That particular link is a strawman argument. React isn't magically fast. Writing a 5 line shouldComponentUpdate would normalize the performance.
If you think you can do better with something else, feel free to ignore the React hype. For my part, I've been doing frontend full time more or less exclusively since 2005 and have tried dozens of libraries/frameworks in earnest. I don't know of a better way to write client side code.
How do you know what things depend on X? if you have Z=Y+X, do you also refresh Z?
State control is not simple when you have many moving parts. A very good solution (which both Angular and React bring to the table without destroying performance most of the time) is to remove all the moving aspects to the parts. This doesn't matter in microbenchmarks, but in real apps, having something be slightly slower but bug-free is better than fast but wrong.
To add to the Clojurescript point: dead code removal. CLJS uses Google Closure and can take part in it's advanced compilation and dead code removal feature. All of the cruft that isn't used, that is abstracted away in CLJS anyway, can be removed when building your code for production.
You can manage state like that with web components as well: store state in one root object, only pass state down the tree, only build DOM based on the given state, use events to communicate changes back up the tree.
The end result is very React-like in behavior, but completely interoperable with other web components, and not require a framework at all.
This is what React does if you don't use Flux/Redux/something similar and it don't scale very well to medium sized or larger codebases.
Web Components hasn't been supported by all browsers (and probably still isn't) and has had some problems with grouping components and loading them. I can use React today but Web Components is something I might want to use in 2-3 years.
Re: state control. The "mediator pattern" is a cool way to write some apps and it addresses a lot of these concerns (with a parent app-element). It's not Polymer specific, but here's a cool video going into a little more detail: https://www.youtube.com/watch?v=ZDjiUmx51y8
Well, browser compatibility is still a big problem with Polymer. A simple click-and-select-stuff-quickly-while-moving-mouse-around test can often lead to focus and/or the selection being "stuck" on Firefox -- even on simple widget demo pages. (This was a few months ago, things may have improved.) Probably on other browsers too.
React works perfectly today.
> I see 2016 as the year that people slowly begin to realize that while components ARE the future, you don't need big frameworks or libraries or 4000 node modules.
What would you call Web Components (polymer) if not a "big framework or library"? That's effectively what Shadow DOM, custom elements, &c amount to -- it's just standardized and shipped with the browser. (Yes, that's a massive advantage, but not until we have 100% working shims and/or browsers that comply 99%+ with the specs.)
EDIT: I should also say: Polymer itself is quite opinionated about how you should structure your custom components (and thus JS code) and this may be a disadvantage to some. This doesn't seem to affect Web Components per se, so that's something. Also, something like the virtual DOM will probably still be needed for speed.
I should say, my post was more about web components and less about Polymer. Polymer is just one way to do it right now, and you're right, it is opinionated.
You don't need a library at all if that's what you prefer.
The polyfills are there now and they are solid. Webcomponents.js is small and effective. The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper elements. That's not what I'm talking about here.
> The polyfills are there now and they are solid. Webcomponents.js is small and effective.
This leads to a tangential point which I find somewhat interesting to ponder: If the polyfills are good enough... then why does this actually need to be a browser standard?
I'd really like to get to a place where we (collectively) find some sort of minimal API-type "thing" that browsers need to support such that everything else can be polyfilled. I would even go so far as to include things like future ES standards in that, such that you could just "plug in" (in the page, not the browser per se) a shim for ES2015 and it would work near-natively. I know Microsoft Research had at least one project going in this direction -- unfortunately its name escapes me at the moment.
> The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper elements. That's not what I'm talking about here.
FWIW, that may very well be true. AFAIR all my tests were done with the paper elements.
I definitely agree that Web Components in some form is the future of application development for the web -- unless we're talking stuff that mostly just wants to use the browser as a delivery platform like WebAssembly. Of course that may change if/when WebAssembly can interface well with the GC/DOM/etc. (Well, come to think of it Web Components might also be massively useful for authoring documents sanely using custom components for higher-level semantic elements, but that's a digression.)
Just FTR as well, I have actually implemented a small application using Polymer just to get a feel for what it's like. Overall it was reasonably pleasant as Web development goes, but it's really disconcerting that all the state[1] passed down to sub-components gets represented using attributes-but-not-really-because-they're-not-primitive-types-any-more.
[1] At least, that's the idiomatic way, AFAIUI from Polymer documentation.
EDIT: I should edit while I can: I semi-believe that Web Components is sort of along the right lines wrt. what needs to be standardized (and perhaps WebAssembly + an interface to the WebComponents API can do the rest?), but frankly I probably don't have nearly enough expertise in this field to even have an opinion. So there. :)
This is what the Extensible Web Manifesto is -- an agreement from browser vendors to build in low-level primitives so that things can be implemented in user space:
Thanks for pointing this out. I (as I'm sure many others) was not even aware that such a thing existed.
Having said that...
- Is that the actual manifesto? I couldn't find any link to any more detailed document, but maybe it's a browser/adblock thing.
- If yes, then... I agree with nearly all of it (having just skimmed it), but it seems a bit... bland and fluffy (as opposed to concrete).
That's not exactly what I was imagining with my ever-so-specific "API/thing" nomenclature :) I was thinking more along the lines of a "universal bytecode for web", but a) not just for code, and b) one that actually works. Maybe Java 25 will get us there, who knows :)
That's a little closer, but AFAICT it's just a bunch of added "signatories" -- again from a skim-read.
In the long run, WebAssembly may be it. As of the promised-1.0 it's just a way/excuse to run C/C++ code on the browser's VM with some GL/Canvas mixed in there. I mean, I understand marketing a FPS-game-in-the-browser as the be-all and end-all thing, but that's not my market or end game :).
It'll be really interesting to see what happens with WebAssembly 1.1, 1.2, 2.x... Will they be the ones to surmount the insurountable obstacles?
(I've been around for quite a long time in the industry, so... having learned things and just how much the last 20% takes, I tend to temper my optimism quite a bit.)
That's fair enough, but I guess I just don't think there's enough... commitment in that?
I appreciate the point about meta-standards vs. standards. I think I'm more looking for concrete technical standards (to obviate all others before them![1]) than meta-standards. The web has advanced significantly in the last few years, perhaps even as a result of this meta-standard, but ultimately I'm skeptical that competition between entities that don't have the same goal will "succeed"[2] in any objective sense. The point me be a a bit muddled at this point, but think "principal agent problem".
[1] Because that always works! (Find your own XKCD)
[2] Yeah, I know. Everybody has a different idea of what that means.
> but it's really disconcerting that all the state[1] passed down to sub-components gets represented using attributes-but-not-really-because-they're-not-primitive-types-any-more.
React, Angular 2, and probably most other frameworks with templates do the same thing.
If it makes you feel any better, the key point for me is that these are not HTML, they're templates embedded in HTML via a DSL. This DSL is valid HTML, but it's necessarily interpreted and modified by the template system.
Also, it's great that these values are not primitives. One of the persistent detractions (made by a core React dev I think) against Polymer is that "everything is a string because attributes", which is just wrong. As you note, Polymer uses attributes in template to declare binding to properties in the resultant DOM, which can be of any type. I think it's great that you understand this distinction, even if you don't like it :)
One thing I like about both Polymer & React is that they encourage you to treat your apps as a composition of components, as opposed to each page being a wall of HTML with a few variables substituted in.
That being said, React really makes it easy for those components to be tiny little things that do only one thing, that compose nicely, and that are easy to understand. There's a heuristic in programming that if a function is more than a page in length, it's probably too complicated. The same heuristic applies to React: if your component (JS, JSX & CSS together) is more than a page, it's probably too big.
Just the act of splitting apart the JS, JSX & CSS encourages the components to become much larger.
Why did Google create Polymer? Google isn't using it. This is almost the same 'problem' with "AngularJS by Google", it's almost never used by Google.
Edit: The reason I like React more is the fact that Facebook uses it in a high traffic production setting.
Edit 2: I think the whole Javascript (or framework) fatigue is just a 'transition problem'. Old tools are getting replaced by new tools, causing confusion..
I believe people generally mean that Google isn't using it for any of their core products: Gmail, Search, Google+, Photos, YouTube, Google Play, Calendar, Drive, Maps... none are built with Angular.
Adwords was not in that list (madewithangular) so I simply supposed it wasn't made with angular. Neither is Analytics, or any of the tools I use from Google.
If Adwords is Angular then that's one big project on Angular (clap clap clap). However, all I ever heard was that they were planning to move to Angular2 on Dart. I wonder how that worked out.
edit: just editing to add that I´m not doubting that Google is using Angular2 in some projects, like their internal CRM (Green Tea or whatever). I simply wanted to point out that it's not used _extensively_ in their main consumer facing sites - the ones you get links to when you click on their apps dropdown menu.
It's important to note that Google does give it's developers the freedom to choose their own tools. If a team isn't excited about Angular or Polymer, it's not forced on them.
If I was building a webapp that was going to have hundreds of millions of users, I'd think twice about grabbing an off the shelf JS library.
JSX is very much optional, despite what the docs imply. I've had good luck with converting a DSL that I was using to spit out HTML to React components that made the transition fairly painless: https://www.npmjs.com/package/recup
I've been using just the custom elements polyfill (6KB gzipped) and love it. I definitely think web components will do to React what querySelector did to jQuery. It's so nice to get rid of the bloat of these libraries, get out of dependency hell, and just write pure javascript again.
At work we are using Polymer / Web Components since version 0.5 and have been enjoying it's structured approach. I was skeptical at first to use html tags to add data models, AJAX requests and non-visual parts of a web app. After the initial shock though it does result in more declarative code and helps our codebase stay organized. Long term, the investment in web components makes sense as they become standard and native to most web browsers.
This will only happen when there isn't a significant portion of new programmers entering the field/language/type of work. As long as there are people that don't know how to write pure, well-written and fast web apps, large frameworks will have a place. This is a good thing, because the more new programmers that try to figure this stuff out themselves the more clusterfuck projects we have. Frameworks allow for an easy onboarding process, where the people that need to reach deeper to accomplish something then look how to do that, and learn as they go.
There are parallels here with languages. Perl, which garnered a reputation as a write-only language, has seen a dramatic increase in the quality, legibility and effectiveness of modules over the last decade, and this corresponds well with the lack of an influx of new programmers (but with a minimum core of users still present to implement new modules). That said, there are many, many other problems when you don't have enough new blood flowing into your ecosystem, so I don't recommend it.
I think you're gonna like Aurelia[1]. It's badass compared to Angular 2, React & Polymer. You get this really, really nice feeling of writing pure Javascript. It's smaller than Angular, strictly follows Javascript standards which is soooo nice.
No
{{bindingVariable}}
but instead:
${bindingVariable} // Just like in Javascript template strings!
Binding? Sure:
<input type="text" value.bind="variable">
Two-way? Of course:
<input type="text" value.two-way="variable">
One time? Yep:
<input type="text" value.one-time="variable">
The templating is so simple, as it follows the APIs as well, for example - how would you bind markdown to the innerHTML of an element? Well, just pass the variable through a ValueConverter in your bind:
<div inner-html.bind="variable | markdown">
It is also pluggable. You can replace almost everything in Aurelia with your own implementation very easily.
Are there any examples using this in the wild? I couldn't find any 'Sites powered by Aurelia' page on the site. Would be interesting to see some full fledged sites (besides the project site).
Well the docs[1] are built using Aurelia, and it's really cool as it fetches the framework API directly from their GitHub repos via GitHub API and caches it on clients computers.
I am currently in the process of re-building our company website with Aurelia (previously Angular 1.X).
Yes, you can do it without `polymer`. But I wanna work with it. `polymer` will give more free times to do something funny more than think about, how to expand this app, how to control all states...
In my opinion, walk on BigBoy's shoulder will faster, and get wider vision
There is more to web development than building components. There are also things like accessing a backend, building authentication services, etc. that developers need to worry about.
Are you under the impression these things aren't possible (or even easier?) with web components or vanilla JS? You don't need a big framework for any of that.
I'm building an app with Ember, and I like how it abstracts away the more tedious aspects of web development without preventing me from moving to a lower level of abstraction when I need to.
I've built a small app in vanilla JS, so I know what the alternative to using a framework is like.
Doing XHR by hand is not easier than using Ember-Data.
Writing custom JS components is not easier than extending Ember's Component class.
First of all, let me share a wonderful (and performant) mobile app, written in ember. It uses ember-data to connect/normalize the iTunes api, and provide a slick fast mobile experience.
Disclaimer, I work on & with Ember.js (and I didn't work on https://fnd.io)
I've worked on several mobile web apps using ember, and performance did require being careful, but often "being careful" was nicely aligned with the mobile UX people expect. Small screen, put less stuff on it. etc.
Often times, we do see issues with ember on mobile, typically this is due to deeply nested loops of UI components being rendered. And most often, performance on mobile was an after-thought.
PSA: Regardless which framework (or no framework) you use, if you are shipping to mobile. Test/develop on your target mobile devices from day 1, you will not have any surprises, and you can catch performance related issues before they fester.
As for the discourse post, there are some issues ember is working to improve. If one reads further, it outlines the largest concern being the growing gap between JSC (Safari, which offers near desktop performance for discourse on mobile) and V8 (which doesn't do so well on mobile for discourse) performance. Year over year, the iOS experience is improving, but the android/v8 experience does not appear to.
The TL;DR of the issue (as is currently understood), is JSC handles dynamic code better, whereas v8 does not (yet) and Ember should both reduce the dynamism and continue to do less work. Which will continue to improve the experience for all consumers.
This is actually quite an interesting issue with lots of details, I could go on, but this is likely not best place for anything in depth.
The important part being, all parties involved are working towards (and together) on a better faster more wonderful future.
Ember with another (faster) iteration if its rendering engine: https://github.com/tildeio/glimmer (written in TypeScript),
V8 with turbofan
and the team, working together to improve JavaScript in the browser for everyone.
The right question is: "are there any substantial apps that take advantage of native Web Components (polyfill or not)?" The answer to that is: "yes, a lot."
Polymer is just one way to write the components. X-Tag is another. Pure JavaScript is another. Use one of them or use them all. No big overarching framework required.
But it's not just about writing individual components when you build an app (you need something like a router still for instance). I say this as someone who rather likes the model Web Components espouses. Developer ecosystems matter a lot - for development, debugging and hiring. At present you have a great many more resources/communities to reach out if you go with React. When you get stuck with Web Components or polymer, and you will get stuck, you are a lot more on your own.
Also, for building you are, at least presently afaik, limited to vulcanize instead of the richer set of tools out there for more typical patterns. Vulcanize is cool, but again - if you get stuck, and you will if you do something complex - you have to rely on a much smaller community to help you out.
Hey Rob- that was probably unfairly harsh of me. I have tried to like the syntax for the last year and I've had trouble.
Anyway, I know you are a big contributer, do you mind showing me the discussion where we determined '*ngFor=' and '[(two-way)]=' was implemented to play nicely with WC? I would be interested in reading. Thanks!
No, it doesn't play nicely with HTML or XML. It's arbitrarily and pointlessly incompatible with HTML for no good reason, which is a huge easily avoided mistake, that makes me question the judgement of the people who designed (and evangelize) Angular 2. Please see my other posting about that. [1]
My simple question that nobody's been able to answer yet: Name any benefits of the broken Angular 2 template syntax, that couldn't easily be achieved with a non-incompatible, HTML-friendly syntax.
The "Databinding with Web Components" design document [2] makes the dubious claim that "The HTML attribute name of a databound attribute must be escaped in some way."
That is precisely what namespaces are for, so why not simply use namespaces for the purpose they were meant to be used, the same way any well designed standards compliant template languages like Genshi [3] does, instead of inventing a new, non-standard, incompatible syntax?
The entire point of the design of the XML namespace prefix syntax was so that it was compatible with XML syntax. Why do the Angular 2 designers think that was such a bad idea?
I'm not the only person to point this out and have it brushed off and ignored by the Angular 2 team.
"Regardless, it is inappropriate for the angular team to take a hard anti-xml stance." [4]
"I wonder why ngnl presentation and current docs about templates still promoting []()# as parts of new syntax, when opening post in this thread contains 'element.setAttribute('[foo]', 'exp') does not work' and, especially 'SVG requires valid XML and []()# is not valid XML.' If these problems are solved somehow and we just don't know - please let us know." [5]
"Given the lack of xml/SVG compatibility, I would say that the []()# syntax simply fails to meet the constraints, and should be eliminated altogether in favor of the prefix proposal." [6]
"Please don't break HTML syntax :( I love Angular because I can write templates for it in any templating language like SLIM or HAML or Jade (you can't do it in Ember or React, for example). Introducing non-standard characters in attributes makes templating languages unusable (as well as syntax coloring and introspection in IDE)." [7]
>Sigh. Yes, Angular is a framework, React is a library. Some say this difference makes comparing them illogical. Not at all!
Agree. This BS "oh, it's like comparing apples to oranges" knee jerk reaction should stop.
For one, even if Angular is a superset, we can always compare the parts that both have: component model, templating, etc.
Second, when we say React we almost ALWAYS mean React + Router + some Flux lib, etc. -- so all the same things you get with Angular, just cherry picked.
Third, we can just as well compare Angular (or any framework) with building something from scratch with vanilla JS too. Nobody said we have to compare them "as frameworks". We can compare them as different "ways get a web app done" (with/without framework, without framework but with x lib, etc).
Fourth, we can always compare apple's to oranges. Here's a comparison: oranges have more vitamin C than apples, and are better for scurvy (haven't checked the actual vitamin C stats, but you get my point).
If you're comparing flux + react + router to angular, then I feel like your missing huge aspects of what makes react valuable. I feel like when people talk about the awesomeness of react, they talk about the ecosystem around it.
It's the fact that Facebook has broken up react and all the surrounding architecture in a new way that is modular and logical for sharing code efficiently across various elements of a project or across projects. When I get excited about react, its because of things like Graphql coming out which is an entirely new way of interacting with your server that makes client side development significantly better.
They are creating entirely new ways of how you interact with the server side from the client side. This is why I love react and everything surrounding it. Not because it compares well to some random JS MVC that is completely tied to the DOM like angular, ember, or polymer.
When I say React, I mean just React - I already have a large complex app with persistence, routing, legacy components with multi-year investment in development etc. - I just want to be able to add performant componentized rendering to problem areas of the app.
And that's what React is able to do, because it's a library, not a framework.
Can you use Angular's components & templating outside of the rest of its MVC architecture? Despite the insistence on HN that React = React + Router + Flux, I've been using just React with plain js objects for models, and I like it exactly because it's an easier way of writing simple interactive views.
What if it can't? (I don't develop apps using Angular, so I really don't know the answer...)
Then it's just a con for Angular, but also a pro for providing a default MVC architecture to rely on. It's a design choice that can be both good and bad.
> Second, when we say React we almost ALWAYS mean React + Router + some Flux lib, etc. -- so all the same things you get with Angular, just cherry picked.
This premise is quite silly. Not every programmer is looking to create or adopt a framework in the beginning of a project. Some people just pick and choose libraries as they see fit and as the code evolves. I've worked on more than a few React projects and none of them use a Flux library or a routing library, simply because they were not needed.
Hence: "cherry picked". You don't have to pick ALL the parts if you don't want. You can still compare a full framework and the 2-3 items you cherry picked though as methods of getting web apps done.
Who said those who use Angular will just use Angular only as it comes upstream and won't pick and/or substitute a few libs for third party ones either?
Of course it's not forbidden. It's just confusing to say you're comparing React to a framework, when you implicitly include things other than React in the definition of React.
This is continuing to shape up to be another one of those preference debates.
I prefer the Angular approach, as its end goal is to simply make web markup what it should be: Interactive. The downside being that you're forced into Angular's opinions for better or worse.
I don't prefer the more "tangled" approach of React. I call it tangled as it's mixing two flavors in one "view", whether you like it or not: JS and HTML. Many people like the approach, and I can see why they do. I don't.
Those are preferences. So much more goes into making an app efficient, testable and expandable. The biggest ingredient is comfort. If you and your dev team are comfortable with React, that's going to be your best option. It's not the wrong option, it's a great option. For me, it's Angular.
However, I feel compelled to say that the debate should be Angular 2 v React. Having used others (... Ember....) it just doesn't make much sense to use anything outside these main 2 contenders unless you're using some of the new "cool" web components based stuff. Angular is solid. React is solid. Compare, contrast and make your decision based on how comfortable you feel with the getting started docs.
You're really missing the point here. The fact that HTML can go in the same file as JS is a tiny and trivial detail. If you don't like it, just put your JSX in a separate file and import it.
How often do we list static data in lists anymore? Honest question. It feels like most websites you view anymore are displaying data fed from somewhere that isn't known when you write the markup. As you write markup some is meant to repeat data (lists of posts, reports, etc.). Since this seems to be (to me) happening more than not, markup needs at least some kind of update to accommodate the fact that when writing it, we don't typically write out static markup anymore, though the end result obviously is.
Therefore, Angular, to me, acts like that "dynamic markup" when writing it. It feel more natural to me at this point.
I've used Angular, React, and Handlebars (Ember's templating engine), and I can tell you, they are all the same in "tangling." They all solve this problem by emphasizing that the view portion of the code (Angular's pseudo-HTML, React's JSX, and Handlebar's limited helpers) should be used strictly for view-related logic, not domain/business logic. So there really isn't any difference between the libraries in that respect, except for personal taste.
Just a pedantic touchup, ember does not use Handlebars (it once, several years ago did) Now it uses something (Glimmer) which shares some syntactic similarities, but usage/implementation have diverged.
> Doesn't Angular mix HTML and JS too, except in the HTML file?
Angular2 doesn't. Like React it uses a HTML-like templating syntax to generate views. Nothing is mixed in Angular2, everything is defined in JS and rendered as HTML.
React's learning curve is tiny compared to Angular. With React, you need to understand the component API, which consists of about 5 methods that one uses regularly, and the top level API, which consists of 2 (or just 1 if you use ES6 class syntax to create components).
And as the article points out, it's just JavaScript.
I've briefly used Angular 1 a few years ago, and have been involved in the React ecosystem for the last two years. I really like React, it gets a lot of things right and I think it has a bright future.
But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development. As soon as you get past a "hello world" Todo app, even trying to figure out what questions to ask to get to a scaleable app design can be tough. There are good, stable solutions to most common problems like state management (Redux) and routing (React Router), as well as a ton of other goodies like server-side rendering and hot module reloading available, but if you don't know what you're looking for you're in for a lot of contradictory and sometimes outdated advice about what tools to use for what, and the best way to wire all of them up.
That said, this is an issue that the community is acutely aware of (there's been a lot of chatter on Twitter about it recently, although there's definitely still more questions than answers) and one that I think will get better with time.
> But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development.
Totally agree. Doing anything large-scale is hard, and comes with a massive learning curve. No React or Angular can save you from learning what it means to go from "hello world" to working on a project with a team of, say, 10 people.
When you factor in the learning curve of the usual tools that go with React like Flux/Redux, Webpack, Router and whatnot, the combined cognitive load becomes a lot.
Yeah, additionally React has a serious paradox of choice problem.
Which of the dozens of CSS solutions should I use? Inline styles or not? Which of the dozens of Flux libraries? Isomorphic/universal or client side? If Isomorphic, Express or Koa? Does react-router work with the choices I've made? Webpack or Browserify? It goes on and on...
I love React, but the environment and best practices are unclear to say the least.
There is also a lack of best practices, combined with constantly breaking changes. Every tutorial before the last month is already outdated, and everybody has a different way of setting up webpack / isomorphism / templating.
I call bullshit on you calling bullshit on every point of this comment.
> How many 'best practices' do you need?
Actually, there should only be one way to do something in a framework. While not a framework, think about the Go language. Go is a very strict, almost paternal language that 'enforces' best practices in the language itself by giving you only one way to do something. Angular, on the other hand, provides numerous ways to create a service. Because of this confusion, the Angular team provides best practices. It's like saying, 'we screwed up in designing this thing, so you have to read all the documentation to find out the subtle differences in all this bullshit.' It's not the lack of best practices that concerns me, it's the abundance of them that gets shipped with a bloated framework that wasn't designed well.
>Every large release?I seriously doubt it.
Think of all the pain involved in removing all of the digest cycle code when switching from Angular 1.4 to Angular 2.0.
> No they don't, maybe a small differences and what do you mean with 'templating'? It's not Angular.
Seriously? There are no small differences between Django templates, Soy templates (client and server side), and Angular templates to name a few. They are all very different yet they do essentially the same thing. At least Soy templates can be used outside of a framework (with either JS or Java).
You don't need Flux/Redux to use React. React without a Flux-alike is very much like Sinatra compared to Rails. If your goal is to learn React, Flux gets in the way, and you shouldn't bother.
Browserify/Webpack is a giant pain and my least favorite part of this programming environment, but I'm not clear what it has to do with React. Is the concern here that React is packaged in such a way that you can't use it with a simple script inclusion, and that you must use a bundling system?
Router libraries are even less essential to React than Flux. I've never used one.
Webpack is used for hot reloading otherwise Gulp can suffice to provide you with a command to compress your css and jsx files. You could do it manually with the cli to begin with but I'd use a build automation tool going forward.
You get the advantage of choosing any of those libraries/tools that make up an application (e.g. choosing a router library that makes sense to you [or the team] and/or for your app). Thus, intrinsically the learning curve is much more digestible than grokking why certain parts of a monolithic framework (e.g. Angular) are designed the way they are.
However, that may also lead to being kind of paralyzed by the amount of choice you have. I know I'm not alone in sometimes preferring to have most of the[1] choices already made for me. (Especially when I'm not really a domain expert nor interested in trying to keep up with all the newest goings-on in the area.)
This is a good point, but to be fair you need to learn and implement similar solutions in an Angular-based project. You still need to implement a layering architecture that separates application/model state from view state (e.g. Flux/Redux), a module system (e.g. Webpack, Browserify), and a router (e.g. ui-router, react-router).
I had the complete opposite reaction. I learned a bit of React through a rails + react tutorial and I was lost pretty much the entire time. Having to write HTML using either JSX or the ReactDOM syntax was a complete nightmare. Granted the testing options of both beat out angular, but even at a surface level React just wasn't appealing.
> Having to write HTML using either JSX or the ReactDOM syntax was a complete nightmare.
Can you expand on this? I find writing JSX to be a breeze. JSX is basically HTML with a few small tweaks (e.g., for => htmlFor, class => className). If you use a linter, it will catch those mistakes for you while you're learning.
I think that in order to start seeing the appeal, you have to have seen the alternative. Before angular, I was writing a lot of backbone apps, and generally, they were well organized and easy to maintain.
With angular, I've found that my apps have devolved into a huge tag soup very quickly. It didn't take me long to realize that the templating syntax was a huge part of what made angular suck really bad, and its like the article says: "Angular 2 continues to put 'JS' into HTML."
So to me, JSX is at the core of what makes React feel manageable, since I can use OO and encapsulation techniques of javascript to deal with complex rendering and still keep my code organized and easy to follow.
The more I think about it, angular reminds me a lot of Coldfusion in its approach.
I used backbone a lot too, and despite their obvious differences, react feels like backbone's spiritual successor in terms of being 'Just Javascript' that solved problems, rather than a fullblown framework.
For the longest time I totally saw react as replacing backbone views, but in practice that was unwieldy and the stateful, unidirectional approaches (Jesus that needs a catchy acronym!) made more sense given what I was trying to achive.
If you're just building components, the learning curve for Angular2 is no different.
All in all, it takes about 20 lines of code to define a simple web component.
If you're using either Angular2 or React for anything beyond trivial examples (ex, routing, AJAX, lazy loading, isomorphic rendering, etc), things become more complex.
If anyone is new to both frameworks Angular 2 or React; I would prefer React. I have learned React in a day. I can use my existing knowledge of js in React (for, if etc), whereas in angular learning those directives is still a pain (in Angular 2 as well).
I love the fact how each component in React can be composed! Its just beauty!
There are some slight inaccuracies here, such as file size reporting - Angular 2 is fat at the moment only because it is bundling the whole kitchen instead of just the one piece that is the library itself. The Angular 1 number also is off too - this link is giving me 52.8 KB for example (minified + gzipped): https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.0/a... (all numbers I remember seeing for angular 1 were around 120 KB IIRC). I'd suspect all the other numbers are off too, but I haven't investigated.
There is a strong argument against doing what JSX does in moving the HTML to JS - you allow developers to fall into the trap of creating complex conditional DOM that is hard to read without a disciplined team (if statements all over the place with imperative DOM construction for example). Neither approach of JSX or Angular's templating (or any other similar system to either) are without its warts, and this falls into an opinion discussion without real winners excepting for however a particular team prefers their templating.
One thing that wasn't discussed but that may come into play - the performance numbers out there for Angular 2 currently is extremely impressive. Optimized Angular 2 code is generally performing at about 2x the rate of other frameworks/libraries out there for UI rendering/repainting, and unoptimized Angular 2 code is performing at roughly the same parity as optimized React code (although optimized/unoptimized React code performs very similarly in many situations, which is a huge benefit of React).
I'm personally on the Angular side of the fence, I prefer the more declarative style to avoid the imperative DOM construction, but I could work with either (and have worked/am working with both) if they are done right. Both are impressive libraries though, and both have strong merits - at the end of the day, it comes down to how your team works, and what they're productive with. Both libraries are bringing excellent changes to how we do things in the frontend...I just wish tooling was there in maturity, that seems to be the greater pain point currently.
> I'm personally on the Angular side of the fence, I prefer the more declarative style to avoid the imperative DOM construction, but I could work with either (and have worked/am working with both) if they are done right.
If by declarative, you mean artificially limiting, then I agree with you, but in my humble opinion, the React approach allows for far more declarative UIs than approaches that come before it.
Templates ultimately limit UI semantics to the subset designed into the template language. Modeling the DOM as a pure JS data structure gives you the entirety of the expressive power the JS programming language, and allows you to construct your UI as a pure declarative mapping between components/elements and your app state (the approach taken by Redux and many ClojureScript frameworks), with no imperative manipulation whatsoever.
React uses an imperative style, not declarative - when one uses this.items.map(item => <li>{item.name}</li>), this is imperative, not declarative. You are describing the DOM with imperative language - JSX cloaks what is truly an imperative nature. This is made more clear with the non-JSX equivalent. When one uses an if else-if else, while, switch, or other similar control flow statements, one departs from describing, to imparting the details of the implementation. The only part declarative about JSX is the conversion of certain code into valid text/attribute values/etc. into the HTML, which I'd hope is a minimum requirement of a useful templating language.
Angular's templating is clearly declarative since one is not making a statement about how it arrives at its result, but purely describing it and leaving the implementation elsewhere. Something like <ul><li *ng-for="#item of items">{{item.name}}</li></ul> leaves the iteration implementation away from the view completely. Every piece here is descriptive, not something more.
It should be noted that Angular 2's DOM model uses an AST under the hood, just like React - fundamentally they are the same in the virtualization of the DOM. Angular 2's templates are not true HTML either, but is closer to HTML than React is in its syntax. It does limit what you can do, but that is the purpose of templating languages - it limits what you can do to increase readability, increase consistent patterns, and steer users away from dangerous usage. That is an argument aside from declarative vs. imperative templating, and more emotional than useful.
Now, both approaches have obvious flaws - both styles are easily (and often) abused, but both also have simple conventions to keep it clean. Imperative construction (ala React) requires one to carefully organize the control flow to avoid convoluted template construction. Declarative construction (ala Angular 1 + 2) requires one to avoid tossing too much in a singular template. What is easier to work with, that is not for me to say as an absolute, but IMO carefully organizing the control flow in template construction requires more mental overhead to avoid constructing the template in a hard to read fashion, and yet still involves the same ultimate basic strategy of having to create separate components to avoid overly complex templates, which is what one has to do with declarative template languages, but without the mental overhead of accidentally abusing control flow in its construction.
Defining UI as a functional map of the state is the one of the most declarative ways of viewing the problem, IMO. Templates are maps too. The problem with templates, historically, is that they've been used only for the initial state, and abandoned for later changes because rerendering is expensive.
Code written in language that allows imperative constructs != imperative code
I would say that React is far more friendly to a declarative style than Angular 1 at least. Immutable data, redux, and virtual dom all encourage this style, whereas the path of least resistance in Angular 1 is definitely imperative mutation of state. Anyway, if you're doing significant amounts of logic in your JSX/angular templates, you're Doing It Wrong.
Unfortunately, the declarative style of programming might not be exactly what you seem to think it is. Take a look at the Wikipedia page for declarative programming: https://en.wikipedia.org/wiki/Declarative_programming
"Although pure functional languages are non-imperative, they often provide a facility for describing the effect of a function as a series of steps."
"While functional languages typically do appear to specify "how", a compiler for a purely functional programming language is free to extensively rewrite the operational behavior of a function, so long as the same result is returned for the same inputs. This can be used to, for example, make a function compute its result in parallel, or to perform substantial optimizations (such as deforestation) that a compiler may not be able to safely apply to a language with side effects."
Pure functional mappings is one of the textbook examples of declarative programming. It might look like you're specifying steps to get some result in the code, but that's the wrong conceptual model. You're actually specifying the resulting data you want as a set of functional transformations on top of some initial data. Exactly how the program arrives at that resulting data from the initial data (recursion/loops/inlining/whatever else) is up to the language runtime/compiler, and not something that functional programmers needs to worry about, thus why it's declarative and not imperative.
React and Angular's approaches to templating are both declarative. React's approach simply offers more expressive power by allowing the whole set of functional transformations in the JS language rather than some artificially limited subset. React's approach also allows for this declarative approach to extend to the entire application architecture by modeling entire apps as pure functional mappings between state and UI.
UPDATE:
> When one uses an if else-if else, while, switch, or other similar control flow statements, one departs from describing, to imparting the details of the implementation. The only part declarative about JSX is the conversion of certain code into valid text/attribute values/etc. into the HTML, which I'd hope is a minimum requirement of a useful templating language.
This hints to a bit of a misunderstanding of what exactly JSX is. Control flow statements are not valid JSX code precisely because JSX is a purely declarative description of UI. [1]
It's pretty easy to write "complex conditional DOM that is hard to read" in both React & Angular. But in my experience, I encounter it a lot more in Angular code bases than React code bases.
That's certainly a fair statement - I found the imperative style generated from JS directly harder to debug/work with in general, but that's why I mentioned it's a bit team dependent. Each developer's experience is going to bias them towards one or the other.
The foolish, totally avoidable, misguided and completely pointless mistake that Angular 2 made was using a template syntax that was almost but not quite completely unlike HTML:
<ul>
<li *ngFor="#hero of heroes">
{{hero.name}}
</li>
</ul>
or:
<web-component [title]="exp1" (close)="exp2()">
That is INVALID html and INVALID xml. That means you can't edit or process or generate or validate Angular templates with any of the millions of existing HTML and XML processing tools. They have completely forsaken the entire universe of existing tools, for no good reason.
The Angular 2 template language gets absolutely zero benefits from arbitrarily disobeying HTML syntax. There's nothing about the broken syntax that makes it any more powerful or tangibly convenient that could be done by an HTML or XML compatible syntax.
Maybe it appeals to Perl brogrammers, but the hip stylish syntactic appeal of peppering templates with unique special snowflakes of punctuation like they were so many christmas tree decorations does not outweigh the dire consequence that you can't use an off-the-shelf HTML editor to edit and preview templates, or use any of the many other existing HTML tools to do whatever they're designed to do.
I've encountered Angular 2 proponents who were such blind zealots that they actually refused to see any benefits of sticking to standard syntax and enabling the use of existing tools. They would ask things like "why would you ever want to edit an Angular 2 template in an HTML editor?" or "why would you ever want to generate a template from another meta-template?" or "why wouldn't you want to write your own Angular 2 template validators and editors and processors?" or "why wouldn't you want to retrain all of your html designers who can't use the tools and syntax they're accustom to?"
Yet they were still unable to name any tangible benefits of the broken Angular 2 template syntax, that couldn't be achieved with a non-incompatible HTML syntax.
I'm afraid that they next thing they'll do is invent their own incompatible version of Unicode.
React has a non-open license: https://github.com/facebook/react/blob/master/PATENTS, which basically says that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement.
This is an automatic no-way for React for any major company
To be clear: only the patent license ceases, which is something you wouldn't even get in the first place with most other licenses. It may also be that no patents are used in React at all. I personally do not know of any that are. (Disclaimer: Not a lawyer, not speaking on behalf of FB, just my own reading of the language.)
Yes... I'm really surprised that people aren't talking about this more seriously. They have removed the worst of it, but it still looks like it gives Facebook an advantage in any patent conflicts with any company that uses React, Immutable, Hack, HHVM, GraphQL, etc. anywhere in the dependencies. It appears that the PATENTS file claims that if Facebook infringes on your patents, you can't defend your patents without a risk of immediately losing the ability to use React (or other Facebook library). Maybe a lawyer would be able to make more sense of that PATENTS file.
I'm surprised that Apple might be using React, since they have had big patent battles with Facebook:
I've heard that Google doesn't use React, but I don't know how long companies will be able to do that as Facebook libraries increasingly become dependencies of other libraries.
I don't have links to any; they might be all internal. The current iteration of the patent grant was developed in collaboration with Google to meet their needs, so if there is any complaint they still have with it, that is news to me.
Only public evidence I have of this is Firebase (owned by Google) being unwilling to use React and then happy with the new license:
I would like to find out more specific information. It seems like the section of the license below says that you can never make any patent claim against Facebook or you lose rights to use the software. Doesn't that mean that Google could never initiate patent claims against Facebook, while Facebook could still initiate patent claims against Google? It seems strange that Google (or Apple) would do that. I am not a lawyer though, and the PATENTS file may not mean that.
> The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion: (i) against Facebook or any of its subsidiaries or corporate
affiliates, (ii) against any party if such Patent Assertion arises in whole or
in part from any software, technology, product or service of Facebook or any of
its subsidiaries or corporate affiliates, or (iii) against any party relating
to the Software.
"The Virtual DOM, among React's most compelling features, has also seen its core ideas filter into other framework projects. But more importantly, React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This has already generated some concerted pushback from both WordPress's Calypso and React contributors."
I've been trying to solve this overly-complex-scaffold meme by chronicling my own research into React/Flux in a Yeoman generator. It's really simple and in addition to React/Flux basics, how to make REST calls to a Node backend/hook up React Router. It's not quite done yet though.
One of the biggest problems I have is the number of things I need to install at $EMPLOYER to make it all work. Typescript I can get approved because it's "Microsoft", but Node/NPM and Ruby? (for SASS) Not a chance - even if it could make it out of the NTLM-auth proxy.
Node/NPM is installed as part of Visual Studio 2015 these days, is it not?
Edit: Note I'm not saying you should install VS2015 just to get Node, but it might help you convincing the powers that be that "hey, Microsoft installs these components as part of VS2015, so it's not that weird, I promise".
The only reason you could have a problem using Immutable.js with redux-simple-router is if you're trying to make the router's state into an Immutable.js data structure, but there is no reason to do that. redux-simple-router manages it's own part of the state, and you don't need to directly mutate it. You only read it or dispatch an action to update it.
You don't need to make the entirety of your state tree an Immutable.js structure, just the parts which are managed by the reducers you write.
Huh? Immutable.js is written in Typescript, and it's advocated by Redux, so I figured it's a natural fit in the React ecosystem. At least ideologically.
IMO the standout difference between Angular and React is how you think about your application. Do you like functional programming paradigms and want to apply them in writing your components? Use React. Do you think immutability is too restrictive and love things like two-way binding? Use Angular.
That being said, I'm a bit disappointed to see no mention of Aurelia although the author has mentioned other frameworks like Emberjs. I have been writing production code with Aurelia for about a month and this has been so far my best experience with any client side javascript framework. ES6 is very capable and Aurelia did it right by staying out of your way for most of the times by letting you write your components in plain ES6. All the while providing binding capability(with beautiful syntax), a very powerful router and out of the box package management support. I feel with all the commotion in framework space, more people will appreciate the simplicity of Aurelia and that camp will get bigger as time goes by.
Its the Angular 2 router that currently needs a lot more work. Currently things like passing data down to child routes [1], getting current route segments[2], checking active route etc are still not easily possible[3].
imho router is a big part of any large app and getting the details right is essential there.
I prefer angular over react.
1) It is opinionated (wasting time for decisions is bad)
2) It is simpler to organize the code (it is MVC)
3) (click)="onSelect()" is simpler. You dont have to create an object with "bind" function like in react.
4) I dont want web designers mess with my code. So putting html on JS is bad decision.
> 1) It is opinionated (wasting time for decisions is bad)
I've wasted A LOT of time debating controller vs directive; asController syntax; service classes vs static factories vs rich models (resources); best way to deal with nested components etc. The problem is, most of the time I wasted with decisions in React was right in the beginning (deciding on how you control flow, how you build your app)... But with angular, all the pain points came late in the game when you thought you had done a helluva job designing a GREAT app, then you slowly come to realize its a tangled tag soup piece of crap.
> 2) It is simpler to organize the code (it is MVC)
If you call it MVC, then Id case it like this: mVc ... because the view portion of it is enormous! In fact, the very idea that they made the "template" do so many things is a huge reason why it could be considered a very bad flavor of MVC to begin with.
But do you want web designers to mess with your markup? Many of the projects I work on still involve the 'old-fashioned' server-side rendering approach with bits of jQuery for interactive elements. If a non-coder webdesigner were to mess with my markup, everything would break anyways.
I guess what I'm saying is that I've worked on many types of projects in many kinds of environments, and whenever a front-end framework was necessary, the 'webdesigners' were not. I've just never run into the situation where it actually ended up being useful to create logic-less templates...
Honestly I wouldn't hire a web designer that can't code a little Javascript. It's been a while since knowing only HTML as a web designer has been acceptable.
To answer your question though: they're probably about the same level of difficulty, and I don't think it's a great argument for vanilla/React/Angular because a person who doesn't understand code trying to modify stuff that is controlled by code is going to break something regardless of what JS framework you're using.
I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending. The ESX syntax is just a nice way of forming a hierarchy of class instances. The beauty of React is that you could come up with your own syntax for doing that and use it just the same, because React is just Javascript.
> I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending.
Yeah, that's what it really boils down to. Many of the principles we apply are holdovers from when we used HTML and CSS for what it was originally intended: pages with content.
The way I see it, HTML and CSS were not meant for any of these apps. But if we are going to 'abuse' these technologies, we might as well chuck out the rulebook and optimize for what apps need to do.
That said, please don't do this if what you're making is 'pages with content'!
Not at all! I might not have expressed myself clearly...
The point I was trying to make is that JSX is significantly more convenient for coders like me, as the markup is is the trivial part and the logic is usually the complicated part. So a javascript-first approach benefits me tremendously over trying to figure out how to get my logic working around the logic-less templating systems, or over learning a html-like DSL as in the case of Angular or Vue.js.
I've even considered not using JSX at all (a bit like mithril.js). The only reason I still do is that I like the visual separation of code and markup, and that I like seeing what the the end result will look like (more or less).
So if the JSX approach is so much more convenient for coders (not all, but many), and if the types of projects where you use React tend to be too complex to involve non-coders writing html/css anyways (in my experience), why not just use JSX?
That said, I don't really have a horse in this race either, I guess, because I'll adjust my choices based on circumstances. A while back, for example, I used Ractive.js instead of React.js for a project, because Ractive.js uses mustache templates and simpler two-way binding (a bit like Knockout.js). Because of the particular circumstances and the relative lack of complexity of the app, I figured I'd optimize for what cheap(er) front-enders with less coding experience could take over from me, as I wasn't planning to stay on the project long-term.
I quite liked Vue.js, but I really don't like how it takes the Angular approach of putting 'js in your templates' (sort of). Furthermore, while I'm holding off on 'universal apps' for now, I love being able to use React server-side. If a component needs client-side functionality (sliders, navigation etc.), it's trivial for me to create one component that renders a simple server-side version and then initializes the same component client-side with all the logic it needs.
Last I checked (about two weeks ago I think) server-side rendering was not possible yet in Vue.js.
All that said I'm quite likely to use Vue.js instead of jQuery for many of the use-cases where I would use jQuery instead of React. It's quite impressive!
I've used it for three projects so far, and I'm in love. The syntax is so clean, super easy to learn, and quick to get going. Bind to a parent element, add your data vars, methods, and add your data bindings. Done. It's certainly not as heavyweight as Angular, and that's a good thing. I played with the other big frameworks, and they were so complex for even the basics. I get 99.9% of the work done that I need to with it and should be at the top of these framework lists.
tl;dr: The author is asserting that React > Angular2 because he's already emotionally invested in the former.
React's greatest strength is also its greatest weakness. It requires devs to compose their app out of multiple de-centralized parts. See 'javascript fatigue'.
If your aim is to write an isomorphic React app, you CAN"T just use 'plain old javascript' or anything that touches the DOM. If you care about SEO, this is a very important implementation detail to consider.
Angular2's greatest strength is also its greatest weakness. It provides a unified API for building apps. It forces you to do things the 'angular way' which is no different from Angular1.
So far Angular2 is heavily biased toward Typescript because it was written in TS and it was literally just released to beta 2 weeks ago. TS is good for devs bridging over from strongly-typed OOP languages, and TS provides better support for autocomplete in IDEs. TS is bad because it's not an 'official' standard and it may be an awkward transition for existing JS devs.
TS is not required, I have been writing an Angular2 app in strictly ES6 despite the lack of documentation/support.
Both: require transpilation; use observables (ie redux vs rxjs); use a HTML-like templating language for data binding; use the virtual DOM to speed up rendering; discourage mutating the DOM directly to encourage rendering on other platforms (ie mobile, isomorphic); require platform-specific shims that don't touch the DOM; etc...
The underlying technologies of both are more similar than different. React favors a more decentralized architecture. Angular2 favors a more monolithic architecture.
As a new web developer, where do you draw the line between a web application rendered server side and a SPA? I'm trying to develop a web app for creating invoices for a niche market but in this case I don't see huge advantages for a SPA over rendering HTML server side, the added complexity of a SPA doesn't have that big of a reward, I still plan to separate the frontend and backend, for example, writing a HTTP API that outputs json and in another process(or server) consume the json and render HTML in the frontend server (and maybe add some JS to improve interactivity). But everything this days seems about creating SPAs for new apps and that's definitely the future it seems, I'm wrong following this route or is that I'm just consuming to much SPA hype?
Perhaps in the future there will be a time where an 'old-fashioned' server-side app is a bad idea, but right now I think it's still a perfectly valid approach, and even preferable in some cases.
Consider whether your app will actually benefit from being an SPA. Does it negatively impact the user experience to have page refreshes? Or does it provide significant benefits to do things client side? If the answer is 'no', you might as well take what is currently still easier and more standardized, and go for server-side.
But the next step is to ask these questions about parts of your app. In those cases using React or Vue or something similar for just those parts might be a good idea. And if you've already separated front- and back-end, it shouldn't be too difficult to realize (and it's a good reason to use React server-side even if that's all you use it for initially!).
I've found that it makes sense to outline what actions it is convenient to view on screen at any given time, and group those things into an app (here, one JS file that is served along with some HTML by the server).
So my typical applications have a handful of traditional routes serving HTML and a few small single page apps. To the extent that functionality is shared, I'll create a Clojurescript or Javascript library and reuse it. It keeps JS files small and quick to serve. I've found it to be a good balance between server-side rendering and having a massive SPA.
> You spend your time writing plain ‘ol JavaScript. That’s the future I believe in.
How about a future where you don't write any code at all? This is the beauty of Angular's markup-centric approach, it's declarative so that means less code, which means less opportunities for devs who enjoy typing to screw things up.
Jeremy Keith made a good point in his An Event Apart talk [1], where he talks about HTML slowly subsuming interactive elements (e.g. like how HTML5 adds better form type support). Angular is pushing things into this realm by helping to take code out of the picture more and more.
If you're writing loops, and especially if you write loops that have conditionals inside of them, you're writing code. "Declarative" is saying "I want a list of all users", "For every user, display their name like this" is just code.
I've seen a lot of template languages that claim to be declarative, I'm yet to see a production template (that is to say, not an "example") that actually looks declarative and isn't just writing code in a language with poor constructs for writing code.
Agreed. In every single project I've worked on that used mustache/handlebars, haml, or some similar 'restricted logic' approach, the long-term result consisted of view templates that contained hacks, a lot of logic hidden in helpers that were often only used in one place, or just plain convoluted solutions.
Furthermore, the main argument I hear is that these logic-less template approaches benefit designers/front-enders, which doesn't make sense to me. If your project is complex enough to require Angular or React, a non-coder front-ender probably will have trouble working on it anyways. That's been my experience at least.
I've seen no evidence that Angular results in less code than React. My experience with Angualar 1 was the opposite. Angular templates are still code... weird, fiddly, silently-failing code, at least for Angular 1.
Markup languages are designed to be computer-readable descriptions of documents. Programming languages are designed to be computer-readable descriptions of general instructions. Modern web applications (the sort of web site for which you would consider heavily using React, Angular, Web Components, etc.) are not really documents. It's really nice having a general purpose programming language to describe the instructions for such web applications.
It seems like Redux + React is clearly going to win out. What am I missing?
Yes the ecosystem is constantly changing right now but the oscillations are getting smaller not bigger. In my opinion Redux is the highest level and most intuitive, just like React was for the view when it came out. It's only a matter of time.
His argument about the 'Unix Philosophy' reminds me a lot of the argument between using big web frameworks like Django vs smaller micro-frameworks like Flask. Personally, I prefer Flask for the small projects I make because of how nimble it is but it's hard to argue with the large organizations using Django for massive projects to (seemingly) good effect. Ironic since I actually do like Angular (sorry)!
Overall I felt the article was preachy and extremely biased. It's as if the author was trying really hard to convince as opposed to just presenting the facts and letting the reader make a choice based on the evidence.
I have concerns about ng2 but having made an effort to learn React as well I think he dramatically oversimplifies it's ease of use for large scale projects (where Angular shines, IMHO).
Have you tried either? What is your concern with mixing the two? JSX is optional, by the way. I have a problem with JS into HTML because that's pseudo-coding. JSX tags are representations of classes and class instances, which makes a lot more sense than a totally new DSL for scripting.
> React is a library. It’s precisely the opposite philosophy of large, comprehensive frameworks like Angular and Ember. So when you select React, you’re free to choose modern best-of-breed libraries that solve your problem best. JavaScript moves fast, and React allows you to swap out small pieces of your application for better libraries instead of waiting around and hoping your framework will innovate.
Just an aside, but who would've thought that Facebook would be the one to develop around the Unix philosophy? Yes, I know that Google is a monolith, but it became a monolith over one very specific feature and mission, whereas Facebook had to accompany many kinds of user-interaction and behavior right from conception. When Zuckerberg guest lectured CS50 (more than 10 years ago), he didn't foresee FB doing open-source:
Excerpt: "There's a lot of work that goes into making stuff open source. And it's on top of whether or not you want to lose the competitive advantage...there's a lot of support and licensing and all that stuff. We found that it's been annoying"
Yes, I know FB of 10 years ago is nothing like it is today, with much different people and components...didn't React arise partly/mostly from Instagram? Either way, I was encouraged to use it early on because it was purportedly being used in Instagram production. Angular 1.x wasn't in any of the big sites (other than DoubleClick?). It's nice to see it in more of Google's sites now...but honestly, how it has currently been used has left a bad taste in my mouth. I'm thinking of the Cloud/Compute Dev console. I spun up a machine, thought I shut it off, found out I was $30 in the hole at the end of the month. No big deal, I've done that with EC2 too...but the difference is that AWS's interface, ugly as it may have been, was very easy to use to shut down a machine (right-click, Terminate). I'm ashamed to say it took me about 10 minutes to do it in the Google console. Part of it is unfamiliarity, sure...but nothing interacted the way that I, as a developer, expected it to. I finally found the button or whatever that brought up the panel to show the Terminate option -- it was on the very bottom of my widescreen monitor window...which is a huge visual gap from where the instance-icon is. Maybe it's different when you have several instances spun up and your eye is naturally drawn to the bottom...
Anyway, I know overly-enthusiastic-responsive design is not something that can be blamed inherently on a framework. But it doesn't inspire enthusiasm when it is poorly dogfooded on a developer-facing UI. I mean, it's beautiful, but in all the wrong ways, with boxes of live-updated charts showing performance/activity metrics, but in no discernable hierarchy, as if someone wrapped the page container with jquery.isotope. It's something I would show my boss to make it look like I was doing something impressive but it was not great for productivity.
In contrast...the way that React was justified in its announcement had immediate appeal. The number of UI/UX things that FB and Instagram have to constantly update because of their dataflow required React's kind of overhaul, and it was easier to trust that they would not only maintain React, but design and add features only as necessary.
> I'm ashamed to say it took me about 10 minutes to do it in the Google console. Part of it is unfamiliarity, sure...but nothing interacted the way that I, as a developer, expected it to.
You can make sloppy interfaces with any library or framework. Angular is no exception. Neither is React.
Oh my Christ, not this again. The framework fatigue is real. Why are people trying to push Angular 2 or React even? The former is still under heavy development and the latter is such a painful pill to swallow.
Sorry, no. My 2016 isn't going to come down to me deciding between React's perverted DSL and crazy toolchain or Angular2's massive cluster$&!% of a bundle with cringe-inducing template syntax. No thanks.
I have followed this long enough. To a lot of people, adding Flux, Webpack, TypeScript, whatever, might seem like the beginning of the future of front-end development, but I see something different. I see 2016 as the year that people slowly begin to realize that while components ARE the future, you don't need big frameworks or libraries or 4000 node modules. This is the year of pure, well-written, and fast web apps. This is the year of framework fatigue.