1. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!"
2. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast."
3. "SuperTool™ v1.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension."
...repeat for a while...
10. "Introducing SuperTool™ v2.0.0, which now has a more flexible API and configuration , allowing many former hacks to be done in a straightforward way."
11. "SuperTool™ v2.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension."
...repeat for a while...
20. "Introducing SuperTool™ v3.0.0, with a whole new, flexible, pipeline based API. Everything is a plugin! There's even a plugin to send email!"
21. "Ugh, SuperTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!"
22. "Introducing HyperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast."
Its not necessarily bad as most new tools are slightly better than their predecessors, it just takes some getting use to and you have to learn how to structure your code base in a way that you do not have to completely refactor it every time a new build tool is adapted ;-)
In my imperfect memory, it was perfect.. (I couldn't go back though...)
No one is forcing you to use the latest bundler / tool / programming language. Let others experiment. You’ll be happy to reap the benefits of their work when something mature comes out of it.
I used to love writing code and building stuff from scratch. Nowadays it's exactly what you said. I spend more time configuring stuff and finding tools that work well together than actually writing the underlying code that makes the app or the website work.
However, this tool actually do useful work, based on quick glance I made. So maybe don't discount it just yet.
But again, I share your frustration.
This isn't reducing complexity, it's just taking all the junk you'd normally have in your bloated boilerplate and putting it directly into the build tool. I'm not convinced that's a good idea.
- Xcode, for iOS/Mac Development, is usually around 5GB (and
no, even if you remove every single simulator, it's still over 100-200MB).
- Android Studio is roughly the same deal as Xcode.
- I've not used Windows so I can't say for sure, but I'd be surprised if the various tech there doesn't follow this pattern.
Xcode and the Android SDK each come from a single vendor who provides an integrated development stack and presumably vets the contents. Does anybody do that with these npm packages?
It seems like every time I run the du command in my node_modules folder, I find some crap that shouldn't be there. Earlier this year, I submitted a PR that reduced the size of the babel react preset install footprint by about a third, just by removing a totally unused dependency that nobody noticed. I don't think the contents of npm packages get nearly enough scrutiny and it scares the hell out of me.
[1] https://www.bleepingcomputer.com/news/security/52-percent-of...
If I put the answer on the internet, then thousands of people benefit. If my work only save you five minutes one time, it still may be worth the bother in the grand scheme of things.
Which is a long way around to my point: this group is curating a bunch of build related modules which means I don't have to pay as much attention. That's not automatically a win (especially if they do a poor job of keeping up, which happens a lot in this space), but it has potential at least to be pretty useful.
Well, npm may implement some kind of content-addressable storage to transparently deduplicate the dependencies tree on disk. It's not quite easy to do well.
As long as your bundle size is small, and the build times are fast, it's a clear improvement, at the expense of spending like 0.15% of even the cheapest 60GB SSD.
If you have some simpler, better alternative to html, css, and JavaScript for websites, more power to you. Over here in the real world, though, we've got stuff to do.
Why? Because Rollup.js makes it possible to structure code into modules in a way that is backwards compatible and future proof. Yeah it takes some getting used to and it is not yet as simple as it could be, because integrating libs which are not yet available in the module format, takes some manual configuration, but once you know how to use it you won't want to got back.
I can highly recommend it, not because it is the hottest tool out there, but because I think it has a much higher long-term value than most JS libs.
Parcel seems to have a similar functionality but due to the wide range of other functions it comes with, I think there is a much higher chance that it will be rendered obsolete in the near future. Rollup.js on the other hand _focuses_ on the combination of modules to a single bundle which will continue to be required for the foreseeable future.
Actually, I still use Gulp to call Rollup.js as it is more flexible and allows me to use features which are not the scope of Rollup.js (e.g. automatic browser reload). My point is, that the exact thing Rollup.js focuses on is very important for the long-term development of JS: Modularization. Yeah, I know thats an upcoming part of the JS standard. But with Rollup.js you can use it today, as it has various adapters for legacy formats and therefore you have a tool which allows you a smooth transition into the future ;-)
I have a few github issues open that haven't been touched in months!
I used brunch with a rails app. Breakfast gem. Not as fun to use as it seems, since doing anything out of the norm is almost impossible to find documentation on.
Honestly, Webpack was easier to use, simply because it is easier to find information on the web about it.
Or if somebody has switched from webpack to parcel, can they give an idea of the performance improvement?
We've got a moderate sized app, and webpack rebuild (typescript, server-side react, client side js bundle, css export) is less than 3 seconds.
I've been configuring Webpack projects for almost 2 years now and I'd rather use Parcel tbh. My only problem is the lack of plugins such as loading .vue files.
It would be nice though
However, my first reaction was "yet another build tool, huh?"
My next thought was "...I must be getting old."
For example, if one of the JS modules in a library package says "import classes from './styles.scss'" and an application package imports that JS module, the application should somehow end up with the CSS output from styles.scss without having to configure Sass itself, and without having to include the entire stylesheet from the library package.
The only downside is that you either deliver one large bundle with mixed HTML/CSS/JS content to the browser or have to use some complicated configuration the split at least the CSS to a seperate file.
1. Browsers don't support JS modules 2. It's more efficient for browsers to request a single file than a bunch of smaller modules. So even if you use something like browserify, which dynamically loads modules in the browser, you end up with much longer load times because of all the overhead with each HTTP request.
-you can log output -perfectly capable of handling your unique build style -no setup (pretty much) -just call the command lines of other tools like (less.c, yui-compressor.jar ... etc) for compliation tasks
talk about over engineering. The thing is that the reason we dont have 1 to rule them all now is because no one has ever objectively argued why one is better than the other.
If we could just get command line equilvalents for things like ember-cli that didnt require npm then we would be good. Npm is the thing holing us back , we dont need it to do command line processing. Its a bloated middle man. Please command line tool gods , offer your tool outside of the javascript eco system. Build it in java and export to jar or c and allow us to worry about the stitching
Question , what is the thing npm/grunt/gulp gives us that cannot be done with bash, if all the tools we used were command line executables?
Try running `npx ember-cli` directly in your terminal.
I have a sense that webpack is the same, its a bloated environment. I dont need an all in one solution for a build process. Just give me the tools, ill use bash and call it a day. So Im just asking, is there something Im missing? What is the feature from these environments that I can directly preform by calling a script from bash? Why cant we just pull that script out into a command line tool and then devs can use it to their liking, pipe its output to a folder, cat that file to soemthing else, call another tool to minify the results, move all the contents to the dist folder.
Node just doesnt seem to give me any more power as a dev (build wise), why is it so important to the space.
Hats off to frontend engineers, the space has evolved to something respectable but I feel like over engineering is a pursuit of community. Its like they keep making new tools, to encapsulate more features and then post on HN and say "Look at this cool new way to do things that fixes that problem you really didnt have".
No ones webpack was bottlenecking their work, im guessing you can choose what to build and when so you dont have to do a full build every time. No one is going to choose a build system because of its blazing speed. I would rather not have people work on these problems that dont really need to be solved.
cries tears of joy
;-)
This just confused me for some reason but it's more me focusing on the wrong thing, haha
After reading the docs though I couldn't find any mention of tree-shaking or other things that would shrink the final bundle size. Any word on that front?
Especially since Webpack's tree-shaking doesn't _really_ work for a lot of third party libraries:
https://github.com/webpack/webpack/issues/1750
I imagine Rollup might do a bit better on that front since its the bundler that popularized tree-shaking in the first place. Can anyone with experience with Rollup comment on this?
Can someone ELI5 what is bundling and what problem does it solve?
The logic for web "applications" these days can be complicated and involve loading hundreds of such files. If loaded individually, this requires a lot of HTTP requests and results in a slow page load time.
Bundling is similar to a static linker in that it produces a single binary out of all its dependencies. This can be loaded with a single HTTP request, cached, zipped, whatever.
Then read all of the docs in 15 minutes and realized that I might like this.
Then I used it and I know that I'll keep using it, unless there are any showstoppers.
Great job, Devon!
I see its potential regarding Parcel’s competitiveness against Webpack, but it also has worsen the JavaScript fatigue, which is considered a nightmare for many newcomers webdevs because of huge fragmentation and thus bigotry in the industry.
Thank you so much for this work! Not only are we happy to see a real contender in the bundling space, but also look forward to not only work together, but also learn from parcel in ways we can help make webpack more flexible and easy to use for those who want "zero configuration".
Welcome to the bundler family!
Sean webpack team
I love webpack to death but there are just so many parts that I keep getting confused, esp with things like "!" in in require, always copy-pasting the same boilerplate code over and over to for sass, es6, etc. I know it may be more flexible but sometimes you just want things to work and can't be bothered with too many details. Laravel did this with elixir where it wrote a wrapper just to do it (which lets you just get on with your work without having to learn another tool). This too seems to be focused on that. Great job!
Is this officially backed by one of the author's employers or any other organization? I've seen too many projects (including major parts of bundlers browserify, gulp) die early when a sole author is forced to move on. Beyond the technical advantages, if I knew a company had already invested resources it would give me a solid business reason to switch.
- Webpack
- Rollup
- Fuse-Box
- Brunch
- Browserify