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.
What I need to know is not whether React is better than Blaze, but what is MDG’s choice for the future.
Let’s don’t fool ourselves: we can all switch to React if we need to. The only question is about the switching benefit-cost ratio, which is all about MDG’s vision, leadership, commitment and dedicated resources.
I agree with the post author. MDG has to start making investment into Blaze or else it is a dead framework. Blaze is a part of meteor and without it Meteor will lose its shine. I think MDG should look at projects like Blaze components, flow-components or sideburns to work on Blaze 2 and come clean on there plans.
There are many who would disagree with that. Meteor is so much more than just Blaze. I think the 1.2 release just goes to show that they’ve moved towards de-coupling the template system from the core, so that people can remove Blaze entirely and use something else if they so desire.
I think people are panicking for no reason. No one ever said they were dropping Blaze. I’m sure they’ll continue to invest time into maintaining it as long as there are developers who using it.
I think every developer has different needs and should be able to decide by himself, what he wants to use. However, I’ve moved from PHP/Laravel to Meteor, because Meteor presented itself as easy JS framework, which delivers fast results. Blaze is one of the Meteor things that I really like, because it let’s me easy add reactivity to my HTML templates, while having a clean syntax (a little bit like Laravel’s Blade).
I’m relatively new in the JS world, so maybe I’ve a small point of view in that case, but Blaze was one of the main reasons, why I’ve switched from Laravel to Meteor. When people say “use React or Angular”, because it is maintained by a larger community, we should ask ourselves, why we should use Meteor in the future? Maybe there will be some new backend frameworks in the coming 1-2 years, that’ll have a better performance than Meteor. Why I shouldn’t use one of that and add seperate UI frameworks like Angular or React to it?
In my opinion, a framework lives by the combination of it’s features, and Blaze is one of Meteors. Stopping the development, because there are alternatives is the wrong way, because there will be alternatives all the time. In fact, Blaze works fine with Meteor, and I would use a full supported template engine rather than one, that isn’t fully supported.
// Edit: I dont’ say, that MDG should invest all the time in it’s own templating engine. As another guy already said, it would be a great, if we could combine the benefits of Blaze with Reacts core, f.e. using Blaze’s easy syntax and structure in our templates, while having React running in the background. But then that way should be fully supported with the rest of Meteors components.
The flaw of blaze is that it doesnt handle states and communication between templates nearly as well as react. Otherwise it is a perfect templating system.
But guess what, if you improve those aspects you will just be chasing react. And with a dedicated community ( 7000 people active in react slack group) blaze can never catch up to react. It is true for all other templating systems out there.
Everyone is switching to react and for good reasons. We are no longer building templates. We are building applications. We need component systems that handles states remarkably well.
What meteor need right now is focus, not trying to juggle 5 balls at the same time. The best about meteor is DDP and data-sync features. Make that the best tool for server-client communication is what they should focus on. And i argue that make meter backend pluggable with other database is the real road to maximize its potential.
P.S Someone is building the bridge between react and hardware.
It’s important for MDG to observe new trends and take the best bits from them the enhance Meteor - this is the whole reason why I started with Meteor - I want to beleive that a bunch of people cleverer than I am are going to sift the wheat from the chaf, create ‘the best’ platform and not abandon those principles for a flavour-of-the-month concept. I’m tired of people starting things and not finishing them - i think a large proportion of the developer community have ADDH!
If people want to use React then let them get on with it elsewhere, just concentrate on developing a better all-round product. I think a lot of people started with Meteor becuase they wanted a full-stack in one language - we have that, lets build on and and not get too demanding of it.
The problem with React is that behind the new and powerful front end paradigm, all of the suggested backend specifications are in a high state of flux. Take flux itself for example: there are literally more implementations currently available then Back to the Future references.
How does one chose from that soup the right implementation for their application idea? That’s where meteor can shine, for it acts not just as a RAD platform but a very viable replacement for the flux soup. Replace GetInitialState with GetMeteorState and you’re off to the races. A full React stack from top to bottom, ready to go.
Meteor needs to spend their money and resources making the database layer as pluggable as the templating layer currently is. Not chasing their tail into niche oblivion by wasting valuable resources on yet another antiquated templating technology. Sorry, but Blaze just needs to fizzle out.
If they can pull that off and then market Meteor to the React crowd as a perfect compliment and full stack solution, then it will take off like a rocket. If they don’t, then it will never be more than a niche community, forever small enough where everybody knows each other by name and the most money to be made is by selling products and tutorials to others in the same niche community.
At one time Unity3d was in the same boat. A small niche gamedev community that ran only on Macintosh. When they announced they were changing course and releasing a Windows client, there appeared threads exactly like this one.
Walls of text predicting doom and gloom. This wasn’t what Unity was supposed to be! This isn’t what you promised on your webpage! Unity will die because I will leave! Well, those walls of text were wrong, just like the ones in this thread. They now dominate the gamedev world on and off of mobile.
If Meteor ignores the foot-stompers and walls of text and chases the sun, then they truly can position themselves to dominate.
screw and nail some time can replace each other, sometime cannot. Arguing which framework is better is a faulty argument, which I think it is totally depending on the use case. However, I do agree MDG should balance their focus on both, so developers from both sides can do their best job without having the unnecessary pressure that come from the other side
Meteor is so much more than just Blaze. I think the 1.2 release just goes to show that they’ve moved towards de-coupling the template system from the core, so that people can remove Blaze entirely and use something else if they so desire.