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
Yeah, saw two double-binding packages. One uses Sessions, while the other uses Bindings object. Am I right?
