Hacker News Reader

Comment by hoodoof | Hacker News Reader

I really don't give a shit what anyone says, for me personally ReactJS makes front end great fun to program and an absolute blast and empowers me like never before to build powerful, interactive front end apps with a code base that is well structured, understandable and makes sense.

Until React I dreaded front end development, painful, weird, quirky, hard to organise and generally problemtic. With React I feel like a front end guru.

AngularJS felt like some sort of weird computer science project developed by Phd's who had spent their university days studying Java - it hurt to learn it.

Call me a hipster fanboy if you want but I choose technology to work with because it is easy and make sense. I don't have much time so I have to commit my limited resource to the optimum set of technologies. At the front end that is React.

View on HN

Angular was a bad idea. In sooo many ways...

-Two-way binding in all cases is slow

-Directives are unecessarily hard to write

-Angular's default DI model breaks on alpha conversion, the basis of every JS minifier ever. All the fixes are cumbersome.

-The system is poorly documented, making it hard for a dev to get started.

-The system is overly complex, slow, and hard to debug ($digest already in progress, anyone?).

-But most importantly, it implements stuff that has no buisiness being in an SPA web framework. It re-implements scoping, modules, part of JQuery, DI, and a programming language, complete with parser.

React, however, did the responsible thing, and stuck to a specific domain. Even if nothing else React did was good (and I have some arguments there), this is a major win over Angular.

Two way data bind is fast because a graph of binds and dependency is created. So you can have atomic updates while in virtual dom you must rerun all the tree. See vue.js and ractive But is also true that 2way double binding take more memory that virtual dom.

Two-way binding CAN be fast, however, due to various issues, Angular's only option was Dirty Checking, which is sloooow.

And no, a depgraph doesn't make it fast. What can make it fast is firing less events, using better triggers, and basically handling it exactly the way that Angular didn't.

VDOM can help, but really not much. However you want to put it, two-way binding is costly, and it should be avoided whenever possible, or minimized by catching multiple bind events at a higher up element on the tree (see http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi...)

Just spraying it everywhere, the way Angular encourages, with no optimization (like the aforementioned asymetrical bindings), should be considered an antipattern.

Data binding is also about computates function where you know the dependencies of this and know when recalculate it

Are you talking about Computed Values? Because Data Binding has nothing to do with that. Not really.

In any case, Computed values make 2 way binding more expensive, because you have to run a depgraph on all the vars that are part of the binding network, every time an event fires. This is O(n). This is only one reason why Computed Values, as implemented in JS, are a Bad Idea. If you have to update a var on event fire, okay, but leaving the things everywhere is slow and ungainly. If you instead change the var to a function call, you can optimize far better, because you only have to update when the value is read.

In conclusion, if you want to polymorphism between functions and variables, treat everything as a function, not as a variable.

At least, I think that's a response to your question. Your English is pretty broken, so it's hard to tell. Sorry.

Angular 2way is based on dirty check. Ractive and vue.js are really data binding with atomic changes.

I said nothing about Ractive and Vue. Their 2 way binding is better, but with large quantities of bindings, it's still slow.

Virtual dom consume more computation processor while data binding consume more memory.

...In theory, but IIRC, binding doesn't cover all the types of updates that vdom does, and vdom is better at avoiding thrashing.

Not sure what you mean "rerun all the tree", if you change a a state variable that is added as a prop in another component it has to rerun refresh on those components, but only those components, so not all the tree. Also not sure how this relates to atomic updates, with a flux pattern each state change is associated with ui changes propogating down, the difference to angular is, they aren't supposed to be allowed to propogate up, which you can do in angular since there isn't necessarily a central state store and since there is two way binding children or parent can change the variable.

It's easy enough to write two way binding into a react state variable, it's just nice to not have it happen by default since having state able to change anywhere in the app can get confusing.

A virtual dom is stupid about the view is only an algorithm that diff 2 trees. A data binding can create a graph of knowledge about the view and can create the best and fast mode for update the view. Library like ractive and vue are the best tools for create animations in svg or where there are many updates of view

...Which is why Mithril and React provide escape valves, for situations in which the VDOM abstraction is ill suited.

Yes but generally speak you must do all this things manually and also optimizatio s and binding you must know what updates. In a real 2way db this is automatic also for performance.

No, the perf's pretty bad if you do a lot of binding, and the manual binding gives you a better sense of what your app is doing, the performance tradeoffs you're making, and more control over an area where you'll probably have to optimize.

Vue.js 2 is an hibrid between virtual dom and data binding.

All VDOM systems are. The difference is how explicit the data binding is: I maintain implicit 2-way binds, Angluar style, are a Bad Idea.

Mmm no sorry i don't agree. For me virtual dom is only a tree generated from code,diffed and batched. Speaking only of the algoritm. For me databining templates libraries are vue and ractive. See this 2 links for comparison. https://vuejs.org/guide/comparison.html

http://blog.ractivejs.org/posts/whats-the-difference-between...

That's true, but what I meant was that all VDOM based systems have binding to some degree, and where optimization is required, explicit is better than implicit.

100% agree.

With Angular, you're basically having to learn an entirely new MVC framework, complete with a mess of its own methods and definitions, which is built on an already existing MVC framework (a web browser).

When I took some time maybe four years ago or so to study Angular, I came to the conclusion that it's just the wrong way to go about web development. I started thinking hell, I'm just gonna write my own library which strictly handles the view portion. Low and behold, I find React, and it's everything I was hoping for.

If anyone is thinking about trying out Angular, save yourself time and headaches and use React or Vue.js

I don't see if it makes much sense to compare Angular with React.

Heck, it's like a Pythonista would go comparing Django and Jinja. One's a framework, another's a template library. Same goes for Angular and React - Angular's a framework that tries to be do-it-all solution (UI rendering, validation, data model description, data persistence and communications with server, and more), React's an long-distant ancestor of templating libraries that essentially does only one thing - takes a data structure, a component definition and renders (and maintains) a DOM tree.

Seems that many are calling non-React pieces that are frequently used with React (e.g. Redux, Flux, Immutable.js, Restful.js) to be "React" as well, while they don't seem have any ties to it.

But, yea, loose coupling's great. And React is a very nice library.

Well, I have to say, I had the feeling already when using ExtJS4 and Emberjs.

Even more than with React, because they both felt much more full featured.

But yes they were harder to grasp than React and I prefer the tiny API of React over that convult that ExtJS is. And yes, I prefer JS-as-templates over that whole HTMLBars stuff Ember throws at their devs.

Reply on news.ycombinator.com