aurelia-getting-started
aurelia-getting-started copied to clipboard
aurelia-contrib
Picking the right starting point cli vs jspm vs webpack
Existing documentation assumes that you know what jspm or webpack is and provides info on how to couple them with aurelia.. For newcomers (there are a lot of questions on gitter) its all greek or russian for that matter. Benefits and shortcomings integration options and such are a must know after you've learned a bit your way around cli and think about getting serious.
Question: do you intend for the discussion to happen in this issue and the result be consolidated into an article?
Why not? Or otherwise someone will create a draft and it can evolve further.
I'd say I recommend using webpack for several reasons:
- it is the industry standard with huge amounts of plugins, guides, etc
- the aurelia webpack plugin works really well with webpack 3 and 4. I'm currently using webpack 4 on a fairly large project
- automatic chunking. this is super useful when doing code splitting based on routes
- really fast
- uses standard es modules syntax
but it does have it problems:
- need to learn configuration
- configuration can get out of hand
- documentation can be scarce
jspm is basically dead and requires a lot more configuration than webpack, and the aurelia cli is just glorified gulp tasks that generate a concatenated file with requirejs for loading. I have used them both: jspm first, then the aurelia cli. they're both cumbersome to work with because you have to list the packages used and even point to the main file for each package instead of just importing them.
I would say the aurelia cli should just concern itself with generating stuff (components, pages, value converters) and not bundling because there are already really good tools out there. but that's for a different thread.
then there's parceljs. it looks promising. it's idea of zero configuration, I believe, aligns with aurelia's convention over configuration. it supports basically everything webpack does but out of the box. I've been using it lately with a react project, and it's reaaaally fast, and all it requires is to point it at an entry file.
but aurelia doesn't work it. this is because of aurelia's magic. even webpack doesn't work out of the box and requires the aurelia plugin. this is to say that if aurelia removed some of its magic when it comes to loading modules and simply aligned with the standards it would work easily with every bundler. but's that's also for a different thread.
I'd say if we write the guide on how to chose loading/bundling strategies.. we could just state the pro/cons and scenarios that apply... systemjs and require allow for dynamic loading of modules to come.. that are not bundled..
systemjs and require allow for dynamic loading of modules to come.. that are not bundled..
webpack and parcel also allow this using the almost standard dynamic import() syntax and amd and require.ensure
I meant modules not mentioned anywhere in the app.. imagine that you have a function to register new module by path to it.. how would webpack load corresponding view?
Using the @inlineView decorator and importing the view using HTML loader that way it's bundled
https://github.com/aurelia-contrib/aurelia-getting-started/tree/master/guides here
I agree with @obedm503 on Webpack it's a good option, however due to the breaking changes they like to make and complexity I've found the ecosystem doesn't always keep up. That stopped me moving to it prior to Webpack 4. So far the debugging experience is horrific (it likes to eat all the errors), although that might be related to using it in a .net core app via SpaServices.
I have a big project that use the cli and requirejs, and it's mostly fine but pretty slow. And there's definitely a lot more messing around with the aurelia.json file and it gets complicated with other file types.
@mttmccb would you mind to help testing https://github.com/aurelia/cli/pull/862 on your big project?
@huochunpeng I can have a look, if means I don't have to switch it to webpack then great 😆