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

181–190 of 257 posts

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

#181

Post by mbrock »

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.

Centralized state as an immutable data structure is exactly how the app I work with is built. It's plain JavaScript and React. So I don't see how React is "behind" on this front.

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

#182

Post by Murkin »

astoilkov wrote: post #160
Murkin wrote: post #157

Earlier quoted context omitted.

Also, please add 'track by $index' to the Angular example.. might be a suprise for you. (Makes Angular outperform both frameworks)

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

You can try yourself, the samples are there.

And it does, just not Virtual DOM

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

#183

Post by lhorie »

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 optimization nearly impossible.

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

#184

Post by addicted »

martincerdeira wrote: post #32
gothy wrote: post #20

Earlier quoted context omitted.

I understand you very well. My todo list called 'stuff to check out' grows so fast that sometimes I'm thinking about clearing it out and just start another one.

Your problem is that have a life. Spend all day working and then checking out new stuff. Don't take a shower, eat on your laptop, etc. =)

http://www.nytimes.com/2015/05/25/technology/in-busy-silicon...

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

#185

Post by jellofiend84 »

Maybe I'm in the minority but after drinking the React 1-way data flow kool-aid I love it. I can think more logically about what a components state is and I can test for that state very easily. IMHO 2-way data bindings are not a feature anymore they are firmly on the cons list for me.

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

#187

Post by ccalvert »

kyllo wrote: post #25
kuyfiuyg wrote: post #18

Earlier quoted context omitted.

So don't study it then? It's perfectly fine to continue using what you are using. Most recruiters talking to me still ask for Angular, even if I consider it a little hairy and prefer not using it. After being in the JS sphere for a while and living with these changes, I have learned a lot. Because there is nothing new under the sun, these all do pretty much the same thing - but in different ways. There are tradeoffs,…

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.

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

#188

Post by xtrumanx »

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.

Immutable.js is a project also from FaceBook that brings immutable data structures to your JS applications including those using React.

Since Clojurescript compiles down to JS, wouldn't it be possible to use Immutable.js and a slightly different app design (a single Flux Store for the entire app) to get the same benefit of using React with Clojurescript?

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

#189

Post by pygy_ »

keslag wrote: post #154
Meai wrote: post #123

Earlier quoted context omitted.

What do you mean by "helper assisted javascript"? Can you give an example where this has caused problems for you? I'm trying to decide between mithril and this library.

Sorry, poor word usage on my part. As vvpan more eloquently puts it, DOM construction via js functions. This is the example from their website. This is very difficult to maintain, and personally, I become very adverse to making changes. Though it appears vvpan has a link to a project attempting to fork(?) React's transformer to be usable in mithril. todo.view = function() { return m("html", [ m("body", [ m("input"),…

Not "attempting to fork", MSX is a JSX fork that outputs Mithril-compatible virtual DOM JS objects.

It works as advertised :-)

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

#190

Post by loudmax »

aikah wrote: post #110
yummybear wrote: post #12

I think it's great that there is such an amount of active development in the JS sphere, and I'm sure your framework is fantastic - so don't take this as directed at your framework specifically. That being said... I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it. I constantly feel that I'm behind on my homework having to evaluate new libraries a…

> I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it. That's the nature of the job. In the front-end new frameworks are born all the time, new apis are created, new paradigms are "invented". Coming up with the "perfect" framework is clearly a work in progress. Here is a list of the techs I had to learn and work with during my career : - flex - jq…

I don't see the frustration so much about job security as about not being able to really get the most out of a technology before it becomes obsolete. It's one thing to be able to simply use some technology to get the job done. It's something else to deeply understand it and to become fluent in its paradigms and write code that is idiomatic and elegant. When a developer has to spend half the time learning new frameworks, it isn't so much about the loss of job security, it's the loss of craftsmanship.
Post reply on HN