I thought so mate. If you want to post that to the other thread and delete it here, I would back you up by deleting my response to yours and reposting on the other thread too. 
1 Like
Ah… Now I get it… You were asking on expanding on Ben Newman’s talk on webpack/commonjs. I was reacting to @casperandersen’s thoughts on webpack and if meteor will be able to surpass innovation in webpack or will they embrace webpack.
I’m really excited with where this is going… you can now use NPM modules in Meteor without Atmosphere package wrappers… but I can’t really switch to React as of now given that Meteor 1.3 hasn’t fixed the transpiling import statements in jsx files from the react jsx package.
But the problem here also is… with the advent of import statements in Meteor 1.3, Blaze will sort of be killed in the process because there’s no clear way on how to “import” html files. I mean, if later on we will be using NPM modules, Meteor packages might be obsolete in the process… but I still need a form of control for the file loading mechanism, especially html files if we are still going to use Blaze, without being constrained on the folder structure.
2 Likes
Do you think this will be corrected with 1.3 goes live? What are the conditions (going with webpack for example) in which you will not be able to go with React in 1.3?
Will you expand on this more?
I am thinking in the context of webpack + react + babel.
For maybe about half a year or so(?)… it has been possible using webpack+react+babel to have hot module replacement in development mode in build systems using these technologies. HMR seems better than the current hot push reload in meteor, because it doesn’t reload the browser and it takes much less time for an update cycle in dev mode. Cases reducing from 45 seconds to 1.5 seconds is not unheard of. I understand this is possible thanks to babel and react, not webpack, but webpacks build system has made it easily available. Meteor using babel + react should also be able to do this without webpack, not sure this is possible with meteor + babel + blaze.
Code Splitting or Incremental Loading as referred to in meteor forums, and which could also be referred to as Conditional Loading (if user has permissions, or event, or route etc is triggered, or agent, or device matches…) allows us to only send the features we relevant, accessible or subscribed to by a user, keep the initial client thin which in larger saas applications is really nice, is using chunks, which webpack relatively makes easily available, compared to not possible at all with meteor without webpack or other facilitator(?)
In addition it should be worth mentioning SSR supporting proper SEO, is possible with React but not blaze.
My point being, these are killer features and innovation that could have happened in meteor or in another project in the wider javascript Node eco system. They happened elsewhere, and because Meteor previously had chosen a very opinionated bottle neck strategy which unless Meteor can always replicate, implement, enhance and extend in real time the innovation outside the Meteor community, would eventually leave us in the dust technologically. If that was the case, then Meteor wouldn’t be for javascript what Geoff Schmidt wanted it positioned, next to .net and java, but it would be a sidetracked sub par implementation where developers could only dream of code splitting, hmr “updates by injection”, ssr or at best have it half a year after the competition. And that would be a concern and a fear of lock-in which would be a hinderance to adoption, or should be.
However, with 1.3, modules, npm, it looks better. It is still to be seen, but it is good that it is being addressed.
And this also helps to address the other issue about skill set conditioning, which happens when developers are isolated from the general innovation, which is not just a matter of employability but also a matter of sourcing and recruiting new team members and developers with relevant skills, rather than a relatively more lengthy onboarding and training period.
It is possible to architect larger apps with blaze too, so I do not always agree with people saying blaze is a no go because of that. when people spend proper time and have experience to do proper structuring it can do a decent job. The bi-directional uni-directional difference between blaze and react does cause raise some interesting challenges, and we see mixins, composition approaches etc… a dominant pattern is yet to emerge, it is also interesting to see what comes out from the blaze react project with trackerreact etc…
my immediate (who knows what we want when we get this) wish list includes
- React and other NPM modules that should not requires no special meteor integration should be installed from npm, not atmosphere, and should integrate seamlessly with webpack when also added, which is still needed for HMR, Code Splitting, and other special loaders of interest. This also helps to ensure that we won’t fall behind with outdated versions of React not compatible with other packages we use from NPM etc.
Then we have HMR (in development at least), CODESPLITTING, SSR( for SEO), and better component design choices, things we have waited for years, and we can begin refining the stack. Promising times for Meteor land, despite the tremors. People who does not wish to invest in migation from Blaze can continue, but without the new tech innovation, and those who can invest can reap the benefits of innovation and get if not more, then at least Code Splitting, Incremental(Conditional?) Loading already now.
2 Likes
The application of @aadams is probably bigger than anything you’ve ever seen in the Meteor constellation, with more than 100 screens, and a lot of complexity.
Moreover, I’m sure that it’s much more than just “being lazy to spend $300K on porting it to React”; Let’s say that MDG didn’t try to kill Blaze, and that @aadams doesn’t have his company and application but is starting them today, I’m sure that he would prefer Blaze for its other advantages over React.
1 Like
I get it mate. I’d like to have code splitting with webpack for example. I like change for the better, especially when it doesn’t too compromise something we’ve worked so hard for.
But then again, all the great things you spoke about, all the great changes and innovations Meteor is preparing for … is not what some of us bought into.
It was the promise of tightly integration set of smarty chosen technologies (one per level of the stack) that work great together, allowed developers to ramp up quickly, and help us solve business/technical problems fast.
Maybe we were all a just a little naive for believing in that world, believing that that utopia could last somehow.
Now ostensibly MDG wants to throw that away in favor of a more open framework, where developers can plug and play different tech at each level of the stack. This can’t be as seamless as what we had in the past. It seems to me the tight integration we’re use to is almost impossible to achieve with the open approach.
If React/Angular2 makes a breaking change with its interoperability with Meteor, then Meteor will need to adjust. If [INSERT TECH AT EACH LEVEL OF THE STACK HERE] makes a breaking change with its interoperability with Meteor, then Meteor will need to adjust to keep up. But I’ll give it to them, this approach might be easier than building the tech at each stack level. This approach requires less innovation from MDG, maybe less expensive, requires less thinking, and is maybe less risky.
All the developers that took a chance on Meteor, invested our time and resources into learning Blaze and the special way Meteor interacted with Tracker and Blaze, the techniques of Meteor as a full stack development solution, that’s time wasted.
With React comes changes to Meteor to adjust to the React way of development. It will be a almost complete development technique change for us. No more Blaze, tentatively no more Tracker. And this is just the start. Next it will be GraphQL and all that will bring along with it.
I’m ready for the great new innovations going on outside the Meteor solution platform. I’m ready to have code-splitting capabilities.
I hope in the end this transition makes our lives easier. I hope we will still be able to build apps lightning fast. And I hope Meteor continues to be as accessible to new comers as it was yesterday.
I hope MDG thinks it shares some responsibility for this transition with the Meteor community, and I hope we get the transition support we need from MDG. I hope for those on Blaze the transition is as seamless as possible. And I hope MDG listens to everyone in the Meteor community.
It’s too bad MDG seems to be focused so narrowly on Galaxy nothing has come from their camp in a couple of years now. It’s too bad that MDG seems no longer willing to take any chances on new tech of their own. Instead they are turning Meteor into a FB integration platform, and in so doing removing chances for innovation, ownership, accountability, and responsibility from the MDG. But I suppose Meteor was a means to an end anyhow, a cloud platform named Galaxy.
3 Likes
I would go to React fully with these conditions (at least for me):
- import statements will work in JSX based on ES2015 specs as well (I would be an import/export freak and doing away with almost all global variables)
- Be able to have full reactivity in React (I think the mixin has already have this)
- FlowRouter and Meteor can do server side rendering of JSX components.
Some optional add-ons:
- GraphQL reactivity (that would be a big plus
)
As for Blaze being killed… I remembered in https://github.com/meteor/meteor/blob/release-1.3/packages/modules/README.md#modular-application-structure it says there that:
that means, not all JS files will be evaluated and there would be one entry point to evaluate all JS files (if I understood it right).
And from the example at https://github.com/meteor/meteor/blob/release-1.3/packages/modules/README.md#modular-package-structure it is not clear how ES2015 can help in also loading/importing html Blaze template files. I mean, you can now create a build order using imports inside the client.js file and make it as an entry point with api.mainModule("client.js", "client") line… but it leaves the question: “should we still use api.addFiles” to evaluate and define the html files? If so, then you would now have two files to define the build order of your blaze templates: the client.js file (for all the JS files that you need to import), and the package.js files (for all the HTML files you need to define as the template)
If it is in JSX though, you will just need to put (I guess) it in the client.js file, use api.mainModule("client.js", "client") to make it as your starting point, and then import all the jsx files from there… The build order and import is easier…
As a plus, you can create npm packages with JSX and do away with Atmosphere packages for those components…
1 Like
MDG didn’t build React, but they DID BUILD Blaze. They built Blaze, integrated it with Meteor, and we had to learn it in order to develop with Meteor. It was inseparable from Meteor. Therefore they took ownership and responsibility for it. Now it’s MDG’s responsibility I believe to ween us off of it as smoothly and seamlessly as possible.
I’m calling for MDG to creating a upgrade path from Blaze 1 to React in support of the Meteor development community: Documentation, videos, presentations, best practices, forum answers (a special category for this), any tools that might make it easier, and general support.
4 Likes
Maybe we shouldn’t call Blaze deprecated. I’m using it in some places and still think it rocks. Its not perfect - sure - but neither is Angular 1, and I believe Angular 1 is also similarly abandoned.
Blaze can be a good, fast MVP solution. It only needs a bit of love to become a lot better. Mainly - incremental loading on the front-end, which is almost here with Meteor 1.3. Otherwise:
- its fast,
- the reactive updates perform well
- SSR is not a vital feature for applications
The main problem I and other’s have had with Blaze is that you have to push down a huge app on the first load. I think if that were solved, Blaze would have many good use cases.
16 Likes
ok, could you just please stop and let us run our meteor app without breaking changes for at least a year or two? I mean, i could barely apologies on behalf of you guys to my boss that the upgrade to 0.8 was painful as fuck, it took 2 weeks of not delivering ANY business value, and now THIS?! no, srsly no! This is more than just swapping out a lousy template engine with another lousy template engine, this is about having 2 kids at home that need food, and a mortgage to pay, where the hell do you guys think that corporate wants to pay me without delivering value to the customer?! They will consider Meteor (and thus, me) a liability instead of a asset.
You guys should really focus on trust here, cause having a yearly breaking change is not acceptable. Look a Django for its depreciation path, where you slowly evolve to a new version of something, instead of breaking the app leaving us, the soldiers at the front, before the managerial firing squad. Just leave it alone for a couple of years, and focus on and focus on your 900+ tickets on github, or the 99 open pull requests, instead of breaking stuff, again.
Sorry for being so salty, but this wil be the final straw for the meteor project at the company i work if this happens.
8 Likes
Can’t we all just go build cool stuff?
If you like Blaze, awesome; use that. It works today and will still work next year. You like Angular, great. You like React instead, great. Just pick one and build something people enjoy.
I’m positive everyone could have learned X framework with the amount of time spent in this thread.
React helps my large apps from crumbling and aligns with the functional methodology (which I enjoy) so I’ll pick that one. You should pick the one that makes you most productive/happy.
9 Likes
My proposal for how MDG should handle this whole situation:
- Keep Blaze around as an introductory, “training wheels” solution for smaller apps and quick prototypes. Don’t deprecate it, but make it clear what its downsides are (no code splitting, no SSR, etc.).
- Spend as little time as possible on it. Don’t introduce any major new features, maybe just try to get low-hanging fruits.
- Transfer control to the community. This can be a gradual process, leading to some kind of Blaze working group that’s independent from MDG.
- Recommend React as the “real” front-end solution for any serious production app.
- Do not waste time on a Blaze-React bridge or migration path. It’ll take up resource, and nobody will be happy with it since Blaze people just want to keep using Blaze, and React people are already using React.
12 Likes
What does the new user onboarding process look like in this world? Does the front page tutorial introduce you to Blaze, and then at the end you learn about React and it says “if you’re building a real app, use this instead?”
It just seems a bit awkward - I’m not convinced that it’s worth the time having a whole other framework just for training wheels.
5 Likes
Actually, in that world that’s something we’d need to figure out for Discover Meteor, too. One solution would be to start with Blaze, and then give people the option to switch to React in more advanced chapters.
I guess it all boils down to how much easier to learn Blaze really is compared to React. Obviously some things ({{#if}}, {{#each}}, for example) are much easier to do in Blaze, but is that enough to warrant keeping it as a first step? I don’t know yet…
3 Likes
As a Blaze person, I disagree, I’d be happy with a good bridge, allowing me to use Blaze awesomeness with React under the hood.
2 Likes
@sacha @sashko
I would propose that it makes more sense to have two versions of Meteor, you can never have both ways without making it mediocre. I think Meteor has an advantage to being the fastest prototyping SPA app in the world if you optimized for that.
Meteor Prototype Edition:
- Slow moving / frozen API
- Blaze templates
- MongoDB as the only database (instead of upcoming ones)
- Packages can be marked ‘approved’ so they just work and continue to work
- Everything is aimed at creation speed (insecure, autopublish, more stuff like this)
- Aimed at assembling leggos that are semi customizable (like accounts-ui)
- Rails style generator to make CRUD apps even faster (with standard layout)
Meteor
- Focuses on keeping up with the fast moving JS world
- Aims at keeping med/large apps maintainable yet easy to build
- Flexible view layers
- Flexible database layers
- no default insecure or autopublish packages
- Improved subscription (eg, declarative like Falcor/GraphQL)
This would kill two birds with one stone by essentially just freezing off updates to an agreed ‘version number’. Say Meteor 1.2 will be ‘official’ version. All packages could say ‘Meteor Prototype Edition approved’ and could have a special version tag.
Beginners and prototypers alike can benefit from no restrictions and can build very rapidly and both wouldn’t care about being up to date, secure, or maintainable. However, because it’s just a version constraint there’s nothing from stopping a user from removing insecure or adding React… it would just break out of the ‘Prototype Edition’.
Just my 0.02
Edit I just created a poll in this thread to see how the community feels about this.
6 Likes
This is a very dangerous decision to make.
- React itself will break the principle of simplicity. The paradigm that goes into easy templating will be distorted by an attempt to humor a loud group of non-Meteor developers. Don’t go against your own principles.
- React is in fact designed with only React in mind. Blaze is designed with Meteor in mind.
- There are people invested in Meteor based production apps. People spending money on working Meteor apps. How do you ever expect Meteor to be a viable option for production if you pull stunts like this. I’ve agitated for Meteor. I’ve heard so many comments of Meteor not being ready. Don’t give these people more power. There are projects that depends on Blaze. There are those of us that would like to see a Meteor-centric Blaze and continue using it. React will die in a year or two, like many did before, let’s not be the one community that died because of concesions. By trying to please everyone you’ll please no one.
7 Likes
I wrote my take on it in the poll thread:
avoids hurting existing blaze investments, allows for freedom for the innovators, and upgrade paths in between. heck multi entry points is possible with different learning curves.
Also
- using packages it should be fine. However, having docs for blaze, react, angular 1+2 is expected, whether they are MDG or community based, or a mix. What Urigo and friends do with Angular 1+2 shows it is not impossible.
2 Likes
I love Blaze as it is right now. The decision to have Blaze stay where it is and move forward with React seems promising.
I hope to see better Tracker-integration, like what @faceyspacey is doing, for React. I’m getting constant reruns and it’s been frustrating to the point where I’ve moved a couple of projects back to Blaze to have Tracker run correctly.
I think an important question is:
With the deprecation of Blaze, what is the future of Tracker?
6 Likes
I am also thinking about the same thing. I tried to use just Redux. But Tracker is so easy to use with Reactive/async data.
Now I am in a point where does the benefits of Redux are valuable for removing Tracker from the schene
3 Likes