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.
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.
@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.
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…
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.
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.
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.
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.
But webpack seems to already work with the right package (and a modified project structure). I’ve seen it work in the “kickstart” demo projects, using webpack:webpack package. Sure it would be nice it was a little better integrated with Meteor…
I think code splitting is really important. One example: I’m building an app with react, but I’m using OrionJS for the admin panel. I don’t need all the bunch of Orion dependencies in the rest of my app, only for the /admin section.
But meteor doesn’t think about anything like that. Maybe I’m using a hefty charting library on just one page, why should I load that library when I’m using the rest of the site?
This is really important for mobile experience, when downloading all these extra libraries can take a long time over a slow network, also phones are slower in general.
I was thinking about splitting my app into two or more meteor apps, but that seems like a stupid solution, when the simple solution would be to just have code splitting, right?
I don’t foresee managing code-splitting (or on-demand loading) of a Meteor package’s files as a feature of Meteor in the near future unless packages use the new ES2015 modules and require us to import their libraries. If the orionjs packages let us explicitly import files from the package, then we’ll be more ready to support this case in the near future. We’ll need some cooperation from the orionjs authors at some point (to convert their libraries to the ES2015 modules). As for the actual code splitting / on-demand loading, I might try to implement that myself if I have some time. It should be a matter of modifying Meteor to to read a config in package.json that tells it to ignore certain files, and to make Meteor serve those files via HTTP so they can be fetched on the client-side.
Yep, exactly! I agree 100%. Meteor 1.3 is a stepping stone towards us being able to load things on-demand the proper way (following standards). We’ll get there soon.
Of course, code-splitting / on-demand loading would be the ideal solution, but it’s actually easy to do what you just suggested: we can make two Meteor apps share the same database. The second instance would just read the DB from the first instance. Then, each Meteor instance can send different things to the UI (and also some of the same shared code as well).
But yeah, I’d much rather have legitimate control over what scripts are sent to the client than launching two separate Meteor servers. Plus, with two servers on two different ports, it’ll be slightly harder to make a sing-page app. it’s a matter of manually connecting to the desired server from within the client code for specific views of the app (for example, an /admin view might need to establish a DDP connection to the second server manually which we gotta write extra code for unlike with the default first server).
Another thing you can currently do (which isn’t hard at all) is just compile your entry points manually with Webpack (or Browserify, JSPM, etc), place them in your public folder, then you can load those on demand right now! The only downside to this is that the build step for this lies in your hands, not in Meteor’s. You’d have to make sure the files your app needs are in public before you run meteor deploy ... or the files will be missing in the deployment. This is probably the easiest route to take currently. You can have multiple entry points in your public folder, and load any of them whenever, but the downside is that anything in public is public, so a mailicious user could download the admin script even if the user is not an admin if the user knows the URL.
Meteor is just Node.js. Another thing you could do is compile entry points into somewhere besides public (a .hidden folder so they don’t get automatically loaded) then, write (or use from NPM) a simple HTTP server to serve those files with whatever security you may have in mind. The Meteor app could spawn the HTTP server on a separate port, but it’d be on the same domain, so you can just request the files using the chosen port.
This kind of functionality is available for more than a year with preloader package - you can load different libraries per each route. Though it uses IronRouter but you can load libraries from wherever you want (CDN,…).
Thanks for the info on these different approaches @trusktr
I wonder if this is the approach that kickstart-hugeapp project is doing? I haven’t dug into how it bundles the app, where they end up.
Public folder isn’t a problem from my point of view, better to rely on proper security rather than security by obscurity (although obscurity I guess is a good second line of defense!))
In any case I wish there was a little more information, either from MDG or somewhere else on how to do this. You say “just compile your entry points manually with Webpack” but that’s not something I would know how to do on my own!
A component scoped within a class at that! It’s awesome.
1.2 also brought a major change to the build system, which compliments the ES2015 module system in 1.3. Meteor is it’s own Webpack now, where “loaders” (or “transforms”) can be added and removed as Meteor packages.
Or, perhaps have two numbers: one direct app installs, and the other indirect installs (when a dependency for example).
And, yes, Webpack is flawed, as you just quoted.
