Is Blaze still worth it (supported in the future)?

@AndreasGalster What exactly you mean with class/id hell ?

I guess itā€™s a reference to callback hell, meaning a whole lot of classes and ids in templates simply for the purpose of being able to address them in events.

I donā€™t see the problem, personally. Itā€™s more a matter of preferences and code organisation.

I donā€™t have much of a problem with a lot of class selectors, as long as they are being addressed efficiently behind the scenes. Of course if youā€™re using a semantic css framework or custom class system, youā€™ll have to really start watching out for spaghetti and coordinate your class structure in a readable way.

Exactly. I find it nicer to call an event function on the actual element. If wanted itā€™s still possible to define the eventlisteners via idā€™s but it makes it easier to swap out stuff this way at least for me. But in general I really like how databinding and building components in Polymer works in general.

The basic Blaze/Spacebars API will stick aroundā€¦ HTML isnā€™t going anywhere, and will need to be pried out of the cold, dead hands of an entire generation of programmers. But the technology itā€™s based onā€¦ thatā€™s totally subject to change. Sideburns is the most promising attempt to rewrite the Blaze/Spacebars API over React. That seems to be the future of Blaze, imho.

2 Likes

@joshowens http://joshowens.me/facebook-to-acquire-meteor/ :laughing:

1 Like

To be fair, Spacebars does the same thing under the covers that React does. In the end it all turns into compiled javascript that is run and inflates HTML into the DOM. Spacebars just does it in a way that some humans like moreā€¦

3 Likes

It was definitely a joke! I updated the post a long time ago to have a TLDR saying as much.

Be sure to read that for sure! ^^

1 Like

Personally I think Blaze should stay simple (or become even more simple) so itā€™s very approachable for beginners and small apps. A Blaze 2.0 seems like re-inventing the wheel. Making it complex is losing sight of itā€™s pros.

If you need lots of structure in your view layer, or it has a lot of complexity, or you need lots of logic in the view, something like React can help out with that at the cost of extra syntax.

1 Like

wow, sideburns and magic-events are both awesome and should have more visibility. Iā€™d never heard of either

It has been amazing to see so much discussion and innovation within the community around this topic. Iā€™m sure both project will have a future for the foreseeable future. At my startup, we decided to stick with blaze for now just to see how the landscape evolves post 1.2, as the cost of switching to react doesnā€™t really bring much benefit for us at this timeā€¦ That said, should Blaze not evolve, we will seriously consider making the switch.

Iā€™d say youā€™re doing it wrong :smile:
What about using frozeman:template-var and you have no scope problems anymoreā€¦

1 Like

Color me completely confused. I donā€™t understand the thinking behind the position MDG has navigated themselves/us into. How can we have this super successful and wonderful framework that all of a sudden does not have a clear forward strategy for its front end?

I came here because I am about to commence development of my third major Meteor based project, and I wanted to read up on the latest and greatestā€¦ only to find that ā€œBlaze basically did get de-prioritized at MDGā€ according to David Greenspan, and that we have as alternatives a tacked on implementation of React that doesnā€™t feel good to me at all (jsx? mixins? canā€™t use collection cursors? no user account system?) or a soon-to-be-replaced-by-the-incompatible-version-2 Angular v1 to choose from.

After reading all the links in the discussion above I stand totally confused about which way to move forward for my next projectā€¦ Not fun.

12 Likes

I have been using Blaze since the git go (meteor 0.4.0). And honestly it just works and gets the job done. I find that large projects will always have problems but Blaze keeps things clear, even at the cost less then DRY code.

MDG as not said they will stop supporting Blaze, only put in on a lower priority. I expect if it every become a real problem MDG will come out with a solid solution, or at least give us a path. Maybe turn Blaze into a React wrapper, maybe not.

Regardless I am sticking with Blaze as it is still plenty functional and fast, even on my Cordova apps.

2 Likes

I think the future development of blaze (or Meteor itself for that matter) doesnā€™t necessarily have to be a make-or-break decision point.
If the current implementation and APIs work perfectly for you, there is technically no reason to ever upgrade (or refactor) in the coming years.
And if you do think about it eventually, youā€™d probably look at potential other options anyway.

So while we are all used to forward-thinking when choosing the right technologies for a project, for some projects there are advantages to just sticking with whatever works right now.

2 Likes

Blaze Plus looks niceā€¦ https://github.com/kadirahq/blaze-plus

1 Like

As I already said via Slack, Iā€™m very interested to hear how your experiment of Meteor and Polymer works out. Please do keep me updated as I plan to walk the same path

2 Likes

I tried experimenting on Meteor and Polymer as well, with the help of @AndreasGalster (met him in person last weekend). You can check my progress here https://github.com/tjmonsi/meteor-polymer-comeback

I have used Differentialā€™s Vulcanize. I am thinking of creating a package that loads all polymer 1.0 components and auto-loads them to the project (so you donā€™t have to bower and config things yourself, with the expense of loading everything you donā€™t need), but maybe in the near future.

As for Blaze, I think @arunodaā€™s Blaze plus is a sign that Blaze is still worth it. I really like how things get compartmentalized in Blaze and still get things working (and with Blaze plus being able to render only what needs to be rendered, it is a good addition that can beā€¦ I repeatā€¦ that can be a bit at par with React when it comes to rendering components). The only thing missing is the double-binding of input elements (with the addition of Polymerā€™s own input elements such as paper-input) to javascript objects/variablesā€¦ if that will be the plan for Blaze in the future, then I guess we will not depend much on jQuery to get the values and just use scoped variables to get data.

1 Like

Iā€™ve tried to switch to React, used it for a couple of days, migrated some code. But finally, I gave up and rolled back. Everything I tried to do made me feel like Iā€™m hacking it. This mixins, this.data. I almost felt I was doing smth wrong and my productivity was awful.

Personally, I always followed the same idea as with React - I have two files for a component (html + js), use template subs, template reactive-vars, nothing global. I also use controllers package and I like it. So, I really donā€™t see any benefit of React for me. The speed/performance is the same.

I always loved meteor for its simplicity and beauty. React removed this feeling. How is your experience?

2 Likes

The only thing missing is the double-binding of input elements

Well, there are two packages for that, by Manuel and Dalgard.

1 Like