How about hiring more people?
1 Like
we,our company from Australia, love meteor. However I feel meteor is fast becoming an erratic unstable moving target. One week you happy building your app with blaze next week you are porting every thing to a new templating language. Don’t get me wrong I’m all for the development of the meteor ecosystem but on this particular issue I strongly feel blaze should be blaze and react should be react
15 Likes
After reading all this thread I cameout with one simple request for @gschmidt:
Dear Geoff, please, make public statment that with moving into React based ‘Blaze2’ MDG will make maximum effort for easy migration path for both, our apps and for popular community packages.
.
Now I’d like to help to put my next 2ct and answer @evanyou questions.
My designer can work with it. It’s almost like HTML.
Also I can use it with Jade, which I prefer when working without designer.
Here I agree with @slava:
" The sub-expressions syntax was very lacking for a long time. Having to create a helper for any trivial or complicated operation felt unnecessary. Also data context was a very confusing concept. Often times templates relied too much on what data context should look like and the templates became less reusable as the shape of the data was defined in how template is using the data context."
Possibility to render template directly from .js for small components.
Data and props are isolated. I really missed possibility to put properties for components/templates in Blaze+Spacebars solution. I event needed to create my own hacky solution for that.
- No external templates for layouts and components with more markup.
- My designer can’t work with it.
- Lack of
ifandforstatements. - Can’t use Jade.
5 Likes
Here’s a big question: will this layer over React be targeted for Meteor or tools like Webpack/Babel? With the latter, it opens it up to a bigger community and markets Meteor to them. Plus, people would be more invested in it knowing that it would have benefit outside of the Meteor world (universe?).
9 Likes
I just built a core requirement of “deep tracker integration” :
It’s a mixin called TrackerReact.
It eliminates the need for getMeteorData, upgrading access to reactive data sources to the “method level.” Simply define a method on your react component that uses a reactive dependency and the component will stay automatically up to date just like Blaze!
Anyway I’m starting to release things from the Sideburns project one by one to appease you all. There’s a lot of good stuff around the corner, some old, some new, some old in new form. But in addition to making the transition easier (and very likely 100% automatic), I’m gonna release a lot of specialized features that only could exist for React in a Meteor world. TrackerReact is one such goody.
Stay tuned for more tools that bridge the gap from blaze to react.
Ps. Try to break TrackerReact. It’s brand new and needs to be battle tested through any unique scenarios.
11 Likes
Awesome. If Meteor Components, ViewModel, AutoForms, etc. Just Works™ with SideBurns + Webpack + the original Blaze and Blaze 2 doesn’t, I feel Blaze 2 should be named something else and Blaze continue its path of evolution and not revolution.
Meteor 1.0 was a celebration of stability. That should be honored.
Kudos!
2 Likes
Thank you for taking the time to come up with an official post.
However, for us, even with 60k LOC already written for our startup, your official stance means this: scrap all this Meteor & isomorphic JS nonsense ( yeah, JSX is not really isomorphic, ok?), and just spend those two months that you’d dedicate to switching to React to actually re-write our app in something reliable. Like Ruby on Rails. What a waste of time and excitement…
14 Likes
Actually, what a storm in a teacup this really is. This should teach us all a good lesson.
Build the backend essentials of your app on proven, reliable open source software (i.e. PostgreSQL, Java libraries, Express if you want JS), pick up something rock-solid and reliable (again) for your front end, like Backbone, and keep only the experiments and prototypes for non-reliable environments and frameworks (Meteor).
7 Likes
Why do we need to give every method of a component reactive sources? Seems like it goes against how React works.
Nah G, I think you’re reading into it too much. They’re not saying use React, they’re saying they’ll render to React. The world of JS frameworks has always been evolving almost as fast as RNA in Viruses. Even with Rails you’d want a JS front end and would fast the same issue. Angular 1 is dead. I have old React code that breaks using the latest branch.
My point is that they shouldn’t abandon Blaze support even if rendering to React (probably a good idea in the long run) and even if they start a different front end framework. At least not for a couple years.
Great packages like Meteor Components and ViewModel can keep adding features on Blaze and perhaps slowly expand to be Blaze 2 compatible.
A Blaze rendering to React might even be a boon to the React community since they’ll have more options in terms of code/template separation, etc.
3 Likes
My 2 cents as a developer:
-
***We don’t need YAFL (Yet Another F’ing Language)***:
Designers barely know how to handle HTML and CSS, don’t ask them to handle HTML and CSS inside JS. This is the worst part of React IMO. Separation of Concern is key. Let’s keep it that way, and that’s where Blaze is good with HTML/CSS templates separate from code. -
I have been working with Angular for a while and when I discovered Meteor, I became a big fan, I’ve been promoting it and teaching it to others… but in my project I have been more and more frustrated with it: Meteor is great to get started on simple apps, with simple collections, but as soon as one tries to get into ‘real-life’ application, Core can’t handle it.
One would say, “yes but then that’s where the community comes into play and there are 2 millions packages available to do the 'other jobs”. Yeah, well, sure… but I have spent so many hours trying to make a package work for my use case, only to figure out further down the road that it doesn’t handle another feature I want to implement.
Take easy-search, publishCounts, or publishComposite. Each of these packages are great on their own for their designed purpose, quick to implement… but they’re not compatible with each other.
So after rewriting code once, twice, three times to try to make all this work together, I ended up rewriting everything myself.
Sure I learned a lot, but hell, this is not what I want to be doing all the time…
I had to do another rewrite to integrate FlowRouter in place of Iron-Router, because of the infamous re-rendering issues, and now you’re telling me I’m going to have to rewrite my templates?
You guys need a better way to distribute packages, and a better path to integrate the popular ones into core, and making sure they all work together. Community effort, yes. Bundle of eclectic packages, NO!
I can’t be spending my time ‘trying things out’ to see what works best, out of dozens of packages and hundreds of forks. Actually if there are many forks, it is a pretty bad sign that a package doesn’t do it right.
Angular sucks, it’s slow and takes much more code to do simple things, but at least it’s consistent, and once you get the gist of it you’re moving.
With Meteor I feel like I’m constantly re-writing the same code: it’s simpler code maybe but in the end I probably wrote as many lines as if I was using Angular! That is far from the original promise of Meteor, unfortunately.
16 Likes
Fortunately Ractive can be used with Meteor quite easily. I’m using it already for +1 year. Mix of Blaze and Ractive is really good for my projects. Good point @miro !
I can’t say enough, it is a shame to see Blaze go. Investing 2 years with Meteor, I fell in love with the way Blaze worked and how easy and productive it was to build apps “THE METEOR WAY”.
With Blaze you pretty much an any library(jQuery or not) and get it working in your app, a probable cause for the rapid increase in no. of community built packages for use in the Meteor ecosystem. Feel a bit stranded now hearing about deprecation of Blaze and forced to look into alternative. I have no grudge with React, I do like the way it works but its not Blaze. I started porting a small app to React started loving the way it works, but then frustration began started to rise knowing you just can’t take a library(that manipulates DOM) that does ‘X’ straight from the web and use it with React, since React freaks out when something else changes DOM. To do something similar you need to recode it “The React way” to get it working with React. It was a setback and I decided to continue using Blaze. Guess what now it will be deprecated!
Its a shame to know that MDG, instead of improving Blaze decided the easy way to just take React and build over it.
12 Likes
you don’t have to. there is several ways to block it. Click the link and read the readme.
That said, this is exactly what getMeteorData is doing, except in more than one frozen method. It’s called “sideways loading data”, and according to the React Team it’s not against React principles: https://github.com/facebook/react/issues/3398
It’s the only way to get data into components from the outside world, think about it. It’s what Relay is doing with container components. When you use Redux or Alt, you’re bringing in data from the outside world and assigning it to state. In short, it doesn’t have to be restricted to just the state key, just as getMeteorData itself uses another key: data.
In all these scenarios, the reality is data is being “sideways loaded.” It doesn’t just come from the very top root component. That’s like never the case.
Anyway, there will be more ways to control what methods do what in the future, as this mixin joins a few other mixins I’m working on as part of a complete component package. I.e. there’s an events mixin, autorun/subscriptions, etc.
No, they aren’t brother man:
I’m saying that, if you look into my work with Sideburns. MDG apparently aint about that life right now lol. They likely haven’t looked into it much, and made this announcement cuz they knew they had to say something. But basically they dont know what they’re talkin about. They currently think no matter we’ll have to port our old code to the React world, and there is no way to automate it so you can just switch out the render. Which is untrue.
Either way, don’t get it twisted, they didn’t just say this is gonna be some easy thing where you can just switch out the renderer. But all will be good cuz community developers are handling. Hit me if you wanna chip in. james@faceyspacey.com
3 Likes
Well, not entirely. Getting your point, but when some of the important packages we’re using will be abandoned (due to lack of Blaze support), then that’ll be it.
If I was supposed to care about JS for front end only… really, that’s easy business. jQuery alone will do it if in a rush. But here we are talking about wiring up the front-end to data. If Meteor is going to shift this under our feet all the time, then separation is the best way to go. And when it’s only about the façade, the JS framewework is easy to change
1 Like
“The primary goal of this project is to lower the barrier of adopting and migrating to React.”
This sounds more like a React sub-project not a Meteor project. The beginning to make Meteor part of React?
1 Like
This is such an interesting discussion because this strongest asset, and the whole way that Meteor is a full stack self contained framework, is also it’s greatest weakness. This is the reason that loads of people are not using Meteor and the reason that Meteor is finding it so difficult (or even arguably impossible) to keep up with developments in the wider javascript community.
So the question is really… which is better: a full stack self contained and fairly easy to use out of the box framework which is many months behind the curve but still totally works; or a library which can perform important functions really well and can plug into anything bleeding edge we like?
So the debate about React or Angular is sort of irrelevant in the longer term. Both might disappear or more likely be changed fundamentally in some way. Next year we might all suddenly want to use cycle.js for example because it seems so great. Do we want Meteor to be able to accommodate that instantly? If someone writes a brilliant new version of Webpack, do we want to be able to use it straight away?
5 Likes
As @slava mentioned above, Blaze is probably the leader in number of open bugs on GitHub among all of the parts of Meteor. So in some sense, switching to React is both (1) getting closer to the cutting edge, and (2) replacing one of the more buggy parts of the system.
4 Likes