Introducing The Kno.. a revolutionizing digital textbook - <AUTHOR> http://www.kno.com/the-kno.html

<comment><USER2> My interest is piqued:

 _As proof of our commitment: from the start we treated our own internal app developers as third party developers. A developer-friendly environment is in our blood. We're powered by the WebKit browser engine, so if you can build a website, you can build a Kno app._

Also, don't miss the photos on the home page. This thing is enormous.

Engadget has a hands on: [http://www.engadget.com/2010/06/02/kno-dual-screen- tablet-ap...](http://www.engadget.com/2010/06/02/kno-dual-screen-tablet- appears-at-d8-we-go-hands-on/) (edit)

<comment><USER3> Judging by the pictures linked above, I think they went too big with it. It's more of a coffee table book than a textbook.

<comment><USER4> Are you trying to learn or surf youtube on the couch?

If they are trying to go application specific for learning I'd rather have a big ass device that kicks ass with textbooks, than suffer a 9" screen.

If you compare it to the text book load of a student now it's a huge improvement.

Also since one of the screens is for note taking, you are also remove that additional stuff as well.

While a device that large seems counter-intuitive, it's made for purpose not general computing.

<comment><USER3> This device would be amazing for consuming media on the couch. I'm questioning its usability in a typical students day.

Reducing it to 9 inches is taking it to the extreme, even 11 or 12 inch displays would still be perfectly adequate and cut down on it's size and weight.

</comment></comment></comment></comment><comment><USER5> The Kno... revolutionizing digital textbooks with a 5.5 pound, original xbox size, dual screen tablet device that starts just under $1,000.

Shoot me in the face.

<comment><USER6> if i were currently an undergrad, i wouldn't want to pull that thing out in a lecture. i don't know if i could even fit it, given some of the tight seating in the lecture halls i went to. everyone uses a laptop or notepad for note taking and that's about as much space as they can afford. i definitely think they should come out with a smaller form factor.

the other issue is pricing. this device has to significantly beat the price of used textbooks.

<comment><USER7> It can do things that paper textbooks don't; it isn't competing just on price.

For instance, how about you mark stuff as important which not only lets you flip through just those bits later but it also puts that chunk of information in your automated "review-stuff" queue. Give that queue a "which things to pop-up when" scheduler based on measurements of your retrieval success rate fall-off over time and some memory science, i.e. it can be a textbook that reinforces the important bits just before your brain was about to forget them. You could even reward a regimen of shoving information through the student's attention... "rewrite these notes for extra points."

The size, sure it can be streamlined some, but this isn't for mostly passive content consumption and casual gaming so it should never be iPad sized.

<comment><USER8> Um, why shouldn't it be iPad sized? I've spent two years looking at memory algorithms, and a similar amount of time implementing and dogfooding learning systems... call it my hobby.

Cro-Mag Rally is _way_ more computationally intensive than anything I've worked with or seen. Perhaps more importantly, the more intricate scheduling systems don't perform any better than the simpler systems.

The real key to making any sort of repetitive study system work isn't really in the scheduling algorithm -- it's in making the system easy to use and always available.

If it's a lot of work to get information into or out of a spaced repetition system, then you won't use it. If you can't study whenever you've got a spare five minutes, then you won't use it. If you can't hit it from your desktop, iPad, Motorola Droid, iPhone, laptop, and computer in the library, then you won't use it. Because it's inconvenient.

So please, bring on the iPad learning systems. It's portable, lightweight, and can speak WiFi and 3G. Anything that makes studying more convenient is good.

<comment><USER7> Very good point on the need for a repetitive study system to be always available.

The bit about iPad being too small comes from asking something like "why aren't textbooks the size of fictional paperbacks?" I suppose it could be just historical accident or the need for enough page mass that the book lays flat and open. But seems to me that the answer also includes something along the lines of different types of information being better shown at different sizes, with richer learning material needing more room. When the target users already carry a bag all the time, should portability of a textbook replacement be so overriding a concern that the area for showing and writing information is slashed by something like half (iPad screen to college notebook ratio) up front? Shouldn't form follow function a little more than that?

The really old college textbooks (1950's and earlier) I have are actually smaller than modern versions, with text areas comparable or smaller than an iPad screen. So perhaps the question can be reformulated as "why did textbooks get bigger over the past century?" Or maybe there is just a lot less reasoning behind their sizes than I'm presupposing.

<comment><USER8> My guess has more to do with sales and marketing than anything else. I've got more than a few textbooks from the 50's and 60's on a variety of subjects, and for the most part, they are a _joy_ to read, because they assume the reader is intelligent enough to not try and eat the chalkboard erasers.

Big textbooks, with lots of diagrams, pictures, and colors, look impressive. They give the impression of a tome filled with knowledge and wisdom, whether or not they actually are. Which is why school districts and professors in charge of lower-division courses buy the damn things -- they get impressive- looking textbooks to wow the students and parents, and they don't have to think much about the choice.

It's just good marketing.

</comment></comment></comment></comment></comment></comment><comment><USER9> Tablets are going to expose all sorts of new ways of interacting with hypertext on the client side. Supporting html5 is nice for authors, but the real revolution comes when readers can compare multiple hypertext documents, naturally browse through interlinked documents, make annotations, etc. These things have been tried and failed on other form factors, but I think they might succeed on a device like this, Courier or the iPad where the new form- factor requires new interaction models anyway.

This device doesn't look perfect, but they're exploring the most interesting aspect of the tablet problem.

<comment><USER10> Check out Popplet. I think something like this could be used as a framework to enable most of the functionality shown in Microsoft's Courier vaporware video. (But in a multi-touch friendly way)

<http://popplet.com/>

If other applications could be integrated, such that arbitrary docs could appear in a Popplet-window, then this gives us a task/document-centric way for users to integrate and organize all of their data. (Such that applications disappear into the background, and it's their data that matters.)

<comment><USER7> Very neat, thanks for sharing that. If data from other application could be integrated like that, would that get it kicked off the iPad under the new "no new 'desktop' environments" rule?

</comment></comment></comment><comment><USER11> Make you own Kno. You will need:

\- 2 x Apple iPad

\- 1 x Hinge

<comment><USER6> not entirely true, although i think you are being a little facetious. this device seems a lot more open in general (use of flash for example).

<comment><USER12> It's a textbook. Flash doesn't matter. The content needs to be there. I've read textbooks on my iPad before; for the most part, it works OK. There doesn't appear to be any big advantage to the Kno that couldn't be matched in a specialized iPad app.

</comment></comment></comment><comment><USER13> Reminds me of this competition for brand names worse than Knol:

[http://voltagecreative.com/blog/2008/08/50-for-worse- brand-n...](http://voltagecreative.com/blog/2008/08/50-for-worse-brand-name- than-knol-we-have-a-winner/)

<comment><USER14> This was originally branded the Kakai.

[http://social.venturebeat.com/2010/01/20/chegg-founders- stea...](http://social.venturebeat.com/2010/01/20/chegg-founders-stealthy- kakai-building-a-gesture-based-consumer-device/)

www.kakai.com now redirects to www.kno.com

It is a project by the Founder of Chegg.com a service that specializes in textbook rentals.

I'm not really enticed by any of their branding.

</comment></comment><comment><USER15> Yes! I've been waiting for an ebook reader that I can use to take hand-written notes with.

I really can't concentrate on a book unless I have a pencil in hand, underlining, circling, and taking notes. Stylus instead of pencil, here.

</comment><comment><USER16> Having just researched Personal Learning Environments (PLE's) [1] - this is a timely reminder of just how bad standard teaching portal type application are for the goal of teaching and learning. Hopefully this will spawn a few imitators which will drive the costs down so that it isn't just useful in the US.

[1][http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.2772&rep=rep1&type=pdf)

</comment><comment><USER17> Drop the hardware, write an iPad app. They do some very cool things with the software that neither the kindle nor Apples book reader app satisfies. But when it comes down to how to spend the money, $1000 on one Kno or two iPads, there isn't enough of a value add on for the Kno. In fact, the iPad has more features and a better form factor.

Kno is about a year late for their hardware, but their software could work as an iPad app.

</comment><comment><USER18> So basically, it's a tablet, but it's as unpractical to use as a laptop. (If you can use it comfortably somewhere, you can probably use a laptop instead.)

</comment><comment><USER19> I would want one of these if there were enough textbooks and the price was reasonable.

</comment><comment><USER20> An approximate equivalent would be a tablet/laptop and a paper notebook and pen.

</comment><comment><USER21> It looks cool but it's massive and with two screens that size and the batteries that would be required to support them, I can imagine that it is _very_ heavy.

Which is definitely one of the biggest problems with paper textbooks, something we should try and get away from with etextbooks.

<comment><USER22> It'd probably weigh about the same amount as a first year Calc textbook. This is actually one area where the standard for improvement isn't very high. Textbooks weigh A LOT, and I think it's getting to the point where people's posture and backs are being negatively affected. Let alone the day you need to move...

Compared to something like an iPad, this Kno is going to be a hell of a lot heavier, so it's just a matter of what the students are comparing against.

This is all moot though as the major pain point with textbooks are their obscene pricing. If this is just the same old overpriced textbooks, just in digital form, it's interesting but hardly a game changer.

<comment><USER23> The sticking point with text books IS the printing. My wife (PhD and professor) would love to move to digital text books. In the digital realm there are actually entire text books that aren't widely available in print. They are also MUCH cheaper for the students.

<http://www.flatworldknowledge.com/> is one example. There are others I can't remember right now.

This device seems to knock down a LOT of barriers. The two screens allow for the space needed to show all of the content a professor might Believe it or not, THE biggest thing slowing adoption of electronic text books is the ability to take notes want to expose at once. The students can take notes on the pages (this is a huge deal for adoption believe it or not). It enables open and cheaper options...

I like it a lot. I think they have a winner if they've executed well.

</comment></comment></comment><comment><USER24> Looks hackernews-inspired: two iPads and some Sugru to hold them together.</comment>


Viacom slaps Google with $1 billion lawsuit - <AUTHOR> http://www.cnn.com/2007/TECH/biztech/03/13/viacom.youtube.reut/index.html <comment><USER2> This is a great thing, and IMO, exactly why Google bought Youtube.. They paid for this lawsuit.

When you think about it, everything Google does, the Cache, Google Groups, The Image search, and even their golden baby, Search, requires that they deal with the copyrighted material of other people.. It's their bread and butter. They can do it under the law, or at least their lawyers are convinced they can, because of a legal concept known as Common Carrier (Some people in the audience will notice I'm simplifying. I'm trying to encourage discussion, not write a legal essay ;)

The Common Carrier clause, written under the (otherwise) dreaded DMCA, says that carriers, such as Earthlink/aol/etc are just carrying information, and they aren't responsible for it.. It provides rules, which say you need to take things down when you're asked, but you're otherwise not culpable- As long as you take it down when asked, you're OK.

Now, with Youtube, before Google invested anything in it, Google sees a lawsuit coming which could change that.. They KNOW that youtube is likely to be sued, and don't want to have the judge define the laws in a way which screws them over.. They know this lawsuit is coming one way or another, and that Youtube is poor, so their legal defense is likely to..well..suck.

Google realizes that if they buy Youtube, they can use their considerable legal muscle and financial capital to DEFEND youtube, and to make sure that they law isn't redefined in a way that screws them..

Since the US system works by a process of Common Law, the precedent is binding. That means that this case will be VERY influential in dertermining any other cases. And it's THOSE that is worried about.

THAT's why Google bought Youtube. They want this Lawsuit very badly.

Well, As an aside- There's also the line of reasoning that Sequoia Capital was heavily pushing Google for the acqusition.. YouTube was smart/lucky enough to convince Sequoia to invest, which gives Google a good inventive to do the buyout.. That said, I think this was an ancillary factor, not a primary one. Winning this lawsuit is worth a billion to Google by itself.

Ways to prove me wrong? If Google settles, I'm full of shit.

<comment><USER3> I completely agree. Google knew that they needed to be involved in this lawsuit or the future of their business, and perhaps the Internet, could be in jeopardy. If YouTube had to settle or try to fight the lawsuit on their own it is very likely that the outcome wouldn't have been favorable for Google. By buying them and taking the lawsuit on themselves Google is able to use their warchest to fight for the future of the Internet. I'm very excited to see how this plays out.

</comment></comment><comment><USER4> This is like a beaten defender grabbing a forward's shirt as he runs by. Time to sell VIA and buy GOOG.

</comment><comment><USER5> Seems odd to witness a lot of business-type people arguing (or at least leaning) in favor of copyright infringement.

I mean, we could argue for a while about whether some kid should be allowed to download songs off of bittorrent. That's just some kid. But then, you have a huge corporation doing almost the same (okay, okay, with all due equivocations, like: They're only hosting/distributing, not uploading). Well, google isn't distributing video out of a love of the artform. I mean, person X builds/owns something, and person Y profits from it, or at least tries to. See no problem there? It might come down to "might makes right" here, if google has sufficiently expensive lawyers.

The seemingly obvious solution is to tack a 15-second advertisement on the videos and then share the proceeds with the owner.

</comment><comment><USER6> While I'm on the YouTube side of this one, the web does place content creators in something of a dilemma. If content producers can't make revenue from the web, how are they going to afford to make quality content in the first place? While a lot of tech has brought the cost of media creation down, the only profitable web-exclusive stuff right now is content that can be created for free. Some of the zero-cost content is good, but most if it is just kids hurting themselves for a laugh.

What good is it to make money as a content aggregator if no one can afford to create content in the first place? There's a market here, I'm just not sure what it is.

<comment><USER2> It's not nearly that simple though- Google position isn't "copyright doesn't matter", it's that "Look, we'll take it down if you ask. The law says that's OK! Why are we still arguing"?

Take a look up a few posts for my perspective ;)

<comment><USER6> I'm not saying it is that simple. Google is in the right here. They obey the law, they give customers exactly what they want.

The issue is on the supply side: How can content producers adapt to this altered economy? Right now, their answer has been to sue and hold tightly to the old business models. My argument is more nuanced than just protecting copyright -- I believe there is a way to make money producing quality content, but maybe not for the big, hollywood sized producers. I'm more interested in how to empower the people in-between viacom and the lone camcorder.

</comment></comment></comment><comment><USER7> This is just total hogwash -- old media suing new media in the name of copyrighted content to ultimately protect distribution control.

</comment><comment><USER8> Looks like partnership negotiations completely fell through.

</comment><comment><USER3> Begun the copyright war has... Yoda</comment>


C++ or ++C? - <AUTHOR>

The C++ programming language returns a copy of its value (C), then increments itself. Therefore a program written in C++ returns C code. You might as well write C. Any thoughts? <comment><USER2> If I remember correctly, originally that's what it did, a C++ program was compiled to C, then compiled to binary.</comment>


Families Stuck at Home Turn to Board Game Catan, Sending Sales Skyrocketing - <AUTHOR> https://www.npr.org/2020/08/07/897271885/families-stuck-at-home-turn-to-board-game-catan-sending-sales-skyrocketing <comment><AUTHOR> > "Every player is involved throughout the whole game, even when it's other > players' turns, you're not sitting around waiting," says Arneson. "The games > are always quite close. Nobody ever gets eliminated. It is just a remarkable > achievement in game design."

I hope most families go for Catan instead of Risk while sheltered in place. The latter tends to cause fallouts and retaliation that go beyond the game.

[https://en.wikipedia.org/wiki/Risk_(game)](https://en.wikipedia.org/wiki/Risk_\(game\))</comment>


Is ReactJS really fast? - <AUTHOR> http://blog.500tech.com/is-reactjs-fast/ <comment><USER2> React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead.

I wasn't truly interested in React until I read this, which does a better job of spelling out React's real advantages than I ever could: [http://jlongster.com/Removing-User-Interface- Complexity,-or-...](http://jlongster.com/Removing-User-Interface- Complexity,-or-Why-React-is-Awesome)

Here's a choice quote:

 _" Rerendering everything (and only applying it to the DOM when something actually changed) vastly simplifies the architecture of our app. Observables+DOM elements is a leaky abstraction, and as a user I shouldn't need an intimate knowledge of how the UI is kept in sync with my data. This architecture opens up lots of various ways to optimize the rendering, but it's all completely transparent to the user."_

<comment><USER3> > Observables+DOM elements is a leaky abstraction

The DOM itself is also a leaky abstraction. Render cycles are so prohibitively slow that we've started maintaining a parallel DOM and implementing diffing algorithms in JavaScript. As brilliant as that may be, it's also crazy that it's come to that.

This is a problem that should be solved in the browser. HTML5 should add a simple API to transactionally update the DOM and only render after all changes are committed. This would prevent every single framework from having to implement this logic.

<comment><USER4> The DOM _is_ only rendered after your JavaScript is finished running - as long as you don't ask for properties that can only be known By rendering it out.

</comment></comment></comment><comment><USER5> I wouldn't say React isn't fast, but the OP is right, the claim that React is faster than the alternatives is basically just hype (or good marketing).

Going back years to React's inception and public launch, everyone's concern about virtual DOM diffing was that it would be impractically slower than fine- grained dependency tracking. Note that React's own home page expects people may be concerned about performance, and rightly does not respond with sweeping statements promising better-than-Brand-X performance:

> One of the first questions people ask when considering React for a project > is whether their application will be as fast and responsive as an equivalent > non-React version. The idea of re-rendering an entire subtree of components > in response to every state change makes people wonder whether this process > negatively impacts performance. React uses several clever techniques to > minimize the number of costly DOM operations required to update the UI.

The React team and early proponents got out ahead of this concern, pushing the message that React is fast. It's faster than you'd think, they said, and in some cases faster than the alternatives. Their arguments seem to have gotten distorted and simplified by those repeating them.

The original arguments for why React was fast were:

* The DOM is very slow compared to pure JS. To the extent React's diffing is saving you from re-rendering DOM, you are winning. (Compare it to re-rendering a Backbone template, for example.)

* While it's true that other libraries have schemes that track fine-grained data dependencies, allowing them to go straight to the nodes that need re-rendering without doing any tree diffing, these schemes have their own overhead, which could in theory be just as high as React's.

When I pressed a couple React devs on the second point, it was clear they couldn't argue that tracking data dependencies would be worse than diffing _necessarily_ or in general. Rather, they had concluded the two approaches were comparable in practice.

In summary, the DOM is pretty slow, and virtual DOM diffing is pretty fast. It means you don't have to track data changes at a fine-grained level, and you never over-render the DOM. Performance is comparable to other leading frameworks.

</comment><comment><USER6> I don't use React for it's speed, I'm sure I can make anything using vanilla or ember, or whatever just as fast. It's the way it makes you think about things...the developers on my team are now much more productive. They can jump onto something another developer has been working on and see what each component is doing. It's the declarative nature of React and the way it makes developers think about how they compose their components that makes it a great framework. And let's not forget the reason behind a framework...for developer efficiency. There are no frameworks that are the panacea to everything either, which is probably why the framework arguments break out every single day in the JS world...people think the framework they choose is the one true solution, when in fact, there are many ways to build a building.

<comment><USER7> I was swept away by the React hype a bit. I tried to sell my team on React by stating many of the same points and eventually we decided to stick with our current JS framework: ExtJS. And I'm thankful I was overruled a bit.

For our team and the types of applications we're building ExtJS simply makes much more sense. I've used React now for a simple web app and also a Chrome extension. For certain UIs scenarios like Facebook's ad example, the React method of rerendering everything definitely makes things easier. But in most applications, I think such a complex UI is usually rare and ~80% of the UI screens are usually fairly simple. For the majority of UI screens, React or perhaps React+Flux complicates things by adding unnecessary boilerplate even when using third party Flux implementations.

<comment><USER8> We're in the process of migrating from ExtJS to React, and it is, to put it simply, awesome. Ext was great when we started because it gave us all these great out-of-the-box components to just mix and match and shove things together and get things out the door.

But relatively quickly (i.e. as soon as we wanted to make something look like it _wasn 't_ Ext, and you can always easily tell an Ext app) we ran into Ext's inflexibility. A huge percentage of our code now is finagling Ext over an entire file of code to do what would be a line and some css in any other framework.

I have had the exact opposite experience with "boilerplate", as I see Ext needing much more of it than React.

As a caveat; we are building extremely complex enterprise-level software, but even for the basic stuff if you want to do what Ext wants you to do you are golden. If you want anything a pixel different? Good luck.

<comment><USER7> Is your main complaint over theming ExtJS? We're also building enterprisey software that's for the most part not consumer facing. Our clients are much more concerned about functionality. So while we have several custom themes for our products, we haven't drastically altered the base themes.

Regarding boilerplate, I'll give you a simple example. In ExtJS 4, it's one line of code to wire up an event handler in your controller to a view component like a "Save" button. Then in your onSaveButtonClicked event handler in your controller, you typically you write something like:

        myView.setLoading(true) // to mask the view
        myModel.save() // to execute an Ajax req,
            on success,
               myView.setLoading(false)

In React+Flux, clicking the Save button calls an action creator. The action creator first fires an event "loading: true" before it does anything. A store which is bound to that load action then calls a method which dispatches another event. The view which is listening on the store is notified that "something changed" and redraws itself (to show the loading mask/spinner). All this and we haven't even begun loading any data yet. Repeat all steps once the data is loaded or if an error occurs.

I'm not against React at all - just for our purposes ExtJS seems like a better fit. To be fair, I did spent some time building a custom URL router which really simplifies everything. All of our controllers are consistent with start() and stop() methods, they can define data dependencies (i.e. this data needs to be loaded before start is called), etc.

<comment><USER7> @mejari - the reason why I wrote out the React code long-form is because I couldn't figure out how to write it concisely :) Not because I'm biased hehe.

I disagree it's not identical to React+Flux at all. There's more pieces and wiring required for the typical "Save" button example. In react+flux, the views need to listen on stores:

        MyStore.listen(this._onMyStoreChange.bind(this));

The views manually call action creators:

        MyActions.saveData();

Action creators dispatch separate events for beforeRequest, onRequest, onError events:

        this.actions.onBeforeSaveSomething();

        // do the save
        this.dispatch({ type: 'SUCCESS', data: myData });

Stores need to listen for action creator events:

        this.bindAction(actions.onBeforeSaveSomething, this.onBeforeSaveSomething);
        this.bindAction(actions.onSave, this.onSave);
        this.bindAction(actions.onError, this.onError);

In the Flux flavor I'm using (alt), stores automatically dispatch events when their state is changed, but I found managing the store state is annoying because of the loading, error flags[1].

So the store.onSave might look like this:

        this.loading = false;
        this.error = null;
        this.data = data;

Finally, the view updates it's state in response to a store change which automatically calls render.

Then in the view render, you can show your loading/saving mask.

[1] [https://news.ycombinator.com/item?id=9315503](https://news.ycombinator.com/item?id=9315503)

<comment><USER8> I guess it just comes down to comparing two different things. Yes, you have to do more setup with React because React isn't what Ext is. But if you set up your React to the point that Ext is at, with data binding and error handling and event listening that Ext magics away you get code that is very similar. Almost all of your code is doing what Ext magically does, but in a React application of any size these things are handled via components and mixins and such and you don't have to deal with them in the clunky way you're describing.

<comment><USER7> Not to keep harping on this issue because I know we're way off topic, but I'm genuinely curious how the React code can be simplified because this was one of my main pain points using React. Reflux and alt were major improvements over the Facebook flux impl, but they still require the boilerplate I posted above. If you remove that then you have "Flux magic" :)

There's no Ext magic in the code I posted. Flux and MVC are different patterns. In MVC, the controller typically has direct access to the view and model which is why the code is simple:

        myView.setLoading(true);
        myModel.save(...)

That would look the same in Java Swing for example. Flux is a fundamentally different pattern and one that I really haven't seen the need for in the products we're building to justify it's disadvantages. But for some applications, it's probably the right solution.

<comment><USER9> And the reason you couldn't setup your stores in a similar fashion?

        myStore.setLoading(true);
        myStore.save(...);

Where the handling is in your action handler for whatever event was raised... This assumes you do your backend data access in the store itself... there are other options.

<comment><USER7> Sorry for the confusion: setLoading (poorly named) is a method on a view component in ExtJS 4 which displays a modal message mask.

<comment><USER9> No confusion.. you can have a property on your store that does the same to state, and triggers an event to draw a mask/modal in a similar way... there's nothing preventing you from doing that... it isn't so much in the box, but you can do it pretty easily.

You also aren't stuck building class based object constructors in JS as extjs projects tend to do.. or trying to shim out areas of extjs in order to extend a base rendering.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Pet peeve: Can we please stop blindly abusing `track by $index` without understanding it?

The thing with `track by $index` that nobody talks about is that, like many of the workarounds in Angular, it's a footgun in disguise. Consider this: [http://plnkr.co/edit/qKm7fYZFCkXHI5pkPMYL?p=preview](http://plnkr.co/edit/qKm7fYZFCkXHI5pkPMYL?p=preview) and focus on the first input. Notice that the focus stays on the first input, instead of sticking with the value as it jumps around, so if you start typing, you'll acccidentally modify another item as well. Oops.

If you don't use `track by` (or, if you use keys as they recommend you do if this was React/Mithril/some other vdom library), you'll see that the focus stays in the input that corresponds to the value you originally clicked on, which is the correct behavior.

While this may seem like a contrived example, the underlying problem is that it silently messes up state synchronization between your data and the DOM. This can become a nightmare because anything ranging from jquery plugins and directives to mundane things like inputs (as is shown in the plunkr) or links with onmouseup handlers or filters become potential minefields where you are eventually forced to choose between decent performance and correctness (after the hours it took you to finally understand the problem).

<comment><USER11> This is absolutely a contrived example. $index is the equivalent to `var ctrl = angular.controller`, something that serves very well to communicate basic concepts but that you would never use in a real-world application. If you're dealing with server side data, your model should have a real unique key/id, and that is what you track by.

<comment><USER12> The amount of stuff in AngularJS that "serves very well to communicate basic concepts but that you would never use in a real-world application" is a _huge_ problem with the framework. It's a perfect storm of a documentation site and blogosphere full of misleading and/or contradictory advice and examples, combined with conceptual and implementation complexity that makes it incredibly hard to just read the source and deduce best practices from first principles.

This article contains a good example of the phenomenon: it suggests switching from `$timeout` to `setTimeout` with `$digest` to "give both frameworks the same information". Is that a silver bullet solution, or does it come with trade-offs, and if it does, what are they? I'm not sure, but my gut says that I shouldn't change this pattern in my code everywhere without doing a bunch of research to understand exactly what is going on. That's fine, researching how our tools work is a big part of the job, but I feel like Angular has a disproportionate amount of this sort of complexity compared with other tools I've used.

<comment><USER13> > The amount of stuff in AngularJS that "serves very well to communicate basic > concepts but that you would never use in a real-world application" is a huge > problem with the framework.

Come to think of it, this describes a lot of PHP example code out there too.

</comment></comment></comment></comment><comment><USER14> The basic premise seems to be that AngularJS can be just as performant as ReactJS if you do your homework and avoid common pitfalls of AngularJS.

I would argue that the beauty of ReactJS is that it doesn't have any gotchas. It's performant without needing a deep knowledge of the framework.

<comment><USER15> > The basic premise seems to be that AngularJS can be just as performant as > ReactJS if you do your homework and avoid common pitfalls of AngularJS.

While AngularJS(1.x) is a bit faster now, your comment is a bit like saying Ruby can be equally fast to Java if one does it homework.

AngularJS has architectural problems that can only be reduced if one doesn't use much of angular features(scopes,watches) inside directives(which means writing components in pure js). So it takes a huge effort to make angular fast in general. That's the reason why they are creating an entirely new framework with version 2.x (which I believe is a mistake, Angular 1.x despite its flaws was pragmatic, 2.x isn't).

React is faster for a few reasons: there are no templates in react, everything is js code React does all the heavy computation outside the DOM so manipulations are minimal and there is no two-way data binding by default, the data flow is unidirectional.

Obviously the angular team wants the same stuff since it has proven it is a better architecture.

<comment><USER16> Given the above discussion about the great performance differences largely being rectified by using angular's `track-by`, I think we can rule out templates as a major driver of performance grief. Templates are usually compiled into native javascript code once (or at least, can and should be), so I really don't see how there should be grand differences between what React is doing and how template processors work.

This, by the way, is an EXCELLENT example of the kind of arguments that have come out of the React.js camp that give me a lot of pause. There's radical differences made in how frontend applications are developed with React, and the primary selling point that I kept hearing was "embrace it, the performance difference is HUGE!". Then as arguments come out about how the performance differences have caveats, the arguments switch to "...well this is how we should be developing, for X, Y, and Z architectural reasons". I'm not saying that X, Y, and Z aren't valid discussion points, but it's been wrapped up in so much pseudo-technical FUD, and that's pretty unfortunate.

Signed, Recovering Template-Aholic

<comment><USER15> > Templates are usually compiled into native javascript code once

no they aren't.

> (or at least, can and should be)

not by default. React doesn't have templates at all ,so case closed.

<comment><USER17> > no they aren't. says who?

<comment><USER15> says the angular team that wants to copy how react works and ditch old angular 1.x templates. Why do you think they are creating an entire new framework? because the old version was good enough? no. 2.x means the whole 1.x was an architecture mistake.

</comment></comment></comment></comment></comment></comment><comment><USER18> The most important thing about React's update performance is that it's ~O(n) of the size of the virtual dom. If React's performance is a problem you can window the input data, do things more efficiently in your render, tweak shouldComponentUpdate. The goal isn't to be as fast as possible but rather to be fast enough and for non-mobile you can hit that target with only the occasional tweak. For mobile, you can get as exciting as you like[1] but I've never had to go beyond the above steps.

[1] [http://engineering.flipboard.com/2015/02/mobile- web/](http://engineering.flipboard.com/2015/02/mobile-web/)

You can build things that are faster than React in benchmarks. Pretty much every vdom based library/framework/language is faster than React in benchmarks and absolute performance has never been a stated goal of the project. The framework does help you out in ways that don't show up on benchmarks like this. An example would be batching DOM updates, which is much harder when you have components mucking around directly with their internal set of nodes.

I also favor using an immutable data tree with a corresponding shouldComponentUpdate and only rendering on rAF but those force architectural decisions on the project.

</comment><comment><USER19> We need to stop this cargo cult stuff.

"Speed" as determined by rendering stuff to a page is actually something we can determine. Is it not possible to simply trace the framework execution? What's the point of having silly hype pieces back and forth when we're debating trivial examples that ought to be _not too_ difficult to measure?

Finally, wrt to React: it's just a view layer. Comparing it to Ember or Angular as if it were a fully fledged, swappable alternative doesn't really make sense.

<comment><USER20> > Finally, wrt to React: it's just a view layer. Comparing it to Ember or > Angular as if it were a fully fledged, swappable alternative doesn't really > make sense.

This every time. If there's any bloggers among you: as soon as you start doing a 1:1 comparison between Angular and React, stop.

<comment><USER21> I (apparently incorrectly) thought they were similar enough to compare. What are the significant additional features that Ember and Angular provide?

<comment><USER11> Not sure about Ember, but Angular provides

\- a full MV* implementation \- routing \- DI \- decorators \- CSP / XSS protection \- a ton of services for mocking for unit tests ($http, $window, et al)

I'm sure I'm missing a fair amount of stuff here, too. This is just what I get out of Angular 1.x on a daily basis.

</comment></comment></comment></comment><comment><USER22> > Or the strange lack of any demonstrable examples of the performance > improvements achieved by this feature... except the comparison demos.

React is winning because of real-world experience. Blog posts are somewhat meaningless, arguing specific nuances back and forth. Who knows what's actually right. But when you actually sit down and learn React, and use it in a complex app, you understand how easily it lets you fine-tune performance, and instead of getting in the way it helps you along the path to blazingly fast UIs.

Nothing is magical out of the box, the key is to help the user along the way and that's exactly what React excels at. Performance is a definite factor for choosing React.

Software doesn't achieve the level of fame of React (or Ember, or Angular for that matter) solely by hype. It may have a brief period of fame, but several years long of building a passionate community means there probably is something there.

<comment><USER2> > Blog posts are somewhat meaningless, arguing specific nuances back and > forth.

I disagree. Your "Bloop" blog post about React with its game loop analogy totally opened my eyes. That's the first time I really "got it". Moved my org to React for all new development and haven't looked back. So thank you for your "somewhat meaningless" blog post!

<comment><USER23> Going to the GPs blog doesn't seem to list a matching blog post. Got a link for me?

<comment><USER24> [http://jlongster.com/Removing-User-Interface- Complexity,-or-...](http://jlongster.com/Removing-User-Interface- Complexity,-or-Why-React-is-Awesome)

</comment></comment></comment></comment><comment><USER25> There are some situations where Angular 1.x's digest/compile cycle leads to degenerate performance and where clean solutions are all but unavailable.

Building arbitrarily recursive structures in Angular leads to degenerate performance[1]. In this example, I had to introduce artificial timeouts during rendering so that the browser's UI thread is not completely locked out for several seconds.

The crux of the problem is that to make a recursive directive, Angular needs to swap back and forth between `$compile`ing newly-added markup and `$digest`ing the `$scope` that is assigned to the new markup as a part of the linking phase. It is my understanding that this issue is not manifested in React.

1: [http://embed.plnkr.co/1gOJjJ/](http://embed.plnkr.co/1gOJjJ/)

<comment><USER26> Actually, I believe I am facing a similar issue. I have directives that encapsulate other directives, and compiling 1000 of them is slow, but they run pretty well after they are compiled. Any thoughts on speeding up that process?

</comment></comment><comment><USER27> From a ClojureScript viewpoint, the whole "really fast" thing is a red herring anyway. I don't care whether it's faster than Angular at rendering some tables. What I do care about is the model: my views can now be functions of my immutable data structures and I can write components that react to changes.

There are two performance-related issues I care about: React doesn't modify the DOM if it doesn't need to, and my components do not even re-render most of the time, because they don't need to if the data hasn't changed (and thanks to immutable data structures the comparisons are really cheap).

It is this approach that is revolutionary. "Really fast" has nothing to do with it. Sure, I'm glad that I can easily create complex apps that have exactly zero performance issues right from the start, but I'm not going to compete in any benchmarks anyway.

</comment><comment><USER28> I have been using Backbone + moustache/handlebar templates and I am not clear on why use a virtualDOM. My application has several views and in my views, I use events to sync data model changes with the view and the view's render function maintains the DOM element . None of my views have to deal with the whole DOM. Therefore, I am really confused. So with my apologies for asking a dumb question : why maintain the whole virtual DOM? And what am I missing with Backbone + mustache based approach ?

<comment><USER29> Say you want a form with as-you-type validation. You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you.

I find Backbone events extremely hard to work with (error-prone, super hard to test / debug), because there are many operations that emit tons of events. So you either listen+render() on any event (very inconsistent performance if your app has any kind of complexity), or you hand-pick the events you want to react to (event-hell). Using immutable objects along with React's PureRenderMixin means you can just render() on any change, with great performance. It makes your UI purely functional, very easy to reason about, and easy to test.

<comment><USER30> > You can't have a view containing the whole form and just re-render that as > someone types. If you did, you'd lose the user current focus on every > render. This forces you to manipulate parts of the DOM "by hand", something > React abstracts for you.

This is not how most modern view engines work. Somehow the React community has convinced the entire JS world that they invented the idea of "only render what has changed" when that's just not the case.

<comment><USER31> You've got that backwards. Every other framework "only renders what has changed". React re-renders everything.

<comment><USER30> Reread that in the context of the parent's statement. There is a misconception that every other template library blows away parts of the dom on each update and that only React will do something like input.value=newValue, but this is not the case.

<comment><USER32> I sure don't see where that misconception is the fault of "the React community."

In fact, this comment is the first time I've seen that formulated. I'll be honest, I don't read every React-related forum entry on the Internet, so I may have missed someone somewhere spreading such a misconception, but there certainly is no such centrally communicated premise.

</comment></comment></comment></comment></comment></comment><comment><USER33> The authors "prove me wrong" attitude is awesome, and I hope we see some deeper diving into virtual DOM performance in a follow-up article.

</comment><comment><USER34> It seems to me they're missing the point. The implementation of ng-repeat is quite complex, and if, for some reason, it doesn't do what you want and you decide to write your own directive you have to deal with mutating the DOM in an efficient manner yourself. React on the other hand allows you to just generate your DOM structure and be fairly confident in it performing well by default.

<comment> dj-wonk In the article:

> This little change ["track by"] invalidates 95% of comparisons between > ReactJS and AngularJS.

Please, let's stop using arbitrarily specific numbers with data to back it up.

</comment></comment><comment><USER35> We worked really hard to try to optimize angular code to make it "Fast enough" for our cordova app.. On the web, it doesn't really matter because everything was <20ms, but on the phone, the same operation was >250ms. We tried lots of hack with angular, and eventually, I tried replacing the slowest view with React. And without hack it was so much faster. It's obviously possible to do the same thing with Angular by not using the dirty checking (or not using $scope at all), but at this point, you're not really using angular anymore).

Point is, for us, React led to a much cleaner and faster code. I was also waiting for an excuse to jump on ES6 and prefer the controlled state/props to the $scope/directives philosophy. We're not using flux but have been highly inspired by it and (Optmimizely's) nuclear.js library.

</comment><comment><USER36> Developers have a tendency to get overly excited about speed. Fast database, fast search, fast framework, etc. The truth of the matter is that speed should be evaluated within a spectrum. As long as your application latency is within a spectrum, you should be just fine

<comment><USER9> Thank you.. for me React/Flux and the like just felt better than Angular 1.x while being fast enough. The tooling and support for something like Polymer just doesn't fit as well.

React with a flux-like flow is simply easier to reason with... When I've used Angular, I always hit points of frustration or weirdness that simply didn't make sense... the more advanced bits of React are less surprising in my mind. It's a shift in thinking about larger component based applications.

It's also worth noting that Angular was started some time ago in 2009 and likely in development farther back than that... this is before CommonJS or AMD were widespread, and jQuery was a rising star. This is very much reflected in Angular 1.x.

React is a different approach with a slightly more functional mindset (though I'm still not 100% sold on the structure). With a flux-like workflow, it's very easy to reason/structure your events and data.. yes events take some extra declaration, but your workflows become a lot easier.

</comment></comment><comment><USER37> Riot.js loops were fixed today. They are now around 4x faster than in React.

React: [http://jsfiddle.net/brianmfranklin/w674Lv7p/](http://jsfiddle.net/brianmfranklin/w674Lv7p/) Riot: [http://jsfiddle.net/gianlucaguarini/cbjuek58/](http://jsfiddle.net/gianlucaguarini/cbjuek58/)

just FYI

<comment><USER38> Your benchmark for React is not correct because when you do a second setState to show the duration it will be scheduled after requestAnimationFrame.

</comment></comment><comment><USER39> While the article shows some really good performance improvements, the tone is really sensationalist. While challenging 'comparison demos' in leiu for proof, the author responds with... yet another comparison demo

The title is not entirely falsified either - ReactJS is fast out of the box. Other frameworks can be tuned to achieve comparable speeds. But in most cases, ReactJS still wins.

</comment><comment><USER40> When I was using Angular I thought doing something like

      setTimeout(function() { $scope.$digest(); }, 0);

was an ugly hack and a sign of angular's leaky abstractionism showing up. Is this considered a good practice now (or always was)?

Edit: just to clarify, I'm asking because in OP this was given as a one of the way to fix Angular speed issues.

<comment><USER41> That's a sign someone has fundamentally misunderstood Angular and is hacking around their misunderstanding.

<comment><USER26> Why do you say that? What about it makes it fundamentally misunderstanding?

<comment><USER15> You should never have to use $scope.digest() unless you're testing a directive. You should never have to fire a digest loop manually.

</comment></comment></comment></comment><comment><USER42> As I was mumbling to myself in a recent other HN comment, it has become clear to me that few people take the time to actually understand the speed differences between various technologies. Even as "everybody" says how benchmarks are useless, "everybody" still uses the most trivial microbenchmarks to decide what's fast. (Perhaps the uselessness of benchmarks has more to do with "everybody" taking cognitive shortcuts than the benchmarks themselves....)

Amusingly, this produces the result that almost every technology is faster every other tech, with the exception of the technologies that are vastly more powerful than something else, but still at least as fast (i.e., Python is at least as fast as C at some task, so it must be as fast as C in general, right?).

(The natural reaction to _that_ is to assume that there is no such thing as speed differences, but, alas, that's not true either. No easy answers! There are things that are faster than other things at some tasks. And there are jobs where you really need to know which is which because even today, the difference between a 50-node cluster and 1 machine that does it all is quite monetarily significant....)

</comment><comment><USER43> The final point of the argument is the best to me. I originally chose using React because it appeared different from everything else. Thus far I feel I have been able to be much more productive and also think about things in my web application differently. The fact that is it fast is only secondary to the fact that I feel I can great a robust and maintainable codebase with more ease than I could with other frameworks.

</comment><comment><USER44> Seems strange that you have to use "track by" to get a speed up when it's meant to be used for something completely different. Is this really a "fix" to slow ng-repeats? Are there any side effects?

</comment><comment><USER45> How is something 310% slower. My physics professor would have slapped me for such sloppiness in wording.

</comment><comment><USER46> I think many of the "advantages" of ReactJS are just hype

\- Immutable data, one directional data flow are easier to learn, understand, harder to break etc. - This isn't anything new, these are just concepts taken from declarative programming. You could always have used those concepts in your JS. They aren't better/worse than imperative programming. That's like saying Haskell is better than C++.

\- Two-way binding creates infinite loops! - Umm... not if you're a half- decent programmer. I've worked with complex single page apps for years, even with junior developers, it's never been a problem.

\- ReactJS is so much faster - Only in unrealistic benchmarks as this illustrates (Mithril is faster in those benchmarks BTW)

React also has a few major downsides:

\- JSX breaks your IDE's error checking and line numbers in error messages (and not using JSX is a pain/verbose)

\- Being only the V in MVC leaves out too much. Now you have to patch together a URL router, http/socket communication script, custom solution for managing the model, etc.

<comment><USER47> Routing, http, and models aren't hard problems. Blaming React for not being an entire MVC framework is silly. It's not designed to be, and there are any number of ways to solve that problem.

Being able to use it with ANY different set of solutions for MC is especially good. I can use React for UI on top of old jQuery pages if I want to. I'm not forced to change my entire application to use it.

Decoupling is a really, really BIG benefit, not a downside.

<comment><USER11> .. until you're building a problem that requires regular external security audits, and you have to keep up with all of the micro-libraries you're using and any security issues they may or may not have. The Angular team has been very responsive to any security issues that have come up, and you get so much for free by using the framework.

</comment></comment></comment><comment><USER48> The tl;dr I get from this is that angular docs don't do a good job of actually documenting "fast by default" options.

</comment><comment><USER38> Ok the authors of 2 talks missed the Angular DSL to speed up the rendering of a 2D table. But what about deeply nested tree structure that change ? Is there a DSL to speed up that too ? If the author want a demonstration maybe he could try that.

<comment><USER26> You could still continue to use the track by syntax in the nested ng-repeats, but I would be careful. O(n^2) is always worrisome.

</comment></comment><comment><USER49> No kidding. I've been saying that frameworks like Angular, Ember etc. do their dirty-checking in the MODEL, whereas React, Mithril and others do their dirty- checking in the VIEW.

The former sometimes get some misses when the underlying data changes but the bound views stay the same. And how often does that really happen? On the other hand, "two-way data binding" is extra sugar that is, indeed, slow. Even Angular 2 got away from that.

So what is the point of using React or Mithril? Well, there are two. One is if you enjoy having idempotent rendering functions rendering EVERYTHING OFFSCREEN ON EVERY FRAME for making 1-1 correspondence between "state" and "view" explicit. The other is that Facebook actually uses it in their own products, and open-sources React Native, so you can technically build native apps (if you're willing to put up with their embedded JS environment instead of the browser's). And since they are so enthusiastic about it, maybe someday you will be able to re-use a bunch of components Facebook, or others, write for you, in your apps.

Personally, I will prefer [http://platform.qbix.com](http://platform.qbix.com) ;-)

</comment><comment><USER50> Setting aside all arguments in the article, I am just generally annoyed by the simple fact that he calls React a "framework" in the article. It's a library, not a framework.

Angular is a framework; it includes everything that you need (and in most cases, significantly more than what you need). You can build an entire web application using Angular without any other external libraries. On the other hand, you usually need to combine React with a router and some library to manage state (or stores/actions if Flux).

For this reason, we shouldn't even be comparing "Angular v. React". They aren't equal and they were not meant to be compared. If want to make a worthwhile comparison, try a "Angular v. React with Flux Architecture".

...but, honestly, can we just stop writing articles like this? What purpose do articles like this serve other than saying, "X tool that I use is better than Y tool that you use and here is why"? If you really want to share knowledge, write about best practices, anti-patterns, etc. Good riddance.

</comment><comment><USER51> >People have sent me links to a number of other demos. All are simply missing 'track by'.

really people? I knew most of the people spewing the angular hate didn't know what they were doing but this is kinda silly.

</comment><comment><USER52> Virtual DOM diffing (the approach taken by React) is "faster" because, in the most simplistic definition, you can intuitively come up with the optimization mentioned in the article as it needs to know what exactly changed to calculate. What's good with React is that it does some of it automatically (with the keys and the structure you have to provide) and also gives you control with the "shouldComponentUpdate" method.

Edit: Down-voters care to comment?

</comment><comment><USER53> Personally I never heard of the alleged speed advantages. I'm only using React for its architecture, i.e. functionally "pure" UIs.

</comment><comment><USER54> The jsblocks library authors are being incredibly deceitful with the tests they are showing off. Their entire premise is that they are faster than react but their tests are just manipulated. They posted this up on product hunt, [http://www.producthunt.com/posts/jsblocks](http://www.producthunt.com/posts/jsblocks), and at that point it claimed to be at 800ms on initial load where as react had 1250ms. I checked out the react code and there was a hidden input that was being rendered with every td element on the table. React has very heavy inputs which is why you are supposed to use state.

original test (with hidden td elements)

js blocks: 800ms

react: 1250ms

After removing hidden element

jsblocks: 350-400ms

react: 200-350ms

So yes, jsblocks can render a lot more input elements that you shouldn't be using faster than react. The react team explains why the inputs are fairly heavy when rendering a large amount, [https://github.com/facebook/react/issues/3771](https://github.com/facebook/react/issues/3771) They didn't stop there though and they responded to my claims and came back with a new test. This time they just ramped up the number of data points by double and added an extra td element to make it an unreasonable absurd amount of elements.

revised test (original test of 5000 elements to 18000 elements)

jsblocks: 600ms (they posted 700ms, so ill give them that)

react: 700ms (they posted 950ms)

After removing half of the data to about 9000 elements react already started to tie jsblocks

jsblocks: 450ms

react: 450ms

Going down to about 5000 elements

jsblocks: 250ms

react: 200ms

Whether or not there is any merit to this library, you can't just go claiming that you have the fastest library so audaciously like this blog post and their marketing. It's terrible for the community. There are an absurd amount of javascript libraries and getting devs to push a few key frameworks forward is already difficult enough. And if you are going to add another library to the list, at least be able to back up your claims.

I will admit that jsblocks seems to be better at rendering extremely large amounts of tabular data, but that is never an issue for me and you should be using lots of different techniques to mitigate that anyway. But once you get to realistic scenarios react is still faster and comes with tons of other advantages.

I didn't test the angular one because I don't know enough to spot odd code, but without even looking into the code the fact that angular was the only one that didn't have a minified library seems fishy. It's at 900+kb compared to the jsblocks/react at 125ish kb. To me it seems like since status qua is react is faster and angular is slower, they just constructed these tests to make it 3. angular, 2. react, 1. jsblocks (the fastest library ever!!).

So there's my rant. Please stop promoting your library like you are, it's just distasteful.

edit: [https://drive.google.com/folderview?id=0BxTyg4RuMOHUfjlvTkN3...](https://drive.google.com/folderview?id=0BxTyg4RuMOHUfjlvTkN3dzRaSU4wckh0b3lST3lrb3lzekdWVWhVSlJfWlRsLWszR0RuYjQ&usp=sharing) Here's a link of the original test without the hidden elements, the response test that required a ton of elements, and the email they sent still talking about their amazing speed!

<comment><USER55> I'm surprised this is the first mention of jsblocks, when the graphics displayed by the article shows jsblocks beating everybody, including React.

</comment></comment><comment><USER56> IMO Angular1 and React are so different in their approaches that it does not even make sense to compare them. If you want to base your application on a 'kind of' functional design with sane reasoning you should know what to use.

With Angular2 the discussion will be more interesting, but as far as I know Angular2 is not quite production ready.

<comment><USER26> Which is why we compare results, and not their philosophies and methodologies. It's like comparing CPUs from AMD and Intel, they have different architectures, but to understand real world performances, we compare results.

<comment><USER8> Except ReactJS and Angular are not the same class of thing. It's more like comparing an Intel CPU and an AMD motherboard.

</comment></comment></comment><comment><USER57> I tried to quantify the performance numbers - and react does show virtual DOM rendering improvements, but eventing is expensive.

[http://blog.nparashuram.com/2015/03/performance- comparison-o...](http://blog.nparashuram.com/2015/03/performance-comparison- on-javascript.html)

</comment><comment><USER58> I really don't like Angular (mostly down to dependency injection, issues I had getting some of the components to work with mobile and it's markup ngAttributes mess) and it put me off React until recently. React is superb and a really new way of thinking about user interface components.

</comment><comment><USER59> AngularJS is like writing in assembly. Sure, if you work really hard you can make it as performant as compiled C (ReactJS), but by that time your C buddy has built so much functionality you might as well stop all together.

(note: I've done professional angularjs and reactjs projects)

</comment><comment><USER60> Ironically, he mentions ember which is in the process of adopting the virtual DOM based approach.

<comment><USER61> This isn't entirely accurate as ember essentially diffs the dynamic values, but not DOM (or vDOM). In Ember the DOM is typically produced from pre- compiled templates and values are used to hydrate those templates or choose which templates are rendered.

Obviously exceptions exist, but this is by far the most common scenario.

When ember goes to "Detect" what changed, is basically ignores the DOM, and looks at the dynamic joint values such as {{#if firstName}} or {{lastName}}. Using this information, in then decides what DOM mutations are needed to bring the DOM back into sync.

As a side note: Babel.js has some related optimizations for JSX/react uses.

This all means, for DOM creation and updates the actual DOM is used.

Now this may sound scary, as we all hear the DOM can be slow. But as it turns out, some aspects of the DOM are actually quite fast, and often faster then the alternatives.

For example:

* fragment.cloneNodes to produce new content * node.textContent to update content – nicely leaves content inert, without needing costly JS based XSS escaping.

There are obviously downsides to either approach and as such likely some hybrid is ideal.

</comment></comment><comment><USER62> Just a question - why is immutability considered a performance improvement when in general it leads to performance degradation? I always assumed it supports a nice conceptual framework when dealing with difficult parallel algorithms but that's about it.

<comment><USER63> Immutability helps solve one of the hard problems in computer science: cache invalidation.

Mutability can always be faster given perfect optimization, in the same way as self-modifying assembly code can always be faster. However, actually doing that optimization on a byte-by-byte level is basically impossible. Techniques such as immutability makes reasoning about how to optimize general cases much simpler.

This often ends up with the trade off of higher ram usage and lower cpu usage, but a good enough general optimization can give lower ram usage too. Bad uses of immutability done for dogmatic reasons can often give you higher ram usage, higher cpu usage, and more complex code. As always, you do need to watch out for what you're using where and why.

<comment><USER64> Not saying you're wrong, but I've never heard this argument... How do you figure that immutability helps solve the cache invalidation problem? Immutability will _cause_ cache issues, not help solve them. The answer to the question seems to be simply that immutability allows quick comparison due to references being the same so a deep comparison is not necessary, nothing to do with cache-invalidation

<comment><USER65> I think what was meant was that immutability solves cache synrhoncization issues. More accurately, state synchronization issues.

If you think about the DOM as the projected state of an application, immutable data structures allow you to very simply define a functions that perform the transformation from application state to the GUI data structures (e.g. the DOM). If the state mutates this can cause cascading state changes that make this function much harder to reason about.

</comment></comment></comment></comment><comment><USER66> >> Is ReactJS really fast enough?

FTFY

</comment><comment><USER67> Is it really important? It exists to simplify app development, not to be fast. If you want fast, use similiar tools based on virtualdom module

</comment><comment><USER68> Speed is just one concern but there is a huge ecosystem and native aspects that is more than just one dimension.

</comment><comment><USER69> From other devs I know they have said React functionality on mobile is quite poor. Drag and drop and scroll, doesn't work as well, because the virtual DOM isn't adapted work to well on mobile. So for that reason, I won't use React, and rather go Vanilla or use Backbone. After getting burned by Angular, I'm really weary to adopt another fancy framework.

<comment><USER70> Drag and drop/scroll should work on the real DOM not the virtual DOM, no? I use Drag and Drop in a web app (using Om, which is a clojurescript library built on top of React) and it works just fine across all platforms.

</comment></comment><comment><USER71> It's not everything is about speed, I would choose manageability over speed anytime

</comment><comment><USER72> Do you use ReactJS because it is fast?

</comment><comment><USER73> my experience with react is that it's really fast.

</comment><comment><USER74> Shows how far too many developers don't question claims but take this stuff for real. Put it on a nice website with a cool domain name, fake some statistics and voila: Your new, web3.0 tech is out there. Bonus points if you are Google/Facebook/Apple.

Even if the article itself will be debunked as wrong, i feel that too many tech-savy people are too superficial.

<comment><USER75> I think the bigger appeal of React isn't the "performance." It's the fact that you can reason about your app as if you are re-rendering the entire application with every change in state. That way you never have to think about mutating the DOM, and you have less places to screw up.

If you actually re-rendered the whole app with every state change, it wouldn't be performant, but with the virtual DOM, it's totally feasible. It is definitely unfortunate that developers take statistics for granted (I'm guilty of this), but it doesn't undermine the usefulness of the framework.

<comment><USER76> > It's the fact that you can reason about your app as if you are re-rendering > the entire application with every change in state. That way you never have > to think about mutating the DOM, and you have less places to screw up.

This is really no different than Angular's value proposition - everything is bound to the DOM via the scope and re-renders automatically with every change in state.</comment></comment></comment>


Application deployment issues - <AUTHOR> http://i.imgur.com/H7thlRM.png

<comment><AUTHOR> Why big companies like Microsoft doesn't follow some standards when deploying application or services, at least they could have redirected to nice page instead of showing classic asp.net YSOD(Yello Screen Of Death) page</comment>


Firefox 32 Supports Public Key Pinning - <AUTHOR> http://monica-at-mozilla.blogspot.com/2014/08/firefox-32-supports-public-key-pinning.html <comment><USER2> I wish that this sort of stuff would come down to API-level interfaces.

For example, for the longest time Python's SSL library wouldn't even verify SSL certs:

[https://wiki.python.org/moin/SSL](https://wiki.python.org/moin/SSL)

And would gladly connect to MITM'ed sites. I think this is rectified, but the information I've found is conflicting.

It seems to me that securing API endpoints would be even more important than end users, as there's could be a much larger quantity of data through an API than a browser.

<comment><USER3> Python's SSL state has been worse than other languages because of the 2.x -> 3.x transition, so basically 2.7 was left broken for longer than ideal. Eventually, they decided to backport most of the network security improvements ([http://legacy.python.org/dev/peps/pep-0466/](http://legacy.python.org/dev/peps/pep-0466/)), see there the timeline.

Notice that this applies to the standard library; many people use the requests library which not only offers a superior API but also more security by default.

</comment></comment><comment><USER4> I wonder how this is going to work. I've been using an add-on to pin certificates for a half a year now and it's a hell on some websites. It nicely worked for my bank for a while, but they now employ the same technique as Google, Twitter, Facebook, Akamai, etc., changing certificates and even their CA seemingly at random. You'd think I'm being MITM'd but I'm pretty sure that's not actually the case.

Edit: I should read more closely, found it:

> the list of acceptable certificate authorities must be set at time of build > for each pinned domain.

So it's directly in Firefox' source code right now. Pretty much useless for anyone but a few big sites.

And the pinning RFC doesn't sound much better. It makes the client store something about sites they visited, which roughly translates to supercookies.

<comment><USER5> > And the pinning RFC doesn't sound much better. It makes the client store > something about sites they visited, which roughly translates to > supercookies.

I don't follow. If the user visits a site for the first time (ever) over a secure connection, they will become much more resilient to MITM for all future connections (including the ones where it updates).

That's a win in my book. At least it is a win from the "hacker" MiTM threat. It won't be as useful against states/governments since there might never be a secure connection ever.

But I'd take a solution NOW that works-ish than a solution maybe never which is flawless. Security in depth and all that jazz. The ultimate solution is some kind of secure DNS infrastructure which delivers information about HTTP certificates (which I believe is in the works also).

<comment><USER4> I'm not saying it's entirely bad, but it's something some users will want to disable for privacy concerns. The current model works well enough to allow widespread online banking and although this RFC will certainly make it _more_ secure, there are also disadvantages.

I happen to know that Chrome hardcodes a list of EV certificates (or at least I read so a while ago), it could do the same for CAs. Or the browser could ask a central server which CA belongs to a certificate fingerprint. Not that different from OSCP except that it'll probably be run by the browser manufacturer instead of the CA.

</comment></comment></comment><comment><USER6> Does anyone know why they didn't go with TACK?

<comment><USER7> TACK is a TLS extension. It must be added to TLS 1.3 RFC.

<comment><USER8> TACK doesn't have to be added to any RFC in order for browsers to adopt it. They could have integrated TACK, but chose not to. I wish they'd go the other way on that.

<comment><USER9> Sure, unless you want a standardized interface that everyone can reliably implement. Once it's in the RFC, people can start implementing it, but if you implement before there's a published standard then you're stuck with a broken implementation, or you break backwards-compatibility.

<comment><USER10> It wouldn't be the first RFC to begin life as an implementation instead of a spec document.

<comment><USER8> Which is the right way for an RFC to begin!

</comment></comment></comment></comment></comment></comment><comment><USER11> Maybe FF and Google should just become CAs? It would remove the extra step as currently both pinning and registering with existing CA are required?

<comment><USER12> Why should we trust them?

<comment><USER13> With the current setup, people are trusting mozilla/google to: Give you the correct software, Update silently, Determine which CA certificates to trust by default, and Determine which certificates are valid by pinning.

The CA is trusted to do: Determine which certificates are valid.

<comment><USER14> Not really. For firefox anyone can build from source (see also iceweasel), disable automatic updates. For chrome it's mostly the same, but then for Chromium instead.

<comment><USER15> Can you verify that the binary download of Firefox is compiled from that source unmodified?

<comment><USER16> There's work in progress to allow this. [https://bugzilla.mozilla.org/show_bug.cgi?id=885777](https://bugzilla.mozilla.org/show_bug.cgi?id=885777)

</comment></comment></comment></comment></comment></comment><comment><USER17> > Other mechanisms, such as a client-side pre-loaded Known Pinned Host list > MAY also be used.

Fantastic addition IMO. You could distribute/sync hash lists on and offline, awesome.

</comment><comment><USER18> The problem I've run into with public key pinning is captive portals. Mobile operating systems or browsers need to provide a better user experience for captive portals.

<comment><USER3> iOS have had good user experience for captive portals since a long time (iOS 3 I think), and also Mac OSX. They automatically detect when a captive portal is present by doing a background connection to some Apple-owned property and trying to download a small text file; if it fails for any reason, they bring up a modal panel showing the captive portal and letting the user login; then, they detect when the Internet access is active and close the panel (or, lately, let the user close the panel with a "Finish" button). What's more important is that the whole operating system / applications are not given the signal "network is on" until the whole process is finished, so you don't get one dozen of failures from applications that try to refresh in background and can't access their backend servers.

This said, I really hate the fact that the WiFi alliance has left us in this very sad state. Like many similar committees, they move too slowly; captive portals arose from a real-world problem that wasn't solved by the WiFi standard, so people had to come up with weird DNS/HTTP interceptions that fail in so many regards it's not even funny. If there's somebody to blame, it's not operating systems for not adding weird heuristics like Apple did, but Wifi Alliance for not bringing to the market a good solution for handling hotspots soon enough.

<comment><USER19> Apple customers, where phoning home on every network connection is good UX. What is wrong with you people?

I had this behaviour crash a captive portal daemon once, was fun tracking down the owner of the device in question in the building. "CapDaemon crashed, request came from around room A2.011!", "Let's get him before he's gone!", "Hey, Mr., do you own an Iphone or I pad? Yes? Please come with us. We need to have a debug session with you."

<comment><USER3> It _is_ good UX. For privacy concerns, it's already phoning home on every network connection for push notification registration (at the very least), so your objection is moot to me.

To handle this less centrally, you would need a distributed list of URLs to be used for captive portal checks, with servers handled by different entities, and each device selecting one at random from the list. This wouldn't change the UX though.

For your other remark, if the captive portal crashes for a standard HTTP GET to a normal URL, you can't really blame this on anybody else but the captive portal developers.

<comment><USER19> > so your objection is moot to me

"...because Apple already fucked it up elsewhere so double fuckup doesn't give extra points."

> you can't really blame this on anybody else but the captive portal > developers.

I don't think I did, thats just how I found out about this particular appleism. Also: This behaviour enabled us to track down that device and its owner physically too. So think about the sensibility of this "feature" in this light. Every other device would have enjoyed relative anonymity amongst the other devices in the building.

<comment><USER3> We're speaking of a device where Apple can silently push kernel-level code over-the-air at any moment. Surely an extra IP connection to an Apple server is not changing anything in the picture, but it is helping millions of people using their device without getting weird error messages or certificate errors every time they connect to a hotspot.

If you don't trust Apple with your IP, you shouldn't use a device which runs their kernels, that's a no brainer; if you do trust them, though, you might appreciate the way they go through multiple hoops not to handle too much of your sensitive personal data, see for instance the design of iCloud Keychain: [http://www.apple.com/ipad/business/docs/iOS_Security_Feb14.p...](http://www.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf)

So it's not like the impact of an IP connection is not taken into account in design considerations; it's just that it doesn't look so important in the big picture of the security and privacy implications of using such a device. For personal passwords, different avenues are taken.

</comment></comment></comment></comment></comment></comment><comment><USER20> What about DANE ([http://en.wikipedia.org/wiki/DNS- based_Authentication_of_Nam...](http://en.wikipedia.org/wiki/DNS- based_Authentication_of_Named_Entities)) ?

<comment><USER21> When you support DANE, you trust the various governments responsible for the various country domains to not wanting to MITM owners of said domains.

I'm sure everybody has a different subset of governments they would be putting in the "trustworthy" bucket and it's not up to the browser vendors to make a political statement there.

Browser vendors would have to trust all governments equally and AFAIK, none of them have publicly stated what their policies regarding MITMing DNSsec is, nor how well they protect their DNSsec signing keys.

CAs have to follow quite rigorous protocols if they want to be included in the browser default list and they have all financial incentives to comply.

Governments don't have to follow anything and even if they had, they have all the incentives not to comply.

This is why DANE, while otherwise sounding like a really good idea, is ultimately doomed to failure. No browser wants to take responsibility for less-than-stellarly performing governments and no browser wants to make a political statement by only supporting DANE for certain top level domains but not others.

<comment><USER22> CA model is broken (>500 of CAs, race to the bottom in terms of price, security is not a part of their business model). DANE is no better. What we really want is to be able to withdraw trust. There is no point for me to trust some Iranian CA. Why should I want to trust one? Today - I have to trust it, because you can't just remove CA without breaking a percentage of websites for you. And you can't normally erase CA from existence, because on single CA rely many customers and each of them will have broken website.

Please read about Convergence by Moxie Marlinspike. It solves the removing of trust problem.

<comment><USER23> With DANE it's immediately visible who you have to trust, and that can't easily be changed. If it's a .se domain then you know that only the Swedish govt can MITM that, with the current CA model any CA is able to authorize a MITM.

<comment><USER8> That would be great if looking at .COM wasn't an immediate guarantee that the USG could MITM something.

<comment><USER24> Don't use .com if you distrust them. It's still orders of magnitude better than the CA model.

The web site owner gets to choose which top domain to use and trust. It is not the end user that is supposed to value how much trust they put in each CA. That alone is the most important point right there.

<comment><USER8> This makes absolutely no sense to me. DNSSEC is a forklift upgrade of a key piece of the architecture of the Internet. We should incur that cost so that _all of the most popular sites on the Internet_ will end up with the USG as their CA? And that's "orders of magnitude" better than what we have now?

<comment><USER25> Today, for a .com, there are a large number of CAs (let's call it 100?) that can sign a cert. Additionally the registrar or the registry (VeriSign) can change NS and DS records due to a US court order (or otherwise) and the new destination could get a domain control validated certificate.

If DANE were adopted and the current CA system abolished, then the registrar or the registry could still change the NS and DS records to takeover a domain, but that takes us from 100+ parties capable of signing a cert to 2 parties that are already part of the system.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> this sounds identical to google CRLSet. Basically a list of pinned certs inside source code.

> In the future, we would like to support dynamic pinsets rather than relying > on built-in ones. HTTP Public Key Pinning (HPKP) [1] is an HTTP header that > allows sites to announce their pinset.

ok cool. Requires initial safe connection once. Like HSTS.

<comment><USER26> This is nothing like Google CRLSet. CRLSet is just a way of collecting the CRLs from a ton of different CAs and having a way to push those out to Chrome browsers easily without users having to individually download them all from the CAs.

Chrome has its own TLS pinning implementation that basically works the same way as Firefox's. See [https://src.chromium.org/chrome/trunk/src/net/http/transport...](https://src.chromium.org/chrome/trunk/src/net/http/transport_security_state_static.json)

</comment></comment><comment><USER27> Meanwhile Chrome doesn't even support OCSP (Certificate Revocation) for performance reasons, not even after Heartbleed.

I hope that doesn't sound like fanboyism, but not being able to communicate a certificate revocation properly is worrisome.

<comment><USER8> That's because OCSP doesn't work. The real-world Internet routinely breaks OCSP queries, which results in Firefox (and other browsers) soft-failing them: if OCSP doesn't work, the browser goes ahead with the connection. The security problem here is trivially observed.

TLS certificate revocation is a mess. We know what the solution will look like: it'll be something like HSTS, except that instead of caching "this site must use HTTPS", we'll also cache "this site must use OCSP stapling", and the OCSP data will be conveyed in-band in the HTTPS connection. It's hard to ding Chrome for not supporting something that doesn't really exist yet.

So, no: _not_ "for performance reasons".

Incidentally: Chrome more or less invented certificate pinning.

<comment><USER27> But OCSP is the only thing that's widely supported as of now. You can't on one hand say "don't blame Chrome to not support something that doesn't exist", when at the same time it rejects something that's widely deployed and even is considered a requirement for CAs.

Being able to revoke your certificate, even if it has problems is better than not being able to.

OCSP is still the standard way of communicating certificate revocations and even with all the HTTP-Extensions you need a way for certificate revocation.

Unlike most alternatives OCSP is out of the box supported by IE, Firefox, Opera and Safari. Only Chrome has it disabled per default. Most people revoked their old certificates after Heartbleed. This is an example of where you need an alternative to just pinning a key.

So you are saying that an attacker has to make sure that the OCSP connection isn't working means OCSP is worse than having no possibility of certificate revocation at all?

Not saying that it's absolutely secure. Hopefully everyone knows that there are flaws in HTTPS/SSL. Zooko's triangle[1] even gives you a hint why.

Also I am curious. What better, more widely used way of Certificate Revocation do you know?

[1] [https://en.wikipedia.org/wiki/Zooko%27s_triangle](https://en.wikipedia.org/wiki/Zooko%27s_triangle)

<comment><USER9> OSCP fails often enough that requiring a verified pass would break the internet. Thus, browsers which support OSCP treat a failure to fetch OSCP data as a soft fail (i.e. they ignore it).

The problem is that if you can MITM someone, you can deny them access to the OSCP service and cause a soft fail, which makes OSCP worthless.

<comment><USER28> Just because it doesn't stop a full MITM between the CA and the client doesn't make it worthless. It still protects the user from trusting a server that is no longer trustworthy.

If a certificate is worth issuing when a server is trustworthy, it's worth revoking when the server loses that trust.

<comment><USER8> We are talking about adversaries who control both secrets and connectivity. Not because those are the adversaries we care most about, but because those are the adversaries that key revocation contemplates. The notion of "full MITM" versus "partial MITM" versus "passive-only" attacker does not apply.

</comment></comment></comment></comment></comment></comment><comment><USER29> Yeah, makes sense. I guess. But I'm more and more worried about the web "platform", it just gets more and more complex each day.</comment>