Next steps on Blaze and the view layer

[lucfranken]

For those of you I haven’t met, I’m Geoff Schmidt, one of the original Meteor core developers and CEO of MDG. With Galaxy in the field now and doing great, I’ve been able to clear out a big chunk of my schedule and you can expect to see me much more active on the forums.
[…]

Think you did a great great great job on building such a terrific platform! Now it’s time to fix those damn communications.

9 days further, more than 300 posts in this topic only. Not to mention the other topics around related topics.

But nope there is no activity on the forums. No problem, you might have been busy, other things got priority, or it’s just not clear what to answer. Just get real on this.

Just be fair, talk to the people and say how it will go.

Some examples of clear answers which developers can work with:

• We do not guarantee support on Blaze from (give it a date). Also from now on bugfixes will not be our priority. New feature requests will for sure not be implemented.

• We will have a React - Meteor connection ready from at best 1-2 months. So in between do something yourself, the standard will not be set yet. After that we will push a new way to connect Meteor with React which we will call the standard so be prepared to update your code at that point.

• We will not make decisions on what is best practice, just take a look in the guide (which is now our answer to all of that sort of questions). That’s a guide, not a core direction, so we can and will overrule the items in the guide every minor version.

But stop talking about things which don’t become true. Better give a negative but clear answer, the damage will be much less.

[avalanche1]

Yeah, in would be nice to have a response from OP @gschmidt every 250-300 posts…

[emmanuelbuah]

I’m torn adding to 326 messages. I will be short and constructive. To answer @evanyou question

What do you like about Spacebars’ syntax?
- simplicity of syntax
- separation of template/code-behind but we can work with other version of combination

What do you not like about Spacebars’ syntax?
- lack of componentization, parent-child access

What do you like about JSX?
- template and codebehind in the same file.

What do you not like about JSX?
- template and codebehind in the same file in js file. Introduces unnecessary code editor add-on if you want code editor benefits since html is not supported (default) in js file

It sometime troubles me when engineers don’t truly understand why a technology is invent and what it should be used for. React is a component framework (for designing and building component like buttons, grid etc) with uni-direction bind at it core. Blaze is a template framework with bi-directional binding at its core. They do intersect but they not one and the same.

React isn’t perfect. It doesn’t solve all UI development problems and disregards one of meteors core principle - bi-directional binding but it also has great aspect such as componentization. I think Riot got it right when they realized that React was overly complicated for what it wanted to achieve. Embracing the spirit of html, riot is very familiar and simple to digest. Its simplicity is on pair with blaze if not better. That why I would suggest MDG to consider riot template style as blaze 2 built on top of React. Here is an example of what it html template file might look like.

 <sample>
  <h3>{{message }}</h3>
  <input name="newOption" type="text" / >
  <ul>
   {{#each techs}}
    <li>{{.}}</li>
    {{/each}}
  </ul>

  <script>
    this.onCreated(function(){
	this.options = new ReactiveDic(["blaze","react","riot"]);
    });
    this.helpers({
		message: function(){
			return "Hello";
		},
		techs: function(){
			return ["blaze","react","riot"];
		},
    });

    this.events({
		'click newOption': function(){
			this.options.add(this.newOption.value)
		}
    });
	  
    this.onRendered(function(){
		
   });
  </script>
</sample>

Benefits

• Simple and intuitive
• Familiarity to blaze users
• Template + codebehind in same file
• No need for additional IDE tooling since its basic html
• Can have all the power of react underneath without taking away the above benefit

[defusion]

I first looked at Riot yesterday after someone else mentioned it in this thread and I much prefer its setup to Reacts.

However like this post points out react is more applicable to components and that not what most of my blaze templates are in my application.

I have quite a few templates that are 100+ lines long where they have little to no JS associated with them or vice versa for some templates I’m using more like components, either of these setups are fine for a React/Riot style template.

The issue I’d have is where I have big templates with a lot of JS, though that might be an argument for breaking things up more into smaller components in some cases that just isn’t necessary and having the ability to keep them separated for me is cleaner.

It’s kind of the same thing with Ember views/components, most of the time I have separate templates for the ember view, however in some cases where the view is tiny I can choose to define the template as part of the view JS.

[npolet]

React is a component framework (for designing and building component like buttons, grid etc) with uni-direction bind at it core. Blaze is a template framework with bi-directional binding at its core. They do intersect but they not one and the same.

This is how I feel. Using react for everything feels like I’m forcing react to do something which blaze does much better. React is perfect for smaller components, but I’m not sure how I feel about splitting up my entire app into components. While logically I suppose it works, it just doesn’t feel natural to do so. Maybe my thought process is stuck in the more traditional template systems, but blaze just feels intuitive coming from ruby and django.

[waldgeist]

The goal is to render ur old blaze 1 code with react and allow you to code in the new react based components along side it. Ie the the whole enchilada.

Yes, I understand this, and I think this is a very good approach. I only see the problem that these two worlds might drift apart over time, as React is a quite different approach of solving things, so it is not unlikely that there will be situations where such a “wrapping” approach becomes nearly impossible. But, of course, I would love to see you prove me wrong, and I don’t want to disencourage you - on the contrary, keep up your excellent work!

[quote=“faceyspacey, post:298, topic:13561”]
MDG made their announcement without doing their homework and have likely not even started work on this[/quote]

Quite likely

Evan has no commits in this area and told me in the Sideburns forum he’s still busy with other stuff first. We can change their decision by showing them the way.

Not convinced that this will happen. I think they decided from their business point of perspective that they’d rather ride the React wave instead of investing more in Blaze, even if this would be possible. Partly, because they consider it as being unmaintainable, partly because of the huge community buzz around React, and partly because the component approach is so appealing. I still think that they cutting the wrong part here, since Blaze’s simplicity is something that got many people hooked to Meteor, but in the end it’s their decision. But, as said above: please, please prove me wrong!

[waldgeist]

Meteor can definitely be an enterprise level platform, but it should be closer to the enterprise needs and pretty often good enough is better than perfect.

Yes, that’s one lesson I had to learn in my professional career, and it was a tough lesson. I can understand that from a pure technical point of perspective, you’d like to stay on the “cutting edge”, especially if you consider yourself as being an innovation leader and don’t want to lose that status. But losing your community’s / customers’ trust is worse, much worse. So for any kind of software there comes the inevitable point, where you have to focus on reliability and trust instead of being the cool kid. And it’s quite hard to determine exactly when this point in time has come, I have to admit.

[waldgeist]

The time you spent on your messages / bridges / packages will be probably enough to read React docs and rebuild your apps with it so that you can finally stop worrying and start enjoying this great view layer and the opportunities it gives to you.

I would certainly agree if React could already everything that Blaze currently offers. But I’m still reading a lot about that Tracker integration is far from being optimal, that you cannot use 3rd party jQuery plugins, because React does not “like” any other framework to modify the DOM etc. This might be no problem if I had plenty of time to invest in a complete re-engineering, and I am quite sure that I will invest this time at a certain point, but for the time being I’d rather like to get my projects done.

[waldgeist]

Folks have been doing production apps months before it hit beta 1.0.1

Just for curiosity, as I was on Aurelia before I discovered Meteor and switched onto it: When I first tried Aurelia (this was in April or so), I loved the concepts and pretty much understood why its inventor left Angular 2, but Aurelia was terribly slow - just unusable on mobile devices. Has this changed since? I remember that the developer clearly stated at that time that Aurelia was not performance optimized and that they would approach this problem soon, but as I was already using Meteor, I lost contact to the Aurelia framework. I also read somewhere (maybe from you?) that Aurelia can be used together with Meteor. What are your experiences here?

[waldgeist]

@rohanray

I think what a lot of people here are trying to say is that as a start-up, they (including us) would prefer to invest their time and effort in developing and enhancing their app built with the adorable Meteor instead of developing Meteor (refactoring to newer versions) every 6 months.

Yes. Yes. And Yes. You absolutely nailed the point. Yet, I fear that MDG actually wants to drive Meteor away from the lean startup target-group into the corporate field. But they neglect that reliability and trust is even more important there. Been there, done that for many years. As an enterprise corp, I’d never bet on a framework that drops core technology so fast. Never ever.

[waldgeist]

including CSS is the next step a lot of React users have started to do.

And this “have started to do” is one of the reasons why I am still hesitating to use it.

[waldgeist]

@rohanray

Before someone starts picking out this specific example of Phonegap, please note that this is just an example to illustrate the concern that I’m trying to bring out.

Yes, but I fear that exactly this will happen. The current level of the Phonegap implementation is quite poor (even a simple hot-code reload can break your whole app, just to mention one of the issues) and I only see little progress on this field ATM (though I know that Martijn is working on the HCR thing; but he seems to be the only single developer actually working on it, as far as I can tell). For me, Phonegap seems to be one of the next candidates to be dropped. Just a guess. And this would hit me very hard, as my whole startup relies on it ATM. I would sleep much better if MDG would be more reliable, believe me.

[gaurav7]

React might solve some scoping issues, but the templating is an abomination.

There’s no “templating” in React, not in the traditional sense. It’s a framework for creating UI components (or “widgets”, if you can relate to them better). JSX is just syntactic sugar. Traditional “templating” with ReactJs (planned for Blaze 2) would look something like http://wix.github.io/react-templates/ (I expect MDG to keep the syntax as close to spacebar / Blaze 1 as feasible)

JSX breaks standards up and down and is a modern day callback to ngApp bloat and div spam.

Which standards? JSX has a well-defined specification. If you’re concerned about the W3C standard compliance of the generated HTML, well, check the html source of the page! You’ll see no extra attributes other than data-reactid. None of the templating languages’ tags/directives were W3C standards when I last checked.

Looking at these JSX return examples how not to cringe at what MDG is backing?

By taking the time to understand when components are more suitable than traditional templates (hint: complex apps). Or if you still have that cringe, then use the Blaze 2 templating that MDG announced their plans for. For apps that you cannot migrate to Blaze 2, continue using Blaze 1 that MDG says would continue to work…

Old Blaze code will continue to work, and it should be totally possible for both solutions to co-exist in the same project. My hope is that a user should be able to incrementally migrate an app to the new solution without committing to a complete rewrite.

[gaurav7]

Lack of if and for statements.

Ternary operators and boolean && have worked well for me in my JSX code, the trick is to have granular components. But if can’t live without tags for control statements, this should help: https://www.npmjs.com/package/jsx-control-statements. Btw, this is one example of how rich the React ecosystem already is, and exploding.

My designer can’t work with it

I have seen many comments in the thread that mention this. I highly recommend reading this: http://facebook.github.io/react/docs/thinking-in-react.html

[dinos]

@joshowens

I really appreciate MDG opening up about it’s plans, but it just feels very short-sighted for the community and like a lot of projects may be left in a lurch and will find it easier to just leave the Meteor ecosystem all together.

[…]

@rohanray

I think what a lot of people here are trying to say is that as a start-up, they (including us) would prefer to invest their time and effort in developing and enhancing their app built with the adorable Meteor instead of developing Meteor (refactoring to newer versions) every 6 months.

[…]

@waldgeist

As an enterprise corp, I’d never bet on a framework that drops core technology so fast. Never ever.

[…]

I am really quite frustrated with the “we are the community” uproar that is going on here… “The community” is mostly still out there. Fenced off by an arbitrary package system, weird load order and weak opinionated mvc practices. Meteor runs in danger of turning itself into legacy software before it even reaches the broad node.js community.

Anyone, a startup or enterprise who first bets on a year old cutting edge technology and now demands to stick to assumptions made during its development that proof weak today, did not do, or is not willing to do, their due diligence for themself and their clients.

The safetynet meteor brings to the table is crystal clear. It is open source! Meteors existence as a full stack library that allows anyone who has a heart hurting requirement for a specific element to fork and take care of it.

Meteor as a whole is in terrible need to converge back into the broader node environment to reach a community scope magnitudes larger than what we have seen today.

Making react a new baseline is a sensible step in that direction and as soon modules and build system alignments are done and the rest of the js/npm ecosystem are treated as first class citizens, we should see an explosion of components, packages and applications. Potentially overtaking atmosphere in a month. Here, higher velocity is something we all can profit from.

The value proposition was “great developer experience”. That experience can now be found elsewhere. And that is a problem for all of us who desire a confident project environment.

I’d also wish MDG would acknowledge those perspectives more than having our meteor community drift into an endless technical pro-con debate about the view layer.

[mz103]

The value proposition was “great developer experience”. That experience can now be found elsewhere.

No. You’re evidently missing the point.

What lured us to Meteor in the first place, and made development with Meteor more approachable and hassle-free for beginners/prospects, is the very thing that is being removed from Meteor.

[gaurav7]

Oops I deleted the post by mistake and can’t seem to undo it. Pasting it below…

@mz103

What lured us to Meteor in the first place, and made development with Meteor more approachable and hassle-free for beginners/prospects, is the very thing that is being removed from Meteor.

But do you want Meteor to stay “approachable and hassle free” only for beginners? As a “platform”, which is the consistent vision statement I’ve been hearing from MDG, it should be able to cater to the widest audience. There are individuals, startups and enterprises who are concerned about architectural decisions too, apart from developer experience (which btw doesn’t necessarily mean even my mama should be able to code).

I tried to go through the entire thread (turned out to be a good substitute for a late night movie ), nowhere was it mentioned that they’re killing Blaze. In fact, it’s a terrific innovation to build a templating engine on top of React. Do you care what Blaze 1 is currently using underneath? Would you stop using it if you found out that it was built using C++? For a beginner looking for a “hassle free” experience, I believe all they care about is the API and that “it works”! If MDG really built Blaze 2 the way they proposed here, you’d be able to use the template-like syntax as a beginner or for small projects, and seamlessly switch to, or mix, JSX components. Best of both worlds as I see it!

[Markusxmr]

Yes, it has changed.
I recall, the same worry with perfomance at the time.
One of the main bottlenecks was with core-js, which was resolved.

Maybe the truest indictor of perfomance, today, is to check their docs, which is made entirely in Aurelia. So anyone, let me/us know how it performs.

Yes, there are two packages on Atmosphere.
One is ahmedshuhel:aurelia, the original package, from a Aurelia core dev, which has not been updated for a while,
and a fork tsumina:meteor-aurelia, which is being regulary updated and enhanced.
Any issue that came up, tsumina was quick to resolve them.

Honestly, did not have an opportunity, yet, to do a production app with Aurelia and Meteor, so I cannot state any true facts.

One of the pros was that Aurelia in Meteor gets automatically bundled so the load speed is great.
The con, for me, was with occasional confusion with precise placement of Tracker.autorun in a app, I think a decorator would be awesome for that.

[goatic]

I’m pretty sure sideways data loading is very much going to be part of the react way very soon And it is much more intuitive with deeper integration than “getMeteorData”

I honestly think the debate about the view layer is somewhat trivial compared to the decisions being made about the data-layer.

I gave React 8 hours yesterday, and I’ve decided to do the same with Angular soon. I think anyone who has interest in the view layer discussion owe it to themselves to experience the options and reason about MDGs decisions after I trust MDG to make the right decisions and totally get why they’re building Blaze 2 on top of React

The work that’s being put into building webpack-ness into the meteor buildchain is veeery exciting :)))) not to mention proposed replacement of livequery

[massimosgrelli]

In my experience starting to hire large corp advocates helps. But MDG has one of the smartest group of people I had the pleasure to meet, so I’m sure that as soon as the big enterprise will be in their radar, they gonna start to do that. Probably in this phase they think they are too early to sell in that market.