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

Meteor 0.8.0: Introducing the Blaze templating engine

meteor.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Meteor 0.8.0: Introducing the Blaze templating engine

#31

Post by chm »

kawera wrote: post #30
chm wrote: post #23

I want to write a web app, an SPA. After many years of not caring about web design [1], getting back into the game is very difficult, even if my programming skills are more than 10x what they were back then. I'm sold on JS, as to me PHP is very ugly and incomprehensible. My stack currently looks like this: Node -> Express+Passport+Mongoose -> Bootstrap + Angular/Polymer + D3 I've only begun my project three weeks ago…

Have you looked at Twitter Flight?[1][2]. Quite easy to grasp. [1] http://flightjs.github.io [2] https://speakerdeck.com/anguscroll/cal

Thanks, I had never heard of it!

Re: Meteor 0.8.0: Introducing the Blaze templating engine

#32

Post by chm »

Void_ wrote: post #27
chm wrote: post #23

I want to write a web app, an SPA. After many years of not caring about web design [1], getting back into the game is very difficult, even if my programming skills are more than 10x what they were back then. I'm sold on JS, as to me PHP is very ugly and incomprehensible. My stack currently looks like this: Node -> Express+Passport+Mongoose -> Bootstrap + Angular/Polymer + D3 I've only begun my project three weeks ago…

Well maybe it would be worth trying Meteor for you. I've tried something similar, that is Rails + Ember.js, and I find using Meteor.js easier.

The app I want to build would be data driven. I want it to be as fast as possible (it will have to plot graphs) and I thought I made a good choice with my current stack. The big difficulty is understanding where each library/framework shines, how to couple it with the others and when two frameworks have some overlapping functionality, which one to keep.

The reason I didn't go with Meteor at first was that I didn't really understand how everything fits together. I needed to build a stack block by block. But that was three weeks ago, I will definitely read more about Meteor and maybe give it a try.

One thing's sure, I have to make up my mind sometime soon or else I'll never have a prototype!

Re: Meteor 0.8.0: Introducing the Blaze templating engine

#33

Post by myhf »

rtfeldman wrote: post #28
avital wrote: post #20

Earlier quoted context omitted.

Hi, I work on Blaze. React and Blaze both compile templates or components into an intermediate representation for their HTML structure (React's JSDOM; Blaze's HTMLJS). A lot of the difference in how they decide what DOM changes are necessary. React re-renders components when data changes and diffs the resulting JSDOM. The diff algorithm is fast and has simple hooks to make it faster by letting you compare state and c…

Not to detract from the positivity of sweet new tech, but it's worth noting that "React outperforms Blaze when many elements change and Blaze outperforms React when few elements change" is the same as "React outperforms Blaze in cases where the user is capable of noticing a performance difference", which reduces to "React outperforms Blaze." Nevertheless, seriously appreciate the detailed and informative response. :)

I'll have to see how each one handles a big grid of rotating colored circles with numbers on them in order to make an informed decision.

Re: Meteor 0.8.0: Introducing the Blaze templating engine

#34

Post by ZeroGravitas »

rtfeldman wrote: post #28
avital wrote: post #20

Earlier quoted context omitted.

Hi, I work on Blaze. React and Blaze both compile templates or components into an intermediate representation for their HTML structure (React's JSDOM; Blaze's HTMLJS). A lot of the difference in how they decide what DOM changes are necessary. React re-renders components when data changes and diffs the resulting JSDOM. The diff algorithm is fast and has simple hooks to make it faster by letting you compare state and c…

Not to detract from the positivity of sweet new tech, but it's worth noting that "React outperforms Blaze when many elements change and Blaze outperforms React when few elements change" is the same as "React outperforms Blaze in cases where the user is capable of noticing a performance difference", which reduces to "React outperforms Blaze." Nevertheless, seriously appreciate the detailed and informative response. :)

That might be true, but it doesn't automatically follow. Java often gets dinged for startup time that it might make up for on longer runs and browser vendors seem to be sniping that their rivals are focussing on long term benchmarks at the expense of realistic workloads.

Re: Meteor 0.8.0: Introducing the Blaze templating engine

#35

Post by akbar501 »

gales wrote: post #4
elsherbini wrote: post #2

jquery compatibility is huge, awesome! I am a new developer. I've used meteor for a couple toy projects, and found it really easy to get started. past the basics however, I found it really hard to get answers. I'm currently trying to write a simple backbone + node app to get my head around all the things meteor does automagically. Are there any plans for learning resources coming from the meteor team?

A great learning resource is Discover Meteor - http://www.discovermeteor.com (purchase required, but great value for money, as it's been regularly updated since its release). The videos on Evented Mind are fantastic to learn from as well - https://www.eventedmind.com (recently introduced a subscription model, though, some of the videos are still free to play).

EventedMind is an excellent resource when you're ready to master Meteor. Chris goes into a lot of depth on each topic.

Re: Meteor 0.8.0: Introducing the Blaze templating engine

#36

Post by vjeux »

avital wrote: post #20
RaphiePS wrote: post #9

Can anyone speak to the difference in approach between Blaze and React? Or are they doing essentially the same thing? At first glance, this seems much better in terms of programmer productivity, given that it uses logicless templates rather than embedding HTML inside JS code. But I'd be curious if it's less performant.

Hi, I work on Blaze. React and Blaze both compile templates or components into an intermediate representation for their HTML structure (React's JSDOM; Blaze's HTMLJS). A lot of the difference in how they decide what DOM changes are necessary. React re-renders components when data changes and diffs the resulting JSDOM. The diff algorithm is fast and has simple hooks to make it faster by letting you compare state and c…

If you use `shouldComponentUpdate`, then React outperforms Blaze on the circle benchmark for both single and large number of updates. See Andrey Popp JSFiddles: https://groups.google.com/forum/#!topic/meteor-core/-px_AGhj...

React by default is fairly fast but what makes it stand out is that it gives the tools to make the bottlenecks faster without having to drop the nice abstraction.

Re: Meteor 0.8.0: Introducing the Blaze templating engine

#38

Post by masklinn »

avital wrote: post #20
RaphiePS wrote: post #9

Can anyone speak to the difference in approach between Blaze and React? Or are they doing essentially the same thing? At first glance, this seems much better in terms of programmer productivity, given that it uses logicless templates rather than embedding HTML inside JS code. But I'd be curious if it's less performant.

Hi, I work on Blaze. React and Blaze both compile templates or components into an intermediate representation for their HTML structure (React's JSDOM; Blaze's HTMLJS). A lot of the difference in how they decide what DOM changes are necessary. React re-renders components when data changes and diffs the resulting JSDOM. The diff algorithm is fast and has simple hooks to make it faster by letting you compare state and c…

> Blaze doesn't diff the resulting DOM structure. Instead, Blaze diffs the data the components depend on. […] Therefore when data changes, Blaze can directly update the relevant elements.

FWIW this is available to React as an optimisation if desired/necessary: by default React just renders the whole component tree on data changes[0] and diffs the result tree before updating the DOM — which is simple and usually performs well — but components can implement shouldComponentUpdate[1] to skip re-rendering if unnecessary[2].

[0] a React component could depend on non-react data, React is conservative and does not assume components depend only on data it can track

[1] http://facebook.github.io/react/docs/component-specs.html#up...

[2] and React provides ReactComponentWithPureRenderMixin[3] which can be mixed into any "pure" component whose output depends solely on application and component state, to get a free shouldComponentUpdate

[3] well "provides" may be excessive, it's in the repository but seems to be neither in the react distribution nor in the react-with-addons distribution. YMMV.

Re: Meteor 0.8.0: Introducing the Blaze templating engine

#39

Post by ermintrude »

chm wrote: post #32
Void_ wrote: post #27

Earlier quoted context omitted.

Well maybe it would be worth trying Meteor for you. I've tried something similar, that is Rails + Ember.js, and I find using Meteor.js easier.

The app I want to build would be data driven. I want it to be as fast as possible (it will have to plot graphs) and I thought I made a good choice with my current stack. The big difficulty is understanding where each library/framework shines, how to couple it with the others and when two frameworks have some overlapping functionality, which one to keep. The reason I didn't go with Meteor at first was that I didn't re…

Unless you're going to be wildly successful the moment you launch, you're better off picking one stack that you understand, creating a working version, then iterating to improve on it. If you try to do it perfectly or make it as fast as possible from the start you may never finish - and you'll never be able to test your idea.

Re: Meteor 0.8.0: Introducing the Blaze templating engine

#40

Post by masklinn »

vjeux wrote: post #36
avital wrote: post #20

Earlier quoted context omitted.

Hi, I work on Blaze. React and Blaze both compile templates or components into an intermediate representation for their HTML structure (React's JSDOM; Blaze's HTMLJS). A lot of the difference in how they decide what DOM changes are necessary. React re-renders components when data changes and diffs the resulting JSDOM. The diff algorithm is fast and has simple hooks to make it faster by letting you compare state and c…

If you use `shouldComponentUpdate`, then React outperforms Blaze on the circle benchmark for both single and large number of updates. See Andrey Popp JSFiddles: https://groups.google.com/forum/#!topic/meteor-core/-px_AGhj... React by default is fairly fast but what makes it stand out is that it gives the tools to make the bottlenecks faster without having to drop the nice abstraction.

Popp's fiddles don't use shouldComponentUpdate, as far as I can tell. They replace using props (application state) by components-local state and an animation prop. I'm not entirely certain that his semantics map to the original ones (in terms of expectations).
Post reply on HN