19 ms·
Parcel – A fast, zero configuration web application bundler
- pbreit 9y agoDidn't see any info that would give me an impression of the possibility if this getting any traction which I think would be even more important than any specific benefits.
- stupidcar 9y agoThe eternal cycle of developer tool bullshit: 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."
- SadWebDeveloper 9y agoWelcome to developing in 2016-201X, were you spend 60% of your time configuring tooling, 35% developing test and 5% developing your app.
- awalton 9y agoCute that you think this started in 2016...
- SadWebDeveloper 9y agoTo be fair, i originally wanted to put 2010 but there are so many butthurt nodejs fans that will get easily offended.
- dotandimet 9y agoTake it down another decade. Or two. There are versions of Old/Super/Hyper in libraries and frameworks for Java, Perl, Python... Once you get the Internet, the hype cycle keeps speeding up
- doublerebel 9y agoHey dude, it looks like you've been shadowbanned for years and I don't immediately see why. Just vouched for this one. Thanks for your comments hopefully it all works out this holiday.
- nip 9y agoOr stick to something that works for you and keep using the same tool over and over again. 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.
- SadWebDeveloper 9y ago> No one is forcing you to use the latest bundler / tool / programming language Except everyone is using them and you get quickly outdated, specially if you are looking for a job with heavy experience on python, php and asp.net web development. The market already shifted to "3 Years worth of experience on Parcel".
- weego 9y agoI agree in a lot of environments, but web/js build tools seem to have a high frequency of fragmenting and becoming abandoned before any real long-term maturity is established.
- deoxxa 9y agoIt sure looks that way if you follow the news, but my webpack config has barely changed for two years now and I'm still getting work done.
- doublerebel 9y agoMy gulp configs have barely changed in 4 years. But we have to convince people to work together and stop jumping ship rather than ignoring the process. I don't think Node has this figured out yet unfortunately. Too much hubris.
- nathan_long 9y ago> No one is forcing you to use the latest bundler / tool / programming language. Tell me that when you get turned down in a job interview because you don't know <JS framework of the year>.
- djstein 9y ago35% developing tests? What great institution do you work for?
- IanCal 9y agoDepends if they're talking about adding tests or battling tests/test frameworks to just get something out.
- iamcasen 9y agoOh man, this is my life. Spurious integration tests that are critical, but very complex and often times have timeouts in our test runner depending on how many builds are going in there. I might take 1 day on the feature, and then 3 more days just getting it past the testing gauntlet
- je42 9y ago90% developer tests here
- SadWebDeveloper 9y agoSlack /s
- JepZ 9y agoThey probably code using Barliman[1] ;-) </joke> [1] https://github.com/webyrd/Barliman https://github.com/webyrd/Barliman
- borellvi 9y agoHave you ever tried a tool like https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app ? It makes your comment totally irrelevant.
- Boxxed 9y agoUnfortunately the whole world isn't developing a react app. And the fact that create-react-app even exists is definitely proving the point!
- borellvi 9y agoIs not about React, it is about tools that makes our life easier. If you want you can stick to ES5, no frameworks, no tools but good luck scaling your app to work with a big teams.
- lhorie 9y agoIMHO, unless your company is also working on a tool like Bazel or Buck, you don't really have a team scalability problem.
- notheguyouthink 9y agoYea, as a user of CRNA (create react native app) with a moderately simple app, dependency hell is something we're already in. We don't see a choice, for reasons, but CNRA is definitely not somehow above these problems. Node/JS in general has a pretty terrible track record for me with version hell.
- tropshop 9y agoStrong technical leadership and defining clear code boundaries is the secret sauce to scaling successfully. The shiniest tooling will not save your team.
- at-fates-hands 9y agoTHIS. 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.
- cortesoft 9y agoHow about you don't do that, then? What is stopping you from developing things like you used to? Those older tools still work.
- SadWebDeveloper 9y agoGo try to find a job that doesn't require any of the new tooling experience or look at the other extreme... looks for those asking 15-years proven experience of Cobol.
- mlsarecmg 9y agoI don't agree at all. Building things from scratch has never been easier. The difference is, today you can build highly complex stuff "from scratch" as easy as simple things. Components are ready to use, javascript and node can steer robots, machines, drive mobile and desktop applications, etc. All of this is set up like nothing. In the same time it costs you to boot up notepad.exe and create a HTML wireframe, create-react-app/electron/etc has already set up an application that is modular, knows dependencies and resources, is debuggable, can hot reload, etc. The time you would spend to get this manually ... it wouldn't even be fair to compare.
- SadWebDeveloper 9y ago> In the same time it costs you to boot up notepad.exe and create a HTML wireframe, create-react-app/electron/etc has already set up an application that is modular, knows dependencies and resources, is debuggable, can hot reload, etc. The time you would spend to get this manually ... it wouldn't even be fair to compare. Most of the times you don't need any of those things, you don't need modularization, you don't need a dependency manager, you don't need a debuggable version (because you are working on plain versions without minifies or module bundlers that compress your code), you don't need hot-reload (because you aren't using a transpiler/compiler-to-js), you don't need the hot-and-untested framework, sometimes you don't even need a source control. The big difference between that and going from scratch is that you choose what you want based on your needs not because everyone or a framework tells you "this is the right path", current state of web development increases "lego developers" to rise and shine like if they were expert.
- hannofcart 9y agoSounds good to me. If I could spend 60 hours on developing the initial tooling, and if I could spend just 5 hours writing minimal code to get things working as I want, and spend the rest of the 35 hours on testing and making everything watertight, I'd call it a job well done.
- nimchimpsky 9y agoThat sounds awful
- Udik 9y agoIt sounds awful, both for you and for the employer/ customer who pays you for only 5% of your time being actually spent in implementing features.
- r00fus 9y agoFeatures that break other features (or introduce vulnerabilities) because they haven't been through a basic testing are anti-features.
- Udik 9y agoSure. I don't write any tests (luckily I don't work on a business-critical system), and 10% of my time is dedicated to fixing features that were broken accidentally. And now? 90% of my time is still dedicated to developing new features.
- SadWebDeveloper 9y agoDon't bother feeding the trolls, r00fus it's a lego developer, if their framework doesn't support they will rebuilt everything from the scratch or mark it was wont-fix, for devs like him is that we can have nice things.
- meebs 9y agoPart of it is you already have SuperTool™ and teaching your team other tools or creating new ones initially seems more complicated than SuperTool™. Eventually paradigms to avoid the problems you face or better solutions are discovered, iterated on, and now someone can start a "better" one without fear of breaking backwards compatibility -- because there is no backwards. :)
- chatmasta 9y agoGod forbid we improve existing tools. What exactly is your problem here? Do you think we should all be using the Borland C++ compiler too?
- icholy 9y agoChange != Improvement.
- chatmasta 9y agoDoes the release of parcel mean you can no longer use webpack, or gulp, or grunt or whatever you’re using now? If you don’t like a new tool, don’t use it. I can’t stand this kind of meritless complaints. If you’ve got a problem with the implementation of a new tool, that’s understandable. But to take issue with its existence? That’s just petty and a waste of everyone’s time.
- lhorie 9y agoAgreed. It's more like Competition == Improvement
- brucephillips 9y agoNo, fragmentation can be destructive.
- lhorie 9y agoCan you give an example? In my experience that isn't really the case. For example, there are bazillions vdom implementations and they are only where they are now in terms of perf because of the intense competition. This was also the case with jQuery/Sizzle and friends back in the day. There's js-joda/moment/date-fns, underscore/lodash/ramda/just, css modules/styled-component/styletron, etc etc etc. Lack of competition tends to lead to stagnation, and since js has such a large (and growing) community, you're never really going to be at a situation where major libraries will run out of community support due to competition of equal caliber.
- wppick 9y agoThis sounds good to me. Encapsulate and simplify existing tooling based on the communities experience with it, then extend and add complexity as needed. As the development environment changes, we will constantly have to update our tools to make it simple for the basic 80% of cases.
- johnwheeler 9y agoI normally share the same sentiment unless the tooling truly is much better than its predecessors. This looks pretty easy to use and fast. If it delivers on those two promises, it's worthy of further consideration by the community.
- desireco42 9y agoI share your frustration. 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.
- pacoverdi 9y agoI use create-react-app and make sure I don't need to eject so (I guess) I use webpack under the hood, which I never had to learn. If CRA switches to parceljs and makes the build twice as fast, I'm all for it!
- amazingman 9y agoThe cycle described here is perfectly acceptable in principle, not to mention unavoidable in practice. Our developer tools will stop changing when humans stop changing.
- deleted 9y ago[deleted]
- brucephillips 9y agoNot really. Fragmentation is only inevitable when there exist feature tradeoffs. If Parcel's advantage is parallelism and caching, it's possible those features could have been added to Webpack.
- iinnii 9y agoHaving one tool that is configurable for all problems often becomes a mess and even harder to use.
- brucephillips 9y agoYou're correct, of course. I consider "simplicity" to be a feature, which is almost always at odds with other features.
- yoz-y 9y agoBut the solution to this is to make more tools with different tradeoffs. Not to add features to the tool that was supposed to be simple at the beginning.
- mempko 9y agoYou have never used Tex....
- redler 9y agoTrue, but Old, Super, and Hyper together represent a deep and productively adversarial exploration of the problem space -- each trying to best its predecessor. The overall problem space benefits, even as each package individually ages into senescent complexity.
- igloofoo 9y agoAKA Evolution
- conatus 9y agoIs my career as a Webpack whisperer at an end? cries tears of joy ;-)
- jameskegel 9y agoGo, you're free now.
- spondyl 9y agoShould main.css be included in the index.html example? This just confused me for some reason but it's more me focusing on the wrong thing, haha
- BlakePetersen 9y agoIt's injected into the main.js file which is added via index.js to the page
- stevefan1999 9y agoThe two coolest things about Parcel for me, are 1) multi-core support, and 2) a simpler, ES6-esque API. Without these two distinct elements, I think Parcel is nothing more than a simple Webpack boilerplate which could easily been generated by yeoman. 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.
- j4ship 9y agowhy are we not just using bash scripts ??? -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?
- jhurliman 9y agoI think you may be confusing npm with something else? npm is a package manager, and it does run as a command line tool. Similar to how apt-get is the command-line frontend for a package ecosystem. npm also includes npx, which allows you to directly run any command line utility in the npm ecosystem without installing the package first. Try running `npx ember-cli` directly in your terminal.
- j4ship 9y agoall you say is correct but im not confused. node and npm is require to run many command line tools (grunt, gulp ...etc). I think this is an unnecessary overhead if we could get these tools to just be built as standalone command line tools and then we can just use bash. Im asking for a particular feature that comes from this environment that I dont have in bash? Why do I need this environment. 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.
- thrownaway954 9y agohow does this handle existing 3rd party jquery plugins? The single biggest problem and configuration nightmare I always face is bundling something like CKeditor.
- deleted 9y ago[deleted]
- bovermyer 9y agoI am not the target audience for this. However, my first reaction was "yet another build tool, huh?" My next thought was "...I must be getting old."
- desireco42 9y agoYou might be getting old, but you are still of sound mind :)
- ardi93 9y agoWait for another 6 months, and we may have "yet another build tool" again
- qudat 9y agoI'm the target audience and thought the exact same thing.
- pier25 9y agoI think it's super cool. 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.
- hanley 9y ago+1 for Vue support
- supermdguy 9y agoAnd the over complexity begins... It would be nice though
- vladimir-y 9y agoWhy would you use Parcel if it's not yet ready to provide all the needed functionality? There is also fuse-box bundler, I din't try it on complex projects though (and not going to in the near future), but in some terms it might be a rival of this Parcel.
- xchaotic 9y agoExplain to me why do we web app need bundlers?
- GijsjanB 9y agoI long for the day I can use browser native import to retrieve all my modules and deps, but at this point it doesn't resolve node_modules and that makes it unusable to me and the reason I am using a bundler.
- davidnagli 9y ago2 reasons: 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.
- newsbinator 9y agoI've been using http://brunch.io http://brunch.io and enjoying it. Far less configuration than Webpack.
- desireco42 9y agoDefinitely overlooked gem. Phoenix is using it though (Elixir web framework)
- holtalanm 9y ago> I've been using http://brunch.io http://brunch.io and enjoying it. Far less configuration than Webpack. 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.
- Blaiz0r 9y agoI love brunch but I can't find a community for it, what do you do when you need support on a plugin or help understanding something? I have a few github issues open that haven't been touched in months! https://github.com/brunch/brunch/issues/1752 https://github.com/brunch/brunch/issues/1752
- newsbinator 9y ago100% agree that support is a major problem. I had to figure it all out for myself, through trial and error.
- iamcasen 9y agoBrunch is so 2011 bro /s
- segphault 9y agoWith transitive dependencies, the total install footprint for this is 689 packages weighing in at 77MB. 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.
- lojack 9y agoSure, its shifting complexity around, but its hard to argue that the API for this is more complex than the bloated boilerplate you're talking about. For some people the simplified API is worth the 77 extra MB.
- deleted 9y ago[deleted]
- Semiapies 9y agoI don't know about you, but that's where and what by i want tedious, error-prone work handled - out of my way and by the computer. 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.
- krzkaczor 9y agoWhat kind of argument is this? This won't be part of your bundle — it won't increase the size of your prod build but can save your precious time.
- hinkley 9y agoOne of the things I like about OSS and things like Stack Overflow is that in the old days, if I solved a hard problem, I solved it for a couple dozen people I worked with and maybe some folks at my next job. In some cases it made it hard to justify the work because I saved everybody 10 minutes a month and spent a week working on it. Which may be bad math for another reason: if I saved you the most aggravating ten minutes of your month, it may be worth many multiples of that ten minutes to you. 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.
- chickenfries 9y agoI have no problem with ditching webpack for another tool if it's faster and of similar or better quality. Is anyone using this in production and want to share their experiences?
- superasn 9y agoReally happy that besides being fast they made a priority to keep the configuration simple. 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!
- seekbeak 9y agoI had my eye on http://fuse-box.org/ http://fuse-box.org/ for a while, and tried a few sample projects with it. It has a lot of the same promises as Parcel appears to have. Multicore is exciting for me, which Fusebox doesn't have. So... many... choices...
- TY 9y agoCame here to puff about "yet another bundler". 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!
- pedalpete 9y agoIs anybody running a project with webpack that has a 20s rebuild time? 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.
- cygned 9y agoWe have a React app with roughly 100k LOC and a lot of SASS that takes about 4 minutes now to create the bundle on my MacBook Pro 2017.
- joekrill 9y agoThat's probably the initial build, though, right? If you've already got dev-server running and it has to rebuild, it shouldn't have to rebuild the entire bundle again.
- milesokeefe 9y agoAlso every time you add/remove a file or make similar breaking changes.
- cygned 9y agoYes, that is just the time for the initial (or production) build. The dev server is not as fast as it has been initially, but it is fast enough.
- regecks 9y agoIs that less than 3 seconds a production bundle (npm run build)?
- ricardobeat 9y agoSee https://github.com/webpack/webpack/issues/5718 https://github.com/webpack/webpack/issues/5718
- deleted 9y ago[deleted]
- dandare 9y ago> Bundle all your assets Can someone ELI5 what is bundling and what problem does it solve?
- deleted 9y ago[deleted]
- sthatipamala 9y agoSure. Programmers usually group logically-related functions/classes/components into smaller files. 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.
- JepZ 9y agoBrowserify, Webpack, Gulp, Grunt: everything nice and shiny, but the one JS lib that stands out for me is Rollup.js[1] 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. [1] https://rollupjs.org https://rollupjs.org
- notaboutdave 9y agoRollup is great. Smaller bundle sizes and no mystery meat. It takes a little more time to configure but it's worth it in some cases.
- substack 9y agoRollup is a good tool. You can get the same benefits in browserify using [rollupify](https://www.npmjs.com/package/rollupify https://www.npmjs.com/package/rollupify) or using [tinyify](https://github.com/goto-bus-stop/tinyify https://github.com/goto-bus-stop/tinyify) which can do tree shaking on commonjs as well as ES modules.
- vladimir-y 9y agoWebpack actually does the same (it's module bundler), browserify too (but in a more limited way). Gulp ant Grunt are not the module bundlers at all, but simply a task runners - absolutely different things. Btw there is also FuseBox module bundler, seems also with a focus on performance and configuration simplicity.
- sbergot 9y ago
- doublerebel 9y agoLooks like a well-thought-out approach to a clientside JS bundler. 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.
- aphexairlines 9y agoIt would be nice if these bundlers could help publish npm packages that vend non-JS assets (html, stylesheets, fonts, images) in a way that's easily consumed by other packages. 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.
- JepZ 9y agoActually, you can do that with rollup.js and riot.js. Components written with riot.js contain all their HTMl, CSS and JS (preprocessors can be used too). Rollup.js can import those components like normal js modules and at runtime riot.js injects the HTMl and CSS. 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.
- vladimir-y 9y agoIt's already a common approach to pack CSS and some other stuff into the single JS bundle, so it's feasibly and many devs already do that. It should be possible to do with any modern bundler, including Webpack of course.
- plurby 9y agoIt would be great if the author taken any of the HNPWA project and replaced WebPack with Parcel so you can compare the setup and actual configuration needed. WebPack is currently a standard and the community is great so I'm not seeing this replacing it in any way.
- tonysickpony 9y agoAs a person who is not well-versed in front-end technology, it will be great if the author(s) could provide more comparison on the website against some other tools that serve the similar purpose in aspects other than performance. For instance the by comparing the scope the problem each solves, the ideology behind each project, or even a side by side configuration file.
- wcr3 9y ago100% agreed.
- cvburgess 9y agoThis looks awesome! 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?
- lewisl9029 9y agoThis is what I was wondering as well. Especially since Webpack's tree-shaking doesn't _really_ work for a lot of third party libraries: https://github.com/webpack/webpack/issues/1750 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?
- gyrgtyn 9y agoWhich bundler does this use?
- davidnagli 9y agoIt is a bundler...
- kriss9 9y agoReact and node bundling and compilation ?
- maxpert 9y agoSo far from comments I have collected following bundling tools: - Webpack - Rollup - Fuse-Box - Brunch - Browserify
- statueq 9y agoWhen one deploys something like this in production, how do you interact with an internal API? Surrendering control of my url routing always causes problems for me.
- thelarkinn 9y agoFrom the webpack team to Devon: 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