Hi Geoff et al,
I’m Tim the author of the package Sideburns/Blaze React. I just want to reflect the reason why I created the package from the beginning. Basically I want to replace Drupal with Meteor some day, using only some packages to get the same features or maybe a set of packages (i.e. SpaceDrop, Universe or Orion). I want to do this because I’m so tired of the way we build CMSs today which I do every day, and they’re ages old now.
But to get there I first realized that in a CMS one has to render and load really quickly, because a regular user to a CMS is different from an app user in that they’re looking for information rather then a function, and doesn’t want to wait for anything to load, they want to access the acclaimed information kept in the page, and nothing more than that.
And to really get to this I realized one needs to render Blaze on the server and maybe incrementally load all its templates. So I started looking for solutions, first by actually rendering blaze on the server together with fast render and a custom package replacing spiderable. At that time I realized how tightly Blaze/spacebars was coupled with the client and to have all templates and code render anywhere I really had many fights to overcome.
Then one day @arunoda created a hacked together sample application, showing us how one could use react and a custom flow router to get fast page loads and server side rendering, it did all the things I needed. And I loved this approach, but I never really have come to love how jsx is written and I always have trouble getting an overview of the actual html output, I don’t even dare to show our designers jsx and that’s when I got the idea of parsing actual blaze templates, because blaze is awesome with the templates.
So starting on that idea, one had to create a plugin that parsed html, js or jsx files, but these extensions was claimed by meteor core packages already so I had to create my own extension which I never really liked. But thankfully with the release of 1.2, it was possible to overcome, except for js files which doesn’t even allow for me to read what’s in them to parse event maps which needs to be added before the transpiling is done.
Some quick things one could really gain with a new template system, and here’s what we should do:
- templates that can be overriden only by re-implementing them as is.
- helpers that use
this instead of Template.instance or Template.parentData to get access to the instance.
- event handlers that also use
this and now takes the context as first argument and the event as last argument.
- both events and helpers can also be overridden if re-implemented as is.
- and let’s stop using the global scope for anything and implement import and export using modules/packages for each file or folder or whatever.
I really like the idea of incrementally loading parts of your app, so let’s get add modules and webpack into core, and have people get used to the fact that they have to include something if they want to use it or override it.
Feel free to fork/use the regex I’ve written in blaze-react, I believe using regex is way faster than any other methods of parsing templates!
And as a final note, I love that you finally have messaged your thoughts to us in the community, I was starting to dislike the whole project due to the lack of personality in your public posts and missing information of your actual stand in these critical maters. And I don’t think the current format of public emails is very well done, compared to when you wrote all of them yourself from a more personal point of view, I miss that, and especially the – in the end. Anyhow, I do love what you’re doing! And I think @joshowens does so as well!
Cheers,
// Tim
I’ve had great success with Vue, Vue-Router, Vue-Meteor-Data, Webpack and Meteor and it’s much easier to learn compared to React.