Next steps on Blaze and the view layer

core
302

Just to quickly say: you really shouldn’t call Blaze2 “Inferno”. It’s already the name of another known JS library that does very similar things: https://github.com/trueadm/inferno. In regards to moving forward with React, I think it’s a massive “given”. React has very much redefined front-end development SPAs. Without question, it’s been the biggest revolution in terms of frontend JS design patterns for years.

Also in terms of performance, Aurelia has been shown to be pretty awful in terms of some of the benchmarks out there. My own company also did a spike with Aurelia and found it do be quite a bit slower than Polymer 1.2. This was a big problem as we’re building mobile applications and the difference was very much noticeable on Android (iOS was fine) funny that).

6 Likes
303

Then you’ll benefit from a widgets library like Webix.

2 Likes
304

Kudos for pointing it out, @dandv, I like it very much, though prices are rather steep, but in a context of said app and its potential market, it doesn’t really matter :wink:

305

Thanks for sharing! But my project is exactly be different from the others ERPs. All ERPs like systems, use the same way to do things and have similar visuals. My project is most focused on be really easy for users, and do a log of things with few clicks.

306

The same reason we’ve been separating HTML and JavaScript for decades? Seperation of concerns.

Or do you also put all your CSS inline? :slight_smile:

3 Likes
307

@tmeasday shared some interesting opinions over at this thread

Although starting a project in pure React seems like a pretty foolproof way to avoid any transition issues (and that’s what @sashko’s said), I think there are plenty of reasons why you might not want to do that (either due to the issues that the Templates+React project aims to solve, or simply that you want to use all the existing Blaze goodness that’s out there).

Kind of helped dissipate the anxiety about blaze getting dropped :slight_smile: Although, left me hanging about what to choose now.

There is also a thread opened by @msavin that deals directly with what to do starting right now meaning what is actually foolproof/futureproof.

1 Like
308

@dandv from what I gather from this issue webix won’t be a good match with React, if one chooses to go React, is that right?

Also I kind of find webix (and kendo for that matter) too disjointed from layout and templating. For example, for a complex form layout with lots of controls, webix does not provide a clear picture of what goes where all because we can’t sprinkle the webix controls into the template, but rather inject the whole monolith into a single container element. Right?

Looks damn good, though! Granted that!

309

I come mainly from a Java background with close to 6 years of software development in Java for corporate giants. What I like about Java is that it is robust, stable, scalable, huge huge ecosystem including libraries, frameworks, tools, apart from stackoverflow & numerous other forums’ questions., patterns, etc. etc.

Do I still like Java today? My reply would be yes absolutely and I am especially proud of one thing which I realized in last few days: The things that I learnt about Java and all the code that I had typed on day 1 (6 years back) still hold good and true.

I acknowledge the fact that it’s a heinous crime to compare a couple decades old, proven and alive programming language Java to a vey new young and budding development framework Meteor and before I get murdered for this act, I would like to share my beautiful and lovely encounter with Meteor in March 2015.

In March 2015, myself and a couple other geeks ventured out to build an enterprise PAAS B2B application for a specific industry and the first question was what do we use to build it? In the last couple years, we had worked a bit on Angular, Backbone, and we really liked the simplicity and more importantly the amount of time that is saved compared to compiling Java source, packaging into a WAR/EAR, deploying to server for changing a single line of code. Trust me it takes ages :slight_smile: Hence, we started to look into MEAN stack for turning out quick MVPs and POCs. We had a problem: we now had to learn Angular, Express, Mongo and we just started searching if this route can be further shortened and boy we discovered the Magic land of Meteor and it was love at first sight mainly because of the following:
Isomorphic JS development platform and hot-deploys,
Reactive out-of-the-box
The most important: it took us less than two hours to install Meteor and learn the basics using the To-Do tutorial and before we knew it, we had already started developing our app. Such was (still currently is) the simplicity and magic of Meteor.

The official documentation although a bit poor, official meteor forum, atmosphere (love it), stackoverflow helped us cruise through our app development, since all Meteorites spoke the same language: Blaze, spacebars, helpers, events etc.

In the last few days, however, we feel like Meteor was indeed a dreamland, a comet far away from the reality of earth. I apologize if it sounds too harsh. Hopefully, that’s not the case. Here’s why we are so concerned.

Earlier if we had any query/issue, we would simply post the query on meteor forums or stackoverflow and additionally mentioning the meteor version being used by us. In the near future, the meta-data for such a post would be like:

Meteor version: 1.x.y Template: React (or Blaze or Angular) Router: Iron router (or flow router or hopefully someday core-router) Build system: Meteor core (or webpack or gulp)

Similar repercussions would be felt in atmosphere packages: it would be mandatory for package maintainers to specify above metadata in their “Supports” section of the package homepage as well.

What worries me is the kind of mysterious direction MDG would take in the indefinite near-future based on questions like:

The last question is really important here: What do you not like about JSX? Why? May be (pretty sure), such questions are also being raised outside Meteor community and within React community. It’s quite possible that someone (or some merry geeks) out there are currently working on addressing these issues and then publish a better open-source framework “ReactNext” probably in another 4 to 6 months (being a bit over optimistic) solving JSX limitations. On the other side, let’s say MDG releases Meteor v. 2.0 with official new templating language Blaze2 or inferno or something else with the being discussed React thin layer atop Blaze. Our next task would be to then learn React and refactor our entire app (to v. 2.0) which then gets over by the time “ReactNext” hits the market. What happens then? A similar thread and similar discussion to chuck out React and target Meteor v. 3.0 with “ReactNext”? It would be a nightmare to then learn “ReactNext” and then refactor all over again.

I am not against React or Angular or Blaze 2 or any other templating framework for that matter. I think what I am looking for is if MDG agrees to go with React as the next templating language, can we be assured of a LTS (may be 2 to 3 years). Support would not simply mean backward compatibility but more importantly active maintenance i.e. fixing open Github issues and upgrading the same templating language over the duration of LTS to include the new features and enhancements of other parts of Meteor. This a major concern looking at the way MDG treated its own quite good (may be not perfect) templating language Blaze, first by ignoring the open Github issues and then in a process to kill it altogether.

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. Hence, I believe to gain some trust and lighten this thread, it would be really great if MDG first officially announces the two key-points 1. tentative release timeline of this new templating language and 2. long term support duration of the same including bug fixes and enhancements; there would be some fear and scepticism among the community (especially the older members who have Meteor apps running on production) on discussing about the new templating language. I believe this holds true for any major enhancements or changes to any part of Meteor. If this question cannot be answered (rather commitment) before taking a decision to change core parts of Meteor and deprecate existing ones, then unfortunately we face the same dilemma while trying to sell Meteor based apps to our customers; portraying Meteor as dreadful, unstable and unknown since we would not know what Meteor has in store for us in the near future.

However, if those two key-points are first confirmed, then the community would be aware of the upcoming changes and plan accordingly. The tentative release timeline could then also accommodate some dedicated time to discuss the design and architecture with the community as being discussed in this thread regarding the next gen templating language of choice for Meteor (including validating the fact that this is what the community needs right now or prioritise other tasks on the roadmap). It would also avoid a lot of questions being asked in this thread viz. “if we start with meteor now, should I pick Blaze, React or Angular?”

Disclaimer: All of the above is my personal opinion :slight_smile: Having said that, I am quite positive Meteor is here to stay for a very long time and I will be riding on it for a long time as well.

18 Likes
310

I acknowledge the fact that it’s a heinous crime to compare a couple decades old, proven and alive programming language Java to a vey new young and budding development framework Meteor

@rohanray on the contrary, you have every right to bring up such comparison all because Meteor is a well-funded company with eyes on the enterprise market and all that matters is the professionalism and philosophy which lends itself to stability and support, as much as it does to innovation. So I think the Java comparison is a perfect suit and we’d be very lucky to have that kind of a comparison fullfilled on Meteor’s end.

2 Likes
311

You can overwork an analogy.

Java is language.

Meteor is a platform built on the Javascript language.

I don’t know of Framewor in Java quiet like Meteor, perhaps GWT :stuck_out_tongue: or Swing

1 Like
312

If I could like this more than once I would

313

Actually, java (jvm) is becoming a platform for polyglot applications with direct support for javascript, scala, groovy, ruby and many more. The gist is, a “technology” that targets enterprises should have a set of business-oriented qualities apart from those that are technical.

2 Likes
314

Nathan, it seems like you haven’t actually used React. And yes, including CSS is the next step a lot of React users have started to do.

Christian

2 Likes
315
4 Likes
316

Yes, you are absolutely right .However, the context or the “underlying purpose” as mentioned correctly

Let me give a simple example of the gloominess surrounding Meteor at this moment. Currently, when we build a meteor app, it also runs seamlessly as a native Android/IOS app. This magic is mainly Phonegap and thankfully MDG utilized it for building (and delivering) the native Android/IOS apps with a simple meteor build android command. Meteor till now has hidden the complexity of building native mobile apps with a sophisticated use of Phonegap as an abstraction layer which is being used under the hood by Meteor build system. Now imagine, one fine day, there’s a new thread by MDG with the title “We are releasing the next version of Meteor and Phonegap support would be deprecated since it’s old now and has got some limitations”. The nightmare begins. Now if we would like to continue delivering our Meteor based mobile app as well; we have to hire or retrain Android/IOS engineers.

Such unpleasant surprises are not taken very well by big companies; hence, they tend to stay out of any language/framework/stack/platform or anything which does not promise some assurance of supporting existing solutions for a long term. Even start-ups wouldn’t have the budget in this case to hire/reskill on Android/IOS.

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.

6 Likes
317

@rohanray I think we are kind of saying the same thing. Basically,
Meteor has make clever choices - on whatever front they may be - that
they can stick with for at least a few years and then some (for
migrations) otherwise it is not an enteprise platform. Now that may be
fine for a lot of people/companies, it just is not for the enterprise
apps that enterprises require.

3 Likes
318

@serkandurusoy Could not agree more! Let’s hope MDG understands this concern before it’s too late. I am confident MDG will make the right decision and also shed some light on our concerns.

1 Like
319

Yep, even though it is a bet I do bet that they will deliver.

321

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.

9 Likes
322

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.

5 Likes