React kinda sucks for projects that prioritize execution speed, and Facebook is crippling it with some kind of patent licensing thing. Meanwhile, Blaze is nice, developer friendly, and will supposedly be exported as a separate repo with its own community managers. So, what do we do with it?
A few thoughts to kick off the conversation:
Blaze is just the view, like React. It also needs a data layer (Minimongo, which needs Tracker), so we need to think about that. I think Minimongo is really nice as a way to store and query objects reactively, so its use goes beyond just being a Mongo cache.
Of all the features, I think incremental loading is the most needed. I have a theory that we can lazy load templates through method calls. What do you guys think about that?
Iām curious why you would pick this out of all of the possible features. This is a feature for the module bundler, rather than the view layer, no? If Blaze templates are just JS modules (which they pretty much are) something like Webpack or a future code-splitting Meteor bundler could easily be applied to templates as well?
@sashko Blaze looks very complete to me for most apps - what features do you have in mind?
A huge problem with Meteor apps is how big they are, it makes the initial load very pain. I havenāt looked at the Webpack integration yet - not sure how reliable the Meteor integration is nor what it would require. Now, a code-splitting Meteor bundler sounds awesome, but I suspect it could be some time until we get thereā¦ assuming you guys havenāt started working on it already?
I think what Blaze needs most is its own homepage, along with a simple tutorial that shows the right way to use it (meaning Blaze Components, ViewModel, etc.).
Perhaps what we should be asking is, with a $20m investment, why MDG continues to lean on itās community and third-parties to help out with ITāS product?
Iāve the domain blazejs.com would love to get it setup if people are interested, Iām still big fan of blaze, i would love to contruibite to the project.
I also want to say that React and GraphQL seem perfect for Apps like Facebook, when there are many Components on the screen. For smaller apps Blaze could still be the Framework of choice.
Also the centralized state handling is only better for larger applications I think.
What bothers me about Blaze is that first the two brackets ("{{ā¦}}") can be replaced by one (or is there any other use for one Bracket in HTML?) and second that one should be able to write most of JS within that brackets (maybe a miniJS or so or it could be just preprocessed into a helper file). Also the use of # for if but / for if-end just doesnāt seem intuitive to me, donāt know how others think of that. The way it is right now seems a little brittle, meaning I never know what is allowed at all (in terms of if, with etc. clauses) and then I end up writing helpers for almost every statement.
Also Session.set("ā¦") .get("ā¦") etc. get unhandy with time, same goes for ReactiveDict etc., maybe the syntax could be just like in normal variables: x = ā¦; or x.a = ā¦; instead of ReactiveDict x.set(āaā, ā¦); and then be preprocessed.
I mean it is just that with time it gets inconvenient.
Other than that I always liked the feeling of working on one distributed app instead of fronted, backend, server, client separate etc.
And also reactivity makes it easier for most apps, of course, for an app like Facebook it is impossible to update all changes.
@mitar had some great comments about the future of Blaze here:
Regarding
the answer is here! Take a look at the open issues and jump into the discussion. Things are pretty quiet right now, but if people are interested in keeping Blaze going things could really pick up.
@msavin: Incremental loading isnāt all that important to me, but your theory is correct.
Blaze Templates can be passed in as helpers (thatās how my Blaze Modules package functions), so loading them via methods is pretty straightforward.
How incremental do you want to beā¦ are just the templates lazy loaded, or are the JS files that reference those templates also going to be lazy loaded? If so, there needs to be a convention for storing them so the loader knows the 2 should be tied together.
Hereās a sample app that loads on demand a template from the āprivateā folder: https://github.com/nathantreid/blaze-lazy-example. It wouldnāt take too much to have that also import a .js file by the same name (or perhaps .blaze.js), and it would also be pretty straightforward to convert that into a build plugin that compiles all the server side templates and caches .blaze.js files, then sends them to the client on demand via a Method call.
Blaze hotloading. There isnāt terribly too much work to do here, I had something similar going in the fview-lab if people recall that (sorry, no link, it was hosted at meteor.com and I havenāt deployed anywhere else yet). Itās planned for my react-hotloading code to become more generalized so that someone working on this could use it (until then, best to develop as an isolated module in webpack I guess :)).
Blaze virtual dom. I started this at https://github.com/gadicc/meteor-blaze-virtual-dom, Iāll clarify/commit with an MIT license if someone wants to carry it on. I stopped working on it when it became clear that MDG had stopped investing in Blaze.
I would have loved to have gotten involved in all this stuff but unfortunately Iām too invested in React now. But Iāll try give input where I can.
@msavin di you give a try to vuejs ?
I liked Blaze because itās simple, and it allows to build something quickly. I disllike React for many, many reasons, but i like the concepts it brings with. For our latest professionnal project (huge international media website - cannot tell the name actually) we choose VueJS.
I can say that :
itās really simple, maybe simplier than Blaze
itās powerful : its directives are cool and it allows me to code faster and faster
i donāt need anymore Blaze
But, i still donāt have tryed VueJS + Meteor.
MDG will donāt put a lot of money on Blaze for long time, so we have to try the best alternative for quick devlopement, and i think that VueJS is the best solution. It only lacks a cool support for Meteor.
Mhh this is a Blaze topic, so we should discuss about Blaze improvements and not other JS frameworks. If you want to extend Blaze to have components or a better state handling, you can use ViewModel or Blaze Components, both work out of the box with Meteor.
).