Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: An Isomorphic JavaScript Framework Faster Than React

jsblocks.com

Post reply on HN
Print view View original

191–200 of 257 posts

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#191

Post by andybak »

kyllo wrote: post #142
AlexC04 wrote: post #113

Earlier quoted context omitted.

Not at all! Honestly there are some WONDERFUL things about angular. There are some bad ones too. - Polling for changes vs. event driven - two way data bindings causing infinite redraw loops. - "feels like O(n^2)" performance on ng-repeats / large pages but things like the templating, directives, data-binding... they are all really good things. And dependency injection! They have really moved the needle forward on cli…

ng-if, ng-switch, ng-repeat? There's already a language in the browser that does these things, it's called JavaScript. Why do you even need dependency injection and singleton services and factories in a dynamic language with closures and first-class functions? You don't. Client-side testing works fine without DI. Angular is just a way to do Java in JavaScript. It's a pile of unnecessary complexity designed to sell to…

> ng-if, ng-switch, ng-repeat? There's already a language in the browser that does these things, it's called JavaScript.

It's nice to have a largely declarative way to specify markup but still allow simple loops and conditionals.

Hasn't every template language in the world has come to a similar conclusion?

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#192

Post by br3w5 »

ccalvert wrote: post #187
kyllo wrote: post #25

Earlier quoted context omitted.

The problem is, it's our fault that recruiters are now asking for Angular, because we sold our employers on Angular and built their apps in Angular. Now that Angular is mainstream and has fallen out of fashion, they need to hire more developers to maintain all those Angular apps we built for them.

Angular is helpful because it promotes things like loose-coupling, dependency injection, modularity, re-use and the factory pattern. I agree that two way data binding was oversold. It isn't a bad thing, just not the most important thing about angular. No doubt angular itself, and other libraries, will evolve. But I don't think angular is a mistake. It encourages developers to design applications the right way.

Agree - i think 2-way data binding is a more superficial benefit vs the other benefits you mention

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#193

Post by Touche »

alejandrodob wrote: post #167
zaynetro wrote: post #149

Earlier quoted context omitted.

Could you explain why are they step ahead? I am not familiar with ClojureScript, but my interest in it is really high.

Because Clojurescript uses immutable data structures, and keeps the state in a centralized atom, so comparing different states is as easy (and fast) as comparing the different versions of the data structure, which in turn (and thanks to being immutable data structures) reduces to compare their memory references, which is fast.

Nitpicking but ClojureScript the language does not keep state in a centralized atom. That's just a common pattern used for Reagent/Om apps.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#194

Post by towelguy »

nahiluhmot wrote: post #60
ndreckshage wrote: post #23

Still relies on JavaScript server side rendering - which will be the biggest performance bottleneck, by far, for both this and React. If you really want a framework that is faster, check out Tungsten ( https://github.com/wayfair/tungstenjs ), which is as fast as this client side, and can render in vanilla Mustache using Go/C++.

I can't speak to this framework, but you do not need to use server-side rendering for React applications. Instead, you can essentially serve a blank page on every request, then have the React application bootstrap itself when the page loads. Alternatively, one could precompile the HTML, and serve it as static content with nginx, apache, etc.

It's funny Meteor actually has this problem upside down and are trying to add a way to have server side rendering.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#195

Post by woah »

alejandrodob wrote: post #167
zaynetro wrote: post #149

Earlier quoted context omitted.

Could you explain why are they step ahead? I am not familiar with ClojureScript, but my interest in it is really high.

Because Clojurescript uses immutable data structures, and keeps the state in a centralized atom, so comparing different states is as easy (and fast) as comparing the different versions of the data structure, which in turn (and thanks to being immutable data structures) reduces to compare their memory references, which is fast.

Nuclear.js also does this, with pretty idiomatic JavaScript

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#196

Post by Touche »

snarfy wrote: post #3

> Well, one problem is declarative programming has never been as expressive as imperative programming. In React you'd use JavaScript for this iteration. This is why I like React over say Angular, with ng-each, ng-if, etc. Flow control does not belong in markup. I cringed the first time I saw an XML schema with an IF element.

The other-side of the argument is that JavaScript is much harder to tool than HTML.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#197

Post by bpicolo »

zilean wrote: post #24
striking wrote: post #11

Earlier quoted context omitted.

Guess not. http://jsperf.com/ldash-vs-underscore

Why link version with year old code? https://jsperf.com/ldash-vs-underscore/3

Lodash was still slightly slower here for me.

Chrome 43.0.2357.65 on OS X 10.10.0

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#198

Post by Murkin »

astoilkov wrote: post #158
Murkin wrote: post #152

The speed comparison is sadly incorrect: Adding 'track by $index' to the Angular example makes it run 10x faster (outperforming both React and Blocks).

Are you sure you are getting correct results. Theoretically Angular can't be faster than both libraries because it does not implement something like diffing.

Yes, you can easily test it - the code they used is in a link on the site.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#199

Post by gclaramunt »

aikah wrote: post #122
anonymoushn wrote: post #61

What is it isomorphic to? How do I compute the isomorphism between this framework and some other thing?

> What is it isomorphic to? Don't bother, most people using this word in the context of javascript apps do not understand what it really means. It just has became a buzz word meaning :" you can render your views on client and on the server using JavaScript". IE you can render an HTML page representing the initial state of your app, then upgrade to an interactive application using JavaScript on the front-end seamlessl…

To be fair, it comes from the same people who call node.js "close to the metal"

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#200

Post by acdha »

lhorie wrote: post #183
amelius wrote: post #31

If you have N virtual dom nodes, and you are going to compare them every time a single thing changes, your performance may be good, as long as N is small. Unfortunately, React and similar frameworks don't deal with the case that N is large.

Actually, they do. React has shouldComponentUpdate, Mithril has subtree directives, Mercury has thunks, etc. One big difference between vdom frameworks and KVO/dirty checking frameworks is that since the virtual dom tree is in plain view (pun intended), it's possible to use advanced features to micro-optimize the hell out of it, whereas other types of engines tend to be more "black boxy" and make these kinds of optim…

That only helps if you had poor state management and churning updates to things which hadn't changed.

If you actually have a large number of DOM elements which need to be updated, you'll find that React is an order of magnitude worse than just using the DOM directly because it has to do that extra book-keeping multiplied by the number of elements.

Post reply on HN