What do we the community do with Blaze?

[voidale]

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.

[waldgeist]

patent licensing thing

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

[zodern]

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.

[tseckert]

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.

[hwillson]

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

Shoud we learn React?

I can tell you how I see it from my point of view. I think the first step is to get Blaze to be available as a NPM module. And split also dependencies into separate repositories/NPM packages. Then having working testing. And some stand-alone documentation page. So first we should have basic project infrastructure. After that I think it should mostly depend on the community, what would they like to make pull requests for. As a matter of fact, I do not think I will have much time to work on …

Regarding

Where do we sign up?

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.

[nathantreid]

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

[mitar]

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?

[gfung]

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

[gadicc]

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.

[rebolon]

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

[townmulti]

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

[XTA]

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.

[illustreets]

Thought this will never be asked. I’d be very happy to contribute.

[msavin]

This is awesome man!

Edit: and wow, that took like two dozen lines of code too good

[msavin]

I’ve yet to try it - it does look interesting though. From my look into it, I feel Blaze is a bit nicer because it has a custom build tool for it, but I should probably look closer in.

[msavin]

Well, it doesn’t quite sound like this guy is a lawyer… I’m still waiting for mine to get back to me

[msavin]

I think what you’re trying to say is: there are people in the community that help advance MDG’s mission and interests, so what, if anything, does MDG give back?

[tidee]

I think what I’m trying to say is: MDG received $20m last year to further the Meteor platform and develop a legitimate business around it. They seem to be struggling to get sufficient development resources to maintain features that many have invested time and effort integrating into their commercial projects. I feel like I am being continually let down by this chopping and changing of agenda. Meteor seems to be heading towards becoming a wrapper for third-party-ware. In doing so, they are exposing themselves to the licences and agendas of those third-parties, over which they have no control.
I beleive that it was their intention to be non-opinionated. But in doing so, they end up chasing their own tail trying to keep up with all the new sparkly things that crop-up rather than concentrate of forming rationalised opinions about best-in-class methodology and making it their own.

[tomRedox]

@tidee

MDG received $20m last year to further the Meteor platform and develop a legitimate business around it

Says who? I’d imagine what MDG plan to do with their funding is pretty commercially sensitive info they wouldn’t be planning to share with their competitors.

[tidee]

If they’re not looking to form a legitimate busines aorund it, then what are they trying to acheive?