4 ms·

There are many ways to check if a object has changed in JavaScript, Angular's version of it is probably however the worst approach. The fact that it loops its a

There are many ways to check if a object has changed in JavaScript, Angular's version of it is probably however the worst approach. The fact that it loops its a fundamental flaw that can't be taken seriously. Its a hack and should have never passed code review. Diff the virtual DOM to determine the minimal amount of imperative real DOM operations needed. Why is this so hard to understand as the optimal solution? Heck, you can even re-render the entire DOM on every requestanimationframe. This is still better than AngularJS approach! Google Bloop for an example which is very easy to follow and can either support occlusion. AngularJS is pure hype and ignorance.

cportela 12y ago
Clearly you like react, but react also doesn't do as much for you as Angular. It's "only the V in MVC."
- kaonashi 12y ago
  Assuming MVC is the right choice for SPA development.
- ttty 12y ago
  Even flux is a lot easier/faster than angular, of course doesn't came with everything angular comes, but is a nice step.
- chenglou 12y ago
  By this reasoning, functional programming is only the "method" in OOP. Surely that means OOP is a necessarily fuller abstraction? React gives you a powerful V that expresses things so intuitively that for most cases it eschews the help of a C or an M. That's a good thing when it's achievable.
  - sanderjd 12y ago
    It doesn't seem true to me that the "V" React gives you is so good that you don't need anything else. It does seem common (though not universal) to eschew MVC for React apps, but in most cases it is replaced with something like the Flux architecture, which is no more or less complexity than MVC, it's just different.
    - chenglou 12y ago
      Even inside Facebook Flux isn't used everywhere; Yes, for heavier modelling, sure. But for most common cases you're very fine with using only js objects.
      - sanderjd 12y ago
        Just saw this - thanks for the info, very interesting!
Skywing 12y ago
I'm not very familiar with React or Angular's history, but wasn't the idea of diffing a virtual DOM something that React kind of came up with, after Angular had been around? Isn't your comment kind of unfair, because you have the advantage of hindsight?
- Silhouette 12y ago
  Perhaps I can fill in some of the history. To the best of my knowledge, React is indeed the first "mainstream" UI framework for JavaScript to be so fundamentally built around a virtual DOM. I think as a minimum the React team deserve credit for popularising the idea and for raising awareness of the underlying performance characteristics of browsers that make the idea relevant in practice. That said, many of the "big ideas" that have been popularised among front-end web developers in recent years by big name frameworks are not even remotely new to the programming world as a whole. For example, it's hardly news to anyone who's worked on browser-based UIs that DOM updates are often the bottleneck. However, back in the days of IE6/7 and the early versions of Mozilla or even Firefox and Chrome, JS generally and DOM updates in particular were far slower than they are in modern browsers. People have been writing UI code specifically to minimise DOM updates since long before the likes of Angular and React came along, because what is done today as a performance boost for relatively large and complicated pages used to be a necessity to get acceptable performance out of any JS-based UI at all (the major alternatives being either plugins like Flash or Java, which ran routine UI code much faster in those days, or doing pretty much all of the work server-side using old school web forms). It's also hardly news to anyone who worked with client-server apps a few years ago, when again things were much slower and more specifically bandwidth was a fraction of what we enjoy today, that sending patches instead of complete data can be an easy performance win. (People have been using the rsync technique for a couple of decades or so.) In the early days of what we might now call web apps, before JSON won and everyone had numerous JSON-friendly persistence and data binding libraries to choose from, a comedian developed a format called XML that accidentally caught on when too many people didn't realise it was a joke. (See also: XMLHttpRequest, the standard tool for retrieving JSON data from servers everywhere.) In order to avoid half the development team retiring before the first test XML data had finished downloading on a typical project, we got pretty good at designing diff/patch formats for these kinds of nested data structures. Put those two ideas together, and as you can imagine, a lot of web developers wrote a lot of ad-hoc tools whose basic purpose was to take some sort of change set for the underlying data model as input and figure out some sort of reasonably small set of DOM updates to match. The canonical example would be something like updating a container in your underlying data model, where you couldn't afford to rewrite a whole list or table element in your DOM for each inserted/changed/deleted element in the container, so you had to bundle up the changes transaction-style and then flag the DOM for a single update at the end. Obviously we've learned a lot since the early versions of this, and today we enjoy templating and data binding libraries that can be dropped into projects with negligible effort but do the same jobs we used to spend many days automating on each new project, with all the usual benefits of consolidation and peer review that come from having generic libraries with many users and many contributors. No doubt some of the techniques used in modern frameworks like React are far more widely applicable and systematic than a lot of the old code we used to use. So in this sense, again, perhaps the React team deserve some credit for advancing the state of the art.

cportela 12y ago

Clearly you like react, but react also doesn't do as much for you as Angular. It's "only the V in MVC."

kaonashi 12y ago
Assuming MVC is the right choice for SPA development.
ttty 12y ago
Even flux is a lot easier/faster than angular, of course doesn't came with everything angular comes, but is a nice step.
chenglou 12y ago
By this reasoning, functional programming is only the "method" in OOP. Surely that means OOP is a necessarily fuller abstraction? React gives you a powerful V that expresses things so intuitively that for most cases it eschews the help of a C or an M. That's a good thing when it's achievable.
- sanderjd 12y ago
  It doesn't seem true to me that the "V" React gives you is so good that you don't need anything else. It does seem common (though not universal) to eschew MVC for React apps, but in most cases it is replaced with something like the Flux architecture, which is no more or less complexity than MVC, it's just different.
  - chenglou 12y ago
    Even inside Facebook Flux isn't used everywhere; Yes, for heavier modelling, sure. But for most common cases you're very fine with using only js objects.
    - sanderjd 12y ago
      Just saw this - thanks for the info, very interesting!

Skywing 12y ago

I'm not very familiar with React or Angular's history, but wasn't the idea of diffing a virtual DOM something that React kind of came up with, after Angular had been around? Isn't your comment kind of unfair, because you have the advantage of hindsight?

Silhouette 12y ago
Perhaps I can fill in some of the history. To the best of my knowledge, React is indeed the first "mainstream" UI framework for JavaScript to be so fundamentally built around a virtual DOM. I think as a minimum the React team deserve credit for popularising the idea and for raising awareness of the underlying performance characteristics of browsers that make the idea relevant in practice. That said, many of the "big ideas" that have been popularised among front-end web developers in recent years by big name frameworks are not even remotely new to the programming world as a whole. For example, it's hardly news to anyone who's worked on browser-based UIs that DOM updates are often the bottleneck. However, back in the days of IE6/7 and the early versions of Mozilla or even Firefox and Chrome, JS generally and DOM updates in particular were far slower than they are in modern browsers. People have been writing UI code specifically to minimise DOM updates since long before the likes of Angular and React came along, because what is done today as a performance boost for relatively large and complicated pages used to be a necessity to get acceptable performance out of any JS-based UI at all (the major alternatives being either plugins like Flash or Java, which ran routine UI code much faster in those days, or doing pretty much all of the work server-side using old school web forms). It's also hardly news to anyone who worked with client-server apps a few years ago, when again things were much slower and more specifically bandwidth was a fraction of what we enjoy today, that sending patches instead of complete data can be an easy performance win. (People have been using the rsync technique for a couple of decades or so.) In the early days of what we might now call web apps, before JSON won and everyone had numerous JSON-friendly persistence and data binding libraries to choose from, a comedian developed a format called XML that accidentally caught on when too many people didn't realise it was a joke. (See also: XMLHttpRequest, the standard tool for retrieving JSON data from servers everywhere.) In order to avoid half the development team retiring before the first test XML data had finished downloading on a typical project, we got pretty good at designing diff/patch formats for these kinds of nested data structures. Put those two ideas together, and as you can imagine, a lot of web developers wrote a lot of ad-hoc tools whose basic purpose was to take some sort of change set for the underlying data model as input and figure out some sort of reasonably small set of DOM updates to match. The canonical example would be something like updating a container in your underlying data model, where you couldn't afford to rewrite a whole list or table element in your DOM for each inserted/changed/deleted element in the container, so you had to bundle up the changes transaction-style and then flag the DOM for a single update at the end. Obviously we've learned a lot since the early versions of this, and today we enjoy templating and data binding libraries that can be dropped into projects with negligible effort but do the same jobs we used to spend many days automating on each new project, with all the usual benefits of consolidation and peer review that come from having generic libraries with many users and many contributors. No doubt some of the techniques used in modern frameworks like React are far more widely applicable and systematic than a lot of the old code we used to use. So in this sense, again, perhaps the React team deserve some credit for advancing the state of the art.