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.
+1. MDG has limited resources, and by embracing efforts by folks like @timbrandin, @faceyspacey, @mitar who are obviously very skilled coders and WANT to participate and WANT to fix the problem, if @evanyou
would work together with these folks instead of on his own chamber, I am sure the solution would rock!
And it would be a solution with several maintainers, thus hopefully more resilient than for example Iron Router was…
I think I said it before somewhere: Check out for example the Qt project. I spent many years in that context. Commercial company running it, but thanks to an open governance model it has truckloads of external people contributing.
It’s not mainly about better features, but more frequent releases. MDG should focus on design/consultation/arbitration/validation and let other do the time consuming work. In a matter of weeks we would have schema and router in core, and approved prototypes for alternative data and visualization layers.
Additional benefit for MDG: more time to work on Galaxy or whatever profitable features.
