Totally agree. I feel people just want faster reloads and Webpack is by and large seen as a pathway for that. I’ve not used it much other than to play around with it. Another thing folks might care about is, like you said, packages and workflow. That is very much about now and not tomorrow. Would it be useful without too much effort to support the needs of now as well?
So the answer is, it’s just too hard? Is the build system systemically flawed in Meteor?
So now MDG is going to shy away from takeing on the hard stuff, even when it comes to VERY important tech like Webpack (Read: code-splitting)? How disappointing.
So which is it, is it too hard or is Webpack flawed?
If Webpack is not right long term, then what else is used by the community achieves code-splitting and incorporates the ES2015 world of import and export?
I’m weary of taking on proprietary Meteor tech now that I know MDG will drop it like it’s hot when the fancy changes. I want something more widely accepted by the community, thereby insulating us somewhat from a few guy’s ideas about what’s best for us.
I think the real answer is that they are trying to be backwards compatible. If they switch to Webpack then everyone’s apps will instantly break and they’ll have to get rid of all their global variables and start the import/export dance (which may not be a bad thing) among other things. In addition, I assume there are some other major complexities that would make it near impossible to integrate Webpack into the existing build system without heavy modifications. If you’re going to have to rewrite a tool to fit your ecosystem then you might as well start from scratch so you can build exactly what you need. I’d love it if you could drop Webpack right into an existing Meteor app but it doesn’t appear to be a possibility. 
2 Likes
Yes - just look at how badly having one guy decide what’s best for us has worked out … with Linux. 
3 Likes
Exactly, just look at how they’re dropping Blaze, Tracker, Publications, Atmosphere and on and on they go…
So the answer is, it’s just too hard? Is the build system systemically flawed in Meteor?
It’s a question of technical debt. Any system we might build on top of Webpack would be much, much more complicated (and take longer to ship!) than something designed with Meteor’s build system and developer experience in mind. And it would be worse, in addition to being harder to maintain, because design decisions that we could otherwise make freely would be constrained by what Webpack can do.
We’re not shying away from anything. We’ve made a careful decision against using a tool (Webpack) that simply isn’t suitable for our purposes. Read my post (again) if you need further explanation, but don’t insult my intelligence or technical ability with your imagined theories about why we’ve made these decisions.
I’m weary of taking on proprietary Meteor tech now that I know MDG will drop it like it’s hot when the fancy changes. I want something more widely accepted by the community, thereby insulating us somewhat from a few guy’s ideas about what’s best for us.
What have we dropped? If you read the linked post in which I clearly explain why we’re not using Webpack, you’ll see that a big part of the reason we can’t “just use Webpack” is that we have a hard commitment to backwards compatibility. I wish we could ignore whole parts of the system we’ve built over the years, like the various Webpack integrations do, but that’s not an option for us.
Webpack happens to be popular right now among developers who think CommonJS is great, but that doesn’t mean it’s the right tool for the long term. Webpack is also a “few [people]'s ideas about what’s best for us.” That’s all software is, ultimately. I hope the feature set Meteor 1.3 provides will win you over.
I’m spending all my working energy (note: not quite all my energy, especially this time of year) steering Meteor back towards standards and best practices. A big part of that is embracing the npm package ecosystem, and migrating Meteor packages from their current format to the npm format, even though that means giving up some features that npm does not support. As Meteor projects become more and more like plain Node projects, tools like Webpack may become more useful, and I hope Meteor can get out of your way if you choose to use such a tool.
I also hope and expect that tools like Rollup will mature to the point of making Webpack and CommonJS obsolete, because that’s a future that takes full advantage of JavaScript standards, and a future I’m really excited about.
23 Likes
Thank you for taking the time to clear this up. Lets call it a day and have a merry christmas? 
1 Like
Indeed MDG is shying away from tackling the hard innovation its been know for. MDG could do a Manhattan Project style Blaze reboot, taking lessons learned from React and the other great UI packages out there – and surpassing them all.
Building on that momentum, they could then focus on a Tracker reboot/update and add code splitting for Blaze+Meteor.
Why is this logic not applied to the situation of Blaze over React? By building a BlazeNext you would never be constrained by what others cannot do. Blaze done right, and under MDG direct control could be something more than React.
I’ll re-read your post again, thanks.
MDG is or will be depreciating the following due to the decision to use React and GraphQL: Blaze, Tracker, Publications, Atmosphere and on and on it goes.
Gawd I love these quotes, again why doesn’t MDG apply this same logic to Blaze over React? Is React the “right” tool? This seem subjective. And ripping out a lot of tech and replacing it with React supported tech seems drastic to me.
It’s clear that Webpack is what the community has voted “yes” to by using it in greater and greater numbers.
We’ve been listening to what MDG has been saying about the reasons for replacing Blaze with React. One point that’s been hammered home by MDG is that React is the “chosen” tech because it’s being embraced by the community. It seem self serving to apply this logic only where it’s convenient.
Many want code-splitting in Meteor. If MDG has said Webpack doesn’t fit the bill due to technical issues, that’s a fine decision. But pull something else from the community instead of building in-house I say, because at this point it’s hard to trust in house solutions.
Also, to be clear, there’s been speculation by myself and others as to the motivations behind some of MDG’s recent technical decisions.
The reasons for this speculation in my opinion is two fold:
-
On the surface the recent decisions by MDG seem to not hold water and,
-
There has been a lack of communication from MDG proper on the rational behind the recent decisions.
Questions I have are as follows:
-
Why doesn’t MDG proper state plainly why they’re making the technical decisions they’ve made as of late to the Meteor developer community?
-
Why is MDG choosing React over Blaze and thereby gutting a large portion of existing Meteor tech?
-
Is MDG adopting FB tech a strategy to position Meteor for Enterprise adoption, and thereby promoting Galaxy and MDG Support Services?
Many of us have made huge (relative) investments in Meteor tech. I for one have built a company on Meteor tech. I’m very likely a future Galaxy customer too.
The decisions made by the small group at MDG directly affect the Meteor development community and small business people.
Cheers
5 Likes
I have to agree and disagree. @benjamn is saying ES6 has a syntax for that and we should use it. He is right. Webpack and CommonJS dealt with JavaScript short comings. Like Coffeescript did.
React is a front end framework not a standard. If anything, there is a stronger case for not using Webpack moving forward than using React over Blaze. Meteor wants to open itself allowing users to use whatever framework they want. They are simply opinionated or recommend React. What’s wrong with this? We’re free to use Backbone or Riot if we want.
If Meteor didn’t make this change, it would die. This is the way forward. My only complaint that there should be a reactive relational option. I feel that in the long run, it’s the data that’s important. Front ends come and go because both market and technology demand that it change.
Hot code reload and fast compile times should be improved. No debate there. This is a huge issue.
I totally agree about FB. I don’t like their license. Simple as that. I don’t want to use their stack ESPECIALLY in relation to data. I can always throw away a React front end. Back end? Hell nah G.
2 Likes
I like this better. Can you change Atmosphere to that? 
Or, perhaps have two numbers: one direct app installs, and the other indirect installs (when a dependency for example).
Meteor 1.3’s modules packages support now more than ever. Package authors can now write build plugins (as they always have) that will compile to a format compatible with ES2015 modules (for example, you could install some package, let’s pretend it’s called someone:png-modules, that lets you import foo from './foo.png' right in your JavaScript and you’ll get a data URL, or a file handle, etc, depending on what the package does). This is comparable to Webpack’s loaders.
1 Like
@benjamn what are the alternatives to require.ensure and module.hot in a fully ES2015 world of import and export that will allow the same features for which we love webpack for our build system.
If ES2015 or other tech is not providing an alternative, then we still need webpack and commonjs require.ensure and module.hot to do its thing.
When the ES2015 world of import and export provide such capability then an alternative to webpack exists and its 3rd party loaders will need migration too.
Until that design problem has a solution, then I’ll still appreciate that we can use commonjs and webpack (also for its other speed and advanced configuration features) with meteor with webpack:webpack (@eXon is working on 1.3 integration in the next branch).
So eventually we’ll need migration from the meteor+webpack or non-meteor+webpack solution to that shiny ES2015 solution when available with or without meteor.
btw, thanks for the great job, it seems to be heading in a better direction.
merry christmas.
2 Likes
Can we take this discussion to the appropriate thread? No need to have two in parallel, where the exact same points are coming up:
4 Likes
I feel Meteor 1.3’s new modules system is going to make Meteor’s build system better than Webpack or Browserify (although it might possibly be limited to Meteor’s ecosystem, @benjamn ?).
Is what too hard? @benjamn is already making it happen, so not for him. 
And, yes, Webpack is flawed, as you just quoted.
We must take first steps first. Meteor 1.3’s modules system is the first step towards other features that could be similar to or better than Webpack’s. In practice, we already have code splitting in Meteor 1.3 by simply writing more than one entry point. I would doubt that @benjamn hasn’t thought of how to share common modules between packages (code splitting). The steps that Meteor 1.3 is taking are making Meteor better. If you have advice on what exactly MDG should do to make Meteor better, please do share.
You’re not noticing the great progress that Meteor 1.2 (and now 1.3) are bringing to the table.
Soon enough Meteor’s build system will be arguably better than Webpack’s, etc.
That’s all talk and no do. If you have ideas on what should actually be done, then share them, otherwise people who are actually doing will make things happen the way they see fits best into Meteor.
Blaze 2 is in the works. Plus I like React much better than Blaze 1 anyways. Tracker is really handy, even while I use React, so I don’t see why that’s going anywhere. Publications are super useful too, I don’t see why those are going anywhere, even with GraphQL in the mix (the client should be able to run GraphQL queries only on published data). We can live without Atmosphere if all packages are NPM-compatible, honestly, and who cares as long as you can get the libraries that you need into your project? Atmosphere will still be there for packages on Atmosphere that haven’t been updated to live on NPM. Atmosphere dying isn’t a huge deal. What is a huge deal is that the new NPM support in 1.3 opens Meteor up to a huge community of developers that were previously outside of Meteor due to packaging restrictions in versions of Meteor up to 1.1.
Over Blaze 1, it is to me. I like to write well structured and modular code, and React does that better out of the box than Blaze 1. Just because Blaze is homegrown doesn’t mean it’s automatically better. Some ideas (like Spacebars templating) might be better in the opinion of some, which is fine, and which is the reason why Blaze 2 is in the works to provide the familiar language, but powered by React. Personally, I’m fine with JSX because I like the control I have with JavaScript compared to any more-limited templating language.
It’s also clear that these votes are made comparing existing technologies (Webpack, Browserify, JSPM, etc). But they didn’t take into consideration Meteor’s new modules system. Before the iPhone came out, no one had any idea what a “smart phone” could be like. This is the same: you have no idea how awesome 1.3 modules are because you probably haven’t seen all the aspects of it yet (I’ve written a build plugin for Meteor before, so I might have more perspective on this in order to see the benefits of the new system).
And it’s embraced by the community because of how great it’s concepts are. React is an amazing new way of thinking of UI composition and structural rendering (how we morph the UI structure of an app with a diffing algorithm), and has inspired projects like Mithril, Mercury, Om, etc.
It (the self-serving of React into Meteor) definitely makes my development experience in Meteor better, and it also makes my development experience with others better because it’s easier to reason about the UI in huge projects when code is modular and not globally scoped, thanks to React (compared to Blaze).
Can describe what you want to achieve by “code splitting” exactly? You want to load separate entry points at certain times (f.e. the view changes)? I have an idea for this…
2 Likes
I’d like to be able to limit what templates/JS the client gets and when, with something like associative tags I suppose.
For example, when a user first loads the application, there’s no need for them to get all the templates and JS. If they’re on a wizard, load up the first few pages of the wizard, and as they progress download more to the client as needed.
Another example would be, if a user doesn’t get a feature because they’ve not purchased it, they should never get this code unless/until they’ve gone through a purchase process. Then they can get the feature pushed down to the client.
Right now, my application is large. I have well over 100 Blaze screens and that number is growing all the time. The client today gets everything, every template and client JS file, even if they never use it. The site also has a built in Admin side, with many templates and code, but only a fraction of the users will ever need it.
Thanks for your feedback.
2 Likes
Already tried once
1 Like
I don’t think React is the right tool (yet). Tracker is the main reason for that. Shadow DOM and JSX aside, I think Blaze is the better choice until Tracker get’s the integration it deserves in React.
Beyond that, Tracker has to mature a bit. More about that [here] (https://www.google.dk/url?sa=t&source=web&rct=j&url=https://medium.com/%40faceyspacey/tracker-vs-redux-implicit-vs-explicit-df847abcc230%23.rj1vniytv&ved=0ahUKEwjD04ijsfXJAhXFRg8KHf5cANEQFggZMAA&usg=AFQjCNGF6KAflaivTyx0NDJ-HhZ1DxilxQ&sig2=VAYPWShQ8z6wbJTuIhIUUg)
I want to challenge this statement, so tell me;
- Are you using Tracker at all?
- How do you integrate Tracker within a React component?
- Is Tracker doing observes/reruns within layouts or conditionally rendered components correcty?
Nah it ain’t dying. Hipsters gonna hip is all. MDG needs to keep their eyes on the prize and make the best tool for Meteor devs. There is nothing like Meteor out there, period.
6 Likes
Yep, I agree, we need to be able to load files on demand, as in the idea I mentioned. I’d love for Meteor to have this feature now that it has modules! They go nicely together! We can write individual entry points to load separately.