Next steps on Blaze and the view layer

[praneybehl]

Since nobody mentioned Riot.js I would like to throw that into the mix as well.
http://riotjs.com/ By description, it is “A React-like user interface micro-library” and its really tiny
when compared to :

react.min.js – 135.0KB
polymer.min.js – 112.0KB
riot.min.js – 18.0KB

Riot is Web Components for everyone. Think React + Polymer but without the bloat. It’s intuitive to use and it weighs almost nothing. And it works today. No reinventing the wheel, but rather taking the good parts of what’s there and making the simplest tool possible.

"Riot has between 10 and 100 times fewer API methods than other UI libraries.

Less to learn. Fewer books and tutorials to view
Less proprietary stuff and more standard stuff"

Here is the comparison: http://riotjs.com/compare/

It has Web Components, VitualDOM, custom-tags, observables, router and SSR pre backed in.

I just wanted to drop it in the mix to gain some traction, since the underdog sure does need some.

[npolet]

I think it’s clear from the responses in this thread, that blaze really needs to stay part of meteor, without the need to migrate to some new system in the near future. It’s seems like anyone who has built an actual production application using blaze, just won’t want to migrate to something else. The key thing I like to see in frameworks/languages, is backwards compatibility.

I always look at the python 2 to python 3 switch. Porting code from python2 to python3 is really quite simple, but there has been a huge amount of resistance from developers to do so. The effect? Python3 hasn’t been adopted well at all (at least not until recently that is).

I develop with django a lot, and I just love their attention to backwards compatibility. It makes upgrading really simple, painless and cheap if your dealing with larger projects. I would be appalled if they were to just drop django’s own template system. I wouldn’t take the framework seriously anymore.

While I love react, I also love blaze. I can get something going really quickly, which is great for startups and prototyping, and can take to medium sized projects quite easily. I haven’t yet developed a massive project with meteor so maybe I’m missing the point. But really, the vast majority of applications are not huge, enterprise systems. They are small to medium codebases that need to iterate quickly and spend time on development, not migrating old code to keep in line with the framework.

And asking designers to deal with react? Absolutely not going to happen anytime soon. I would get laughed at if I was to suggest this to the designers.

I really doubt MDG would completely stop blaze support. If there is a nice migrations path from blaze 1 to blaze 2, then that would be perfect. But this has to be a slow process. Or at least allow support for blaze 1 for the foreseeable future.

But I have faith that the meteor devs will make something great with blaze 2. I’m quite excited to see where this goes, but I’m a little nervous about loosing backwards compatibility.

[Babak]

I’ve asked about it quite often: why can’t Meteor have the option to package up a Meteor NPM package with your client/API calls to your server all bundled in then you just include it with any front end you want with Optimistic UI and the whole thing built right into your package. Everything from React Native to Three JS, RiotJS, etc. all can use the package. Not sure if I’m not getting something on why this can’t be just a thing Meteor does. Even from a financial angel it would be great for them.

[avalanche1]

You guys just blurting things out without reading what everyone else is writing?

Well, well. You’re a really bright guy, are you not?

…I’m working on making this transition 100% seamless

Some of us don’t want to make ANY transition. And you are the one being blind not to see it.

Here’s the thread you guys should be following:

You are also the guy that should stop telling people what they should do and learn some manners.

[faceyspacey]

Some of us don’t want to make ANY transition. And **you ** are the one being blind not to see it.

im the only one working to make it so no–or at least the absolute most minimal–transition has to be made.

You are also the guy that should stop telling people what they should do and learn some manners.

if ur gonna take that route, then the prescribed path is not to do the same, which is what ur doing. I choose not to take that route, cuz ultimately, im ok with taking some slack if ultimately what Im providing is going to help you. It’s on you if you want to be part of the problem or the solution. I dont even know what this is.

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