TL;DR: I think the best thing to do is probably build Blaze 2.0 on top of the React rendering system to get a nice developer experience while taking advantage of new tech like React Native and the React component ecosystem.
where we know that we get to work with the familiar Blaze api’s and spacebars templating, wether or not it is react under the hood, and that we’ll get improvement both on the engine and the api, it would be bliss for a large base of developers.
Hype, wether it would stand the test of time, or not, will always be vocal and I think @mitar is spot on when he raises that question.
Where we stand now, we know, based on work by both @mitar and @arunoda, Blaze can be improved upon. But the nature of those improvements being way too central - as in belonging to core - creates a messy - as in hard to make a decision - situation.
I do appreciate @sashko’s thorough post, but unless it is an official position with viable actionable items, it is unfortunately not sufficient in calming down concerns such as this one.
React sure does have great advantages. But so does Blaze with its increadible simplicity. Perhaps if React were JS done in HTML rather than HTML done in JS, it would be easier to transition one’s mindset, especially those of the designers’ who can fairly easily pick up the spacebars syntax but are driven away by that of React’s.
Anyway, whatever it may be, I do hope we get an official, actionable response.
Gonna work with @debergalis to see what official/actionable items we can put on the table here in the next few days.
One thing is for sure for sure - it would be insanity for Meteor to do something that drops a huge majority of the current users on the floor. That means that whatever the next steps are, they will surely (regardless of the actual technology involved) involve a smooth transition path from what people are doing right now. It seems to me that this fact can be derived independently of everything else.
My goal with the long post above was to lay down some facts that are, in some sense, not reliant on any MDG decision making - they are just realities about the state of the world at the moment.
I think this is completely normal. There are always people who are trying out new things. And this is great. This is how you move things further. This is how ecosystem breaths.
But how ecosystem lives is that it has some stable base. So even if decision is to move to React, MDG should still invest at least 3 years of continued support (and improvements) for Blaze before stopping putting resources in it, for example. This is what stability means. Not that “let’s put resources into React” and now forget about Blaze. 1.0 version does not mean “we will not modify it anymore”, but also “we will continue investing resources into the API we made”.
While react support is great for innovators and maybe early adopters, MDG should cater also (to a larger) early and late majority who moved and are using Meteor because they thought things are stable and Blaze is here to stay. If you cut that community off now, and focus on innovators and early adopters only, then you are disappointing quite some people. Those who are not innovators and early adopters, but prefer stability and tested out solutions.
Yes, innovators and early adopters will be those which is good to provide tools for, to see what they can make. But you should still continue supporting others as well. Not just cut them off. This really bring loss of trust into the project. Not everyone wants to be on cutting edge. Many simply do not have time or resources to be. Once you convince your company that this is something your product should be based on and you work for a year on that, the last thing your boss wants to hear is, oh, they decided to change and stop supporting Blaze. That our bug or pull request we made will never be merged in. Because everyone else is moving to React. Everyone else might, but we are stuck with Blaze. This is why we chose Meteor in the first place and not some other technology.
That means that whatever the next steps are, they will surely (regardless of the actual technology involved) involve a smooth transition path from what people are doing right now.
I do not think transition is really possible because there will always be things which are possible in Blaze and not possible in React and you will have to drop some stuff or reimplement them.
I think a better approach is to continue supporting Blaze as it is and then leave to the community to decide through time by what they use. Maybe through time number of users of Blaze will be so low, that you can then remove it from core and leave to community to continue maintaining it.
So instead of trying to morph Blaze into React, a better approach is to keep Blaze and make it shine in areas for which is good (easy of use, simplicity, having a different reactivity model, interoperability with external DOM changes), while React does the same.
What about React/Angular2 native, built-in React/Angular2 browser debugging tools, etc? While we might be able to “keep Blaze”, it is already far behind other options in those dimensions. Who’s going to build the Chrome extension for debugging Blaze?
I think perhaps the recent focus on React is what turns the discussion to hype, but it applies just as well to Angular/Angular2, which are far and away more popular than any other option in the space.
100x this. Thank you for speaking up and putting this in writing.
To the extent that I’m hired by healthcare professionals and small businesses to deal with what they perceive as ‘tech heads’, and to speak in these forums on their behalf as a sort of lobbyist, I have to agree on behalf of a few dozen of those ‘quieter developers’ who aren’t regular contributors here.
From what we thought we were buying into 3 years ago during v0.5 days, and where we are now… well, I’m going to be generous by simply saying it’s been two steps forward and one step back the entire way. But fiasco may be appropriate also. (I’ve seen at least one project scrapped after over $100K was put into it’s development, partially related to MDG not accepting a PR related to the accounts management MongoId generation issue. These stability issues are costing some of my clients real money.)
Now that has been said, I’ll also say that I don’t think all is lost, and I think we’re very close to the end of the tunnel, and that all the pieces are in place to get the stability back into the stack (even if it’s been a year or two of wandering in the wilderness). peerlibrary:meteor-packages goes a long way to being able to create management pages for Release Tracks. And we just published the first release of clinical@METEOR to provide a stable, audited base for people building healthcare apps. I’m now excited about the prospect of redesigning the clinical.meteor.com Roadmap to use Mitar’s meteor-packages API. So all that is heading in the right direction; and I’m mollified and optimistic that things are falling into place.
However, I(we) do have quite a few questions at this point. In no particular order….
Are Release Tracks an officially sanctioned solution for building audited/stable ‘distros’ of Meteor? (They were vaguely communicated as such last year; but there’s not been much movement since.)
What is the monetization plan around Atmosphere?
Are we going to be able to rely on the Meteor PackageServer (aka Atmosphere) if we build out release-track specific functionality with the PackageServer API?
There were monetization plans around Atmosphere at some point in time. Are we going to billed a Pay to Play fee at some point in the future if we build on the PackageServer API?
What’s the status of tags and language fields on the Package.describe() API?
Will MDG consider PRs if we have needs around the Package API?
Are their any plans around incorporating Sideburns as a bridge between Blaze and React?
Are their any plans for auditing/migration tools using the Sideburns bridge?
What plans does MDG have for long term support of Meteor 1.0.3?
Are we going to get 2 year stable commitments to any release, like other open-source projects provide?
How does maintenance of a 1.0.3 stable-release relate to best-practices documentation vis-a-vis React integration?
If you could maybe also ask about some of those items, that would be real helpful for those of us who thought we were buying into a stable platform based on Blaze, rather than a bleeding-edge platform based on React. I’m actually optimistic that there’s going to be all sorts of benefits to running our own release track; and that it’s the solution to a lot of these problems. But it would be really great to have a little direction now that 1.2 is out.
ps. We’re looking at incorporating BlazeComponents into ClinicalMeteor. Still sorting out the CS/JS issues; but otherwise, everything that Mitar says is spot on, and applicable to our concerns. It’s very popular among the healthcare community to use higher-level languages to get first-drafts completed… lots of the prototypes we get asked to look over are done in Coffeescript, Jade, Stylus, etc. by local IT admins and analysts. They’re on the other end of the abstraction spectrum away from React.
Oh, that would be us with our Atom extensions for Blaze. Atom is built in Chrome. We have debugging tools, code highlighters, refactoring tools, Nightwatch/SpaceJam… and all of it is around Blaze.
Are they open source and/or publicized? I’ve never heard of these and I’m pretty sure I’ve been creeping on the forums since they started. These tools would be very valuable for the Blaze community!
I don’t think, Meteor is so mature to offer you LTS support. Lets take Laravel release - you can clearly see, there is LTS for 3 years. It has everything in core for you - router, ORM for a lot of DBs, validation, view layer, etc. So, you can come to your boss and tell him, this framework is safe to use for the next 2-3 or more years.
Until there will be such notes from MDG, you can’t expect LTS for any components.
You can expect that after half a year you will need to rebuild your app if you want to use the newest Meteor version and community stuff. Take the Iron Router - now it is dead, no one says it, but it is clear that it has no future. So you already need to transfer your routes, move auth and subs to template layer.
Blaze is working fine for a lot of people now, so they can use Meteor 1.2 with blaze for the next 1-2 years, it will work the same.
If you want to follow the early adopters/majority - switch to React now and use it in your projects as its future is already brighter (chrome tools, React Native, full Webstorm support, huge community not only in Meteor).
This is the choice and decisions you need to make before even starting to build apps with Meteor.
Instead of paragraph after paragraph of fear, gnashing of teeth and searching google images for comical charts that undermine their own arguments, time would have been better spent reading some of the 99e^99 React tutorials.
The cold hard reality is Blaze is essentially deprecated and only there for legacy compatibility. The world is moving on. It’s just not worth paying a team of developers to try and bring it up to par.
If you want to keep Blaze that badly, then make commits to the repo and maintain it yourself. Just make sure the dumb innovators can still remove it and replace it with something better.
I will also ask you not to use React in Blaze / Blaze in React or any other hack stuff. And stop promoting it. You actually have no benefit from it and make everything even worse.
Just make sure everything is in React and remove Blaze, the transferring is really simple. Future devs and package users will thank you.
Who is to build anything for Meteor, if there is no chance of things are changing to quickly and there is no feeling that it is worth investing things?
Have you seen Meteor.toys? It has a simple debugger for Blaze.
And in fact I was planing to do one as the next step after Blaze Components. But now I am unsure.
If all smaller startups would always just respond to what big companies do, then there would not be much innovation in smaller startups. Argument “bigger has more resources” is true, but smaller can find some advantage. And what is Meteor’s main advantage? That is the whole stack! An opinionated, whole stack you can bet on. As a whole. That it will be maintained. That you know that the community is building around. It might not be perfect in all cases (data is only MongoDB, only top-level fields are merged, no OT, no backpressure on publish functions, rendering is Blaze, etc.) but it is good enough in many cases. For every one of those you can find better solutions, but this is not what Meteor is about. If it would be, then you should immediately stop developing Minimongo and stop MongoDB support and implement SQL++. For publish you should use something which supports back pressure.
Why Meteor is attractive is because it is not a bunch of open source node.js projects I put together without knowing for each of those who is maintaining them and how long they will be maintaining them, but you have a dedicated team of technology leaders who you know will make sure that the platform is stable and maintain all its pieces.
So yes, by leading the way others can follow. And develop debugging tools. If you yourself are unsure, then this is a self-fulfilling prophecy. Yes, there are no debugging tools. So let’s not develop it further. So that is why there are no debugging tools.
Being a programmer composition with a component paradigm just feels natural. I can actually comprehend what it’s doing, whereas most of the html-centric templating engines feel like drawing in crayon.
I’m surprised it didn’t appear earlier tbh. Most all game engines moved to a component paradigm back around 2007-2008. It’s not like it’s new tech.
Yes and no. The Atom package meteor-api and the StarryNight utility have been converging for quite a while. One of the major ideas behind StarryNight was for it to be a command line utility with testing, scaffolding, and refactoring tools that could be launched from Atom.
Or rather, we’ve been building StarryNight with the idea of having a GUI front-end for it in Atom. This has been a design goal for the past 6 months or so, since we split from Velocity. It gets back to the whole difference in architectural preference, re: testrunner available as a package, vs testrunner available as a separate node utility.
During the hackathon a couple of weeks ago, we finally got around to forking the meteor-helpers package - which had all the UI components for launching external commands and displaying output in Atom - and managed to create a launcher for StarryNight commands. Here’s a screenshot of it with integrated test runner…
So, that’s been in the works, and this is probably the first time I’ve publicized it at all. We’re currently adding in the menu options for refactoring, scaffolding, etc… but the difficult part of systems integration is mostly all figured out, and it’s just a matter of copy-pasting commands into menu GUI options. When the Clinical Track gets officially released this December, we’re sort of planning to include a full Atom based IDE with it (for Blaze).
(Keep in mind that it was I who did the initial draft of what eventually got incorporated into Webstorm. You can trace the typos in the templates to what was in the Cookbook. Ooops. This isn’t the first time I’ve cobbled together an IDE for Meteor; and I ditched Webstorm because it wasn’t isomorphic and was written in Java. So, take that for whatever it’s worth. The working project name for this rewrite has been something along the lines of ‘ComponentFactory’.)
Edit: also keep in mind that StarryNight is simply a placeholder for commands and functionality that we wanted to get into Meteor, but for which we gave up trying to submit PRs for. Now that customizing the meteor-tool allows us to register commands, we’ll probably also be moving the StarryNight commands into the clinical@METEOR track. Which is to say that the starrynight-helper and meteor-helper packages could be extended to support the entire Meteor tool command palette.
I love Blaze, and will continue to use it. I’m using it in 2 industrial apps in production (will not be changing anytime soon), and IMO the only thing it needs is better rendering performance. The data context/scoping model has not been an obstacle to me.
We all know that. What the original post inquiries is the future of Blaze innovation.
artsy folk in lumberjack costumes
You clearly have no understanding of what workflows designers have or how and when they are at the top of their productivity, let alone any appreciation for those people who got different sets of talents and skills than you do.
another wall of text at MDG because you lack the initiative to learn something new.
Do you have any idea whatsoever who @mitar is and what he does for a living and the kind of contribution he’s brought into this community?
Anyway let’s please keep this discussion around what the original topic actually suggests/asks and actually read what people have written before jumping our guns.
