Blaze Standalone

[znewsham]

Re-opening #290 as requested by @filipenevola

I think one of the key reasons people think Blaze sucks is that it's tied to Meteor - you can't use it without. It would be really nice to be able to have it be used as a standalone, either as part of webpack, express - or purely server side. I'm currently using it to print PDFs in a node application and it works OK, but it would be great to have an officially supported npm package.

[filipenevola]

Hi @znewsham maybe you should bring your npm package to this repo as well.

What do other Blaze users think about this?

[znewsham]

I'd be happy to do that, but for there to be any value to it I think there'd need to be a push to convert some of the dependencies (reactive var, random, etc) to NPM too, as officially supported packages, maybe under the @meteor namespace

[jankapunkt]

I think opening Tracker and ReactiveVar to NPM is good, the implementations could get some refreshment but are in general very solid and in my opinion I would always favour Tracker-ReactiveVar before any other state management.

[damon-t]

I think it would be an important step for blaze to be independent from meteor. Now for me it feels like blaze is not getting enough attention (anymore) or at least it's no longer in focus and even most meteor users are using react. The result could be in the worst case that blaze wont't be continue developed anymore. Because of this, even I as a blaze user am thinking about to switch to react.
So I think a standalone version would make blaze more popular and it could also have affect on the publicity of meteor.

[jankapunkt]

@damon-t Blaze has not been updated that much since ~3 years and it just runs fine and stable, which is such a great value for a library/framework. However I agree that if Blaze wants to have a sustainable future then it should be opened.

[distalx]

I love the sound of the standalone blaze. In past, I come across a diagram explaining the internals of blaze. Not able to find it at this moment.

If we decide to move forward with this, I think for starters we need to figure out what part of the blaze is tightly coupled with meteor and what part can be easily port over to npm.

[filipenevola]

Hi, if Blaze users believe this is the best path for the future of Blaze we are here to support.

Of course moving it to NPM would open many new opportunities but it also requires a good amount of work.

Who is willing to join this effort? We need to be realistic here.

If we have a decent number of developers willing to do this, great, let's do it.

Otherwise we could keep Blaze tied to Meteor and improving it.

Blaze tests are back to the CI and also Blaze HMR is almost ready. So Blaze is still maintained as it is.

[damon-t]

With some introductions or help I would like to help.

[harryadel]

I think opening Tracker and ReactiveVar to NPM is good, the implementations could get some refreshment but are in general very solid and in my opinion I would always favour Tracker-ReactiveVar before any other state management.

I'd like to help out with the Blaze standalone too but it seems that the conversion is a low hanging fruit so I started working on https://github.com/harryadel/blaze-standalone

It's still in the works with multiple bugs to fix but the biggest show stopper right now is how Meteor variable is taken for granted.

Example:

// Takes a function `f`, and wraps it in a `Meteor._noYieldsAllowed`
// block if we are running on the server. On the client, returns the
// original function (since `Meteor._noYieldsAllowed` is a
// no-op). This has the benefit of not adding an unnecessary stack
// frame on the client.
function withNoYieldsAllowed(f) {
  if ((typeof Meteor === 'undefined') || Meteor.isClient) {
    return f;
  }
  return function (...args) {
    Meteor._noYieldsAllowed(() => {
      f.apply(null, args);
    });
  };
}

The only solution I can think of is to migrate as much as possible of the code to an NPM package and create a wrapper atmosphere package that uses such an NPM package and injects the additional Meteor specific code. What do you think guys? I'd gladly welcome any other solutions and suggestions.

Also, this package is a prime candidate for a typescript make over, would you guys be ok with that?

[jankapunkt]

I think we can extract the Meteor variables where possible and allow to inject them as dependencies. I will take a look at your fork and see if we can solve this on an architectural level without the need to open dependencies to npm

[StorytellerCZ]

I and @harryadel have started some small works here. Right now just focusing on cleaning up the code and reducing dependencies.

[harryadel]

@jankapunkt have been doing great work too and we need to coordinate our next efforts.

[znewsham]

I think opening Tracker and ReactiveVar to NPM is good, the implementations could get some refreshment but are in general very solid and in my opinion I would always favour Tracker-ReactiveVar before any other state management.

I'd like to help out with the Blaze standalone too but it seems that the conversion is a low hanging fruit so I started working on https://github.com/harryadel/blaze-standalone

It's still in the works with multiple bugs to fix but the biggest show stopper right now is how Meteor variable is taken for granted.

Example:

// Takes a function `f`, and wraps it in a `Meteor._noYieldsAllowed`
// block if we are running on the server. On the client, returns the
// original function (since `Meteor._noYieldsAllowed` is a
// no-op). This has the benefit of not adding an unnecessary stack
// frame on the client.
function withNoYieldsAllowed(f) {
  if ((typeof Meteor === 'undefined') || Meteor.isClient) {
    return f;
  }
  return function (...args) {
    Meteor._noYieldsAllowed(() => {
      f.apply(null, args);
    });
  };
}

The only solution I can think of is to migrate as much as possible of the code to an NPM package and create a wrapper atmosphere package that uses such an NPM package and injects the additional Meteor specific code. What do you think guys? I'd gladly welcome any other solutions and suggestions.

Also, this package is a prime candidate for a typescript make over, would you guys be ok with that?

If you want you can use mine as a starting point: https://bitbucket.org/znewsham/meteor-blaze it works both in meteor and externally

[harryadel]

@znewsham Thanks a lot! Your implementation will definitely be our starting point as I'm curious to know how you solved the compiler issues. Looking at the good and bad sections of the docs we can definitely pick where you left off as you've already done most of the heavy lifting. 👍