Oops I deleted the post by mistake and can’t seem to undo it. Pasting it below…
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!
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.
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
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.
I really like what @timbrandinis doing with Blaze React, and I do believe that trying to keep backwards compatibility is the right way forward, strangely enough.
@gabreilengel Yes we are definitely aware of this - it seems very close to what we want! The main thing I see is we are not entirely sure if the rt-if and rt-repeat prefixed-attribute syntax is what we eventually want. It feels similar to Angular/Vue, but for this specific project, a more familiar {{#each}} syntax will be great for current Blaze users.
Well, Adobe dropped Flash and Microsoft dropped Silverlight and in practice dropped all .Net languages except for C#. Google dropped Wave, Google Glass etc. Those big companies drop products with large or passionate communities all the time.
This is a pain point for our large Blaze1 codebase. We use a range of DOM mutating plugins. I.e:
We use lots of complex, chained velocity.js animations
isotope
selectize
jquery-textcomplete
scotch-panels
materialize-css (tabs, collasibles, tooltips)
I’m sure there are more i’m missing.
Moving to Blaze2/React wouldn’t bother me if I knew that we can migrate from Blaze to React whilst preserving compatibility with the non-React ecosystem of DOM mutating plugins. For my team this is Blaze1’s greatest strength over React
A counter argument here is that the React community are wrapping/migrating/re-creating such plugins - that is a great argument in theory, but we are a lean start-up with very limited time/capital. We want to build out our product, not burn time swapping technology.
If you are not making blaze 2 backwards with blaze 1 then you are essentially deprecating blaze. Why anyone would then pickup blaze 2 is beyond me because no one wants to rewrite a bunch of old code again when you decide to deprecate blaze 2 a year or two down the road because a few decisions you made now have better solutions.
You have basically made your decision that react is the future. Even Wordpress just remade itself around react. If blaze 2 isn’t backwards compatible then what’s the point of it? You lose a big resource (atmosphere). Blaze 1 isn’t perfect but to make larger projects more maintainable you are just going to throw away thousands of packages or hope that they all get rewritten. Well if they need to be rewritten then isn’t it better they get rewritten in react rather than blaze 2 for the other features you pickup like compatibility with npm. I wouldn’t want to even think about all those projects people have made that need to be rewritten.
You need to start thinking of stability as more important than some of these other things. The only 2 reasons I can see to make blaze 2 is to bring everyone’s legacy code into react. That’s a very good reason to make blaze 2. The other reason to make blaze 2 is because it’s much simpler for smaller projects. Smaller projects are what 95% of projects are. If you are building something you think will be huge you should be doing it in react and not blaze or blaze 2 anyway. @faceyspacey has the right idea about what blaze 2 should be.
The way I look at development is you never really know what needs to be optimized until after you have some success. If your app has 5 users then what’s important is how quick were you are able to create it… (To minimize resources expended on something unsuccessful.) On the other hand if you made bad architecture decisions but you have a successful app then don’t worry because you will have the resources to fix the problems and you will know what parts of your code are actually problems…
Yes, this might potentially become one of the major roadblocks for some projects to migrate from Blaze1 to a React-based Blaze2. From my own experience, these dom-manipulating libraries are not incompatible per se, but need to be used in a way that plays well with the React lifecycle.
But, whether it’s worth upgrading a particular project to React/Blaze2, would be an ROI decision that people would have to make according to their project situations. What’s more important is that as long as Blaze1 doesn’t start breaking suddenly, people would have the choice, and not forced to upgrade.
For new projects, it’s totally possible to use jQuery plugins with React (you can generally find alternatives, or fix the reasons for incompatibility). And with the popularity of React, I’m seeing more and more jQuery plugin authors (at least the popular ones) ensuring that their plugins don’t break with React.
Lastly, once I started appreciating how React works, I feel like wanting to avoid jQuery plugins if feasible. Not for compatibility reasons, but just knowing that doing things the React way is so much better! It obviously depends on the ROI. E.g., I’m using Semantic UI and Froala editor (both jQuery-based) in my current project, and React for everything else.
Meteor is not an open source project in a modern sense. See this definition (from here):
Open source refers to any program whose source code is made available for use or modification as users or other developers see fit. Open source software is usually developed as a public collaboration and made freely available.
@Steve is that sarcasm or do you actually consider meteor not open source?
from what I gather it claims to be open source but definitely fails needs a lot of improvement on the public collaboration front
@serkandurusoy, they don’t need “improvement”, they need a cultural change. They need to choose whether to be closed or open. Staying in-between won’t work much longer.
I hope they’ll choose the open side, hire an experienced open source release manager, set up an open source governance model, and leverage, at last, the amazing people we got here.
), 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!
And it is much more intuitive with deeper integration than “getMeteorData”
I trust MDG to make the right decisions and totally get why they’re building Blaze 2 on top of React 