@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
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 
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
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