What do we the community do with Blaze?

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:

  1. 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.

  2. 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?

21 Likes

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?

1 Like

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

22 Likes

I’d like to see a fullt-fledged Blaze revival. I’ve concerns over React’s patent licensing issues.

4 Likes

Are there some people on here who want to invest real time reviving Blaze?

7 Likes

Where do we sign up? :wink:

6 Likes

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.

5 Likes

Could you please elaborate a bit on that, e.g. by providing a link? I’ve not heard about such issues before (maybe because I stick to Blaze :slight_smile: ).

I would love to help. I had stopped working on the blaze website since I thought blaze would be abandoned and then I forgot about it.

1 Like

Hi,

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.

1 Like

@mitar had some great comments about the future of Blaze here:

Regarding

the answer is here! :slight_smile: 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.

3 Likes

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

5 Likes

Current blocker for further development is this ticket: https://github.com/meteor/blaze/issues/13

We have not been able to find a good working approach. Any innovative solution?

1 Like

On the React patent issue, it’s a non-issue: https://www.reddit.com/r/javascript/comments/3zgo35/reactjs_licensingpatent_issue/cym77l0

2 Likes

I think two things that could be nice would be:

  • 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.

3 Likes

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

3 Likes

Does anybody have an experience or a review of Mithril? http://mithril.js.org/

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.

4 Likes