[HN Gopher] Why we switched from Webpack to Vite
___________________________________________________________________
Why we switched from Webpack to Vite
Author : schestakov
Score : 208 points
Date : 2021-04-28 18:20 UTC (4 hours ago)
(HTM) web link (blog.replit.com)
(TXT) w3m dump (blog.replit.com)
| keithnz wrote:
| I've been using vite for a while now and it has been super
| painless. However I use it in a pretty straight forward manner,
| about the most "advanced" thing I use is a proxy to redirect web
| requests to the backend during development. I haven't played
| around with things like SSR yet which is currently marked as
| experimental.
| jcuenod wrote:
| Can anyone comment on Vite vs Snowpack?
| holler wrote:
| In the Ember.js ecosystem there's a really exciting new build
| tool project called "mho", that replaces webpack and uses a novel
| strategy running in a service worker to interpret native
| javascript modules with minimal overhead & near instant rebuilds
| (disclaimer I'm not familiar with how snowpack works under the
| hood).
|
| https://github.com/ef4/mho
|
| https://www.youtube.com/watch?v=09USvAy7w9g
|
| https://sqwok.im/p/TleLmpJ9BFp1IQ
| yepthatsreality wrote:
| > Esbuild is a JS bundler written in Go that bundles dependencies
| 10-100x faster than JavaScript based alternatives like Webpack
| and Parcel.
|
| A JS library calling a golang js-build tool to get the job done.
| Too funny.
| root_axis wrote:
| Why is that funny? How is it conceptually different from any of
| the variety of scripting languages that call out to C bindings
| or binaries?
| yepthatsreality wrote:
| It's funny because in order to compile/minify JS it passes
| said JS to golang which spits out JS to be run under JS. I'm
| not allowed to be amused by the circularity? Get a grip.
| qbasic_forever wrote:
| Python is a C core that takes Python code and spits out
| bytecode to interpret and run said Python. What esbuild is
| doing is not much different than any other interpreted
| language.
|
| (p.s. JS is not compiled)
| yepthatsreality wrote:
| It's not much different but yet it needs a solution built
| in another language to "build" it. I understand the
| process is not much different from other scripted
| languages but I find it funny that JS cannot reasonably
| do this itself.
|
| (p.s. I'm aware)
| root_axis wrote:
| Why so defensive? I didn't say anything about what you're
| allowed to do, I simply asked you a question about why you
| thought it was funny.
| mavelikara wrote:
| Many golang webapps use JS as their front-end language. Use the
| right tool to get the job done etc.
| yepthatsreality wrote:
| Being on the web it would be difficult not to no?
| ZephyrBlu wrote:
| You can server-render pages.
| jupp0r wrote:
| This might shock you, but webpack runs on node/V8 which is
| written in C/C++.
| yepthatsreality wrote:
| Nope.
| kklisura wrote:
| How long until "Why we switched from Vite to *"?
| trinovantes wrote:
| I wonder why all these new bundlers don't provide a webpack-
| compatible API to entice new users. I can't take the risk of
| investing in a new tool only to find that I can't migrate the
| last 20% key features that I need. I also don't have the
| bandwidth to constantly switch between vite, webpack, parcel,
| etc. every time I switch to a different project.
| fastball wrote:
| Because my main quibble with webpack is that its API is a mess
| and sucks.
| qbasic_forever wrote:
| Snowpack (which also uses esbuild internally) has a webpack
| compatibility extension:
| https://www.npmjs.com/package/@snowpack/plugin-webpack -
| andrewmcwatters wrote:
| I can only imagine it's because the authors don't care, right?
| If they cared, they'd build it. But I think most of these
| bundlers are out to show you how great they are, and how you
| should drop everything to do things their way.
|
| So, ultimately I think the answer is to say, "No, solve my
| problem, not yours."
| colordrops wrote:
| What about using native es6 imports cached by a service worker?
| If you don't have to support old browsers, this is a much better
| option than a compile step. Just pull from git and load it in
| your browser, no complications eating a weekend reading through
| docs and shotgun debugging.
| sunflowerdeath wrote:
| I have tried to use esbuild, and over the past 3 months I had at
| least a dozen times when it has compiled incorrect code that
| doesn't work or doesn't do what it's supposed to do. So despite
| the performance benefits, I was forced to go back to webpack,
| babel, and terser.
| ballenf wrote:
| Any specific scenarios where it fails? We're using it across a
| wide codebase and several teams and I haven't seen or heard
| that issue.
| donjoe wrote:
| Did u try using typescript with esbuild? React + esbuild +
| typescript is a perfect combination for me. I had the chance to
| kick off a new project a few months ago and started with this
| stack. It needed roughly 50 lines of code to get a decent
| server side rendering development experience set up. Compile
| time is still below 200ms.
|
| The only issues I had in the beginning was esbuild's
| compilation of typescript enums: the import order was off from
| time to time. Besides that, no issues. I am also super glad I
| do not need to configure webpack any longer.
| MintsJohn wrote:
| Webdev truly is one of a kind. Not only do you have your source
| code, you also have your build code, oddly dictating the
| organization of your source code. For extra fun, some libraries
| don't build with build system a, others require build system b,
| when you're lucky enough to have a working mix, changing build
| systems is better to be avoided. Of course periodically the
| officially blessed build system for your used libraries changes.
|
| The webdev ecosystem is so broken, it's no wonder so many
| websites deliver assets that are extremely suboptimally
| optimised, big unused blobs of assets /scripts slowing page load,
| optimising it all is actually made harder than coding it all.
| brundolf wrote:
| > you also have your build code, oddly dictating the
| organization of your source code
|
| It... really doesn't? You generally have an entry point file -
| which can be any file, you just have to specify it to your
| build system - and import statements are followed from there
| on. If anything you could argue the JS build ecosystem is too
| _flexible_ (which is one of the things esbuild is pushing back
| against). I 've never heard someone criticize it for being too
| _opinionated_.
|
| > For extra fun, some libraries don't build with build system
| a, others require build system b
|
| I've literally never encountered this problem. Library authors
| virtually always ship least-common-denominator JS that will
| work without using a build system at all, and then build
| systems know how to handle lots of different variations of JS
| and converge them into a single representation. Compatibility
| is not an issue that exists in my experience.
|
| > The webdev ecosystem is so broken, it's no wonder so many
| websites deliver assets that are extremely suboptimally
| optimised, big unused blobs of assets /scripts slowing page
| load, optimising it all is actually made harder than coding it
| all.
|
| Now you're just airing your own personal beef which doesn't
| actually have anything to do with the original topic.
| toddmorey wrote:
| I knew someone would bring this comment.
|
| Webdev can be broken, but doesn't have to be. I am currently
| having fun & feeling productive on both a large team project
| and some small personal projects.
| [deleted]
| the_gipsy wrote:
| Then also make unit, integration, and e2e work with all the
| transpiling. Good luck with sourcemaps!
| Kaze404 wrote:
| You enable sourcemaps on Webpack with `devtool = "eval-
| source-map"` in your config, and I'm not sure how you expect
| transpiling to be a problem with testing considering your
| tests are also transpiled.
| the_gipsy wrote:
| Do you compile and run your unit tests with webpack?
| kall wrote:
| Have you seen the android build system? I mean what the hell is
| a gradle wrapper. At least js tools are configured in .json or
| .js files not in a special purpose programming language.
|
| I don't mean to discuss which system is too complicated and
| which is not just to point out a lot of real world build
| systems are on that level.
| napsterbr wrote:
| > The webdev ecosystem is so broken
|
| Allow me to correct this statement: The _Javascript_ ecosystem
| is so broken.
|
| Working with Clojurescript and Elm is an experience that will
| make most developers fall in love with web development again.
| curun1r wrote:
| Also Trunk [0] for Rust-wasm web dev. It's made me not hate
| doing the front end for my projects. I look forward to the
| Rust web ecosystem evolving to the point where I can
| recommend it in a work context.
|
| [0] https://trunkrs.dev/
| krapp wrote:
| Hate to break it to you but Clojurescript, Elm and the whole
| paradigm of "compile to JS" languages are part of what is
| broken about the javascript ecosystem. So much unnecessary
| complexity and energy wasted making javascript pretend to be
| something it isn't and to make it do things it was never
| meant to do, pressing a small, simple and powerful scripting
| language into the service of the profane eldritch abomination
| that is Enterprise Development.
| deergomoo wrote:
| I dunno, I feel that's like saying that Lisp and Haskell
| are part of what's broken about the machine code ecosystem.
|
| ClojureScript and Elm aren't compile-to-JS languages for
| the sake of doing something weird, there's just literally
| nothing else that will run in a browser (except wasm but
| probably best not to get into that).
|
| Different programming languages exist for a multitude of
| valid reasons, the compiled output isn't particularly
| important as long as it can express everything you need it
| to.
| krapp wrote:
| > I dunno, I feel that's like saying that Lisp and
| Haskell are part of what's broken about the machine code
| ecosystem.
|
| It would be if machine code were another high-level text-
| based language completely unrelated to either Lisp or
| Haskell with its own semantics, execution model and type
| system rather than a more directly machine-readable
| format of those languages themselves.
|
| Javascript is fundamentally different enough from a
| bytecode for any arbitrary language that, at least to me
| the distinction matters. I can accept that it works well
| enough that most people don't care, even though I suspect
| most of the use cases for doing so (error checking, type
| checking) could be better served with linters or editor
| tools for JS itself.
|
| But the decision to avoid actually writing javascript at
| all costs has contributed a great deal of complexity in
| the JS ecosystem, which translates into the bloat in the
| web that everyone complains about, because all of that
| javascript is wasting time and cycles simulating other
| languages.
| jupp0r wrote:
| I see you have never worked on a C/C++ project.
| uhhhhhhhhhhhhhh wrote:
| Yeah this appears to be more or less the essential complexity
| of build+link
| Shorel wrote:
| I have done both. C++ is miles better in comparison.
| z3t4 wrote:
| For personal projects I just use plain javaScript, ES5 even,
| without any compile steps, everything loads instantly and runs
| on every browser that supports JavaScript, and the development
| can be set up in any environment/OS without headaches. I do use
| minification for production but that is not really necessary if
| the browser supports loading JS-script tags async (all major
| browsers). The bundle gets very small without any frameworks
| attached. Debugging is easy with the browser built in dev-tools
| - with small error messages that always have the correct line
| (eg. no source maps). I'm currently working on a 100,000+ line
| JS project that uses the plugin pattern with script tags and
| it's very manageable, adding new features is fast and fun.
| There are of course trade-offs, I can't just "npm install
| react-x-y-z", but the browser API's are extensive, you can do
| just about anything on the front-end with just the native
| browser components and API's.
| andrewmcwatters wrote:
| My position on web development for even consulting projects is
| just to not use build processes as much as possible. I still end
| up using them for things like JSX, but I don't bundle anymore,
| nor do any web projects I build require installation out of the
| box.
|
| I've found that by doing so, I can just basically ignore, for
| years on end, all of the peddlers pushing how their projects make
| development easier or faster or some nonsense.
|
| You know what's easiest and fastest? Flat files in a good
| directory structure with some getting started template.
|
| That's it. The fastest build times are the ones that don't exist.
| Period.
|
| Web development is as complicated as you choose to make it. Very
| few fields work like this.
| shakow wrote:
| > Very few fields work like this.
|
| Quite the opposite; I would argue that webdev is basically
| rediscovering the whole shebang, but decades later.
|
| Modern webdev with transpilation, linking, pruning, compilation
| to WASM etc. starts to dreadfully look like the classical
| native development paradigm.
| andrewmcwatters wrote:
| Yeah, and basically none of that is necessary. Which is my
| point exactly.
| WORMS_EAT_WORMS wrote:
| From the article, a good explainer:
|
| > Vite works by treating your source code and your dependencies
| differently. Unlike your source code, dependencies don't change
| nearly as often during development. Vite takes advantage of this
| fact by pre-bundling your dependencies using esbuild. Esbuild is
| a JS bundler written in Go that bundles dependencies 10-100x
| faster than JavaScript based alternatives like Webpack and
| Parcel.
| vaughan wrote:
| I find it useful to have my vendor dependencies compiled and
| watched for debugging. There are always bugs in deps or poor
| error messages, and sometimes the dev tools debugger doesn't
| work properly, so being able to modify a dev is nice.
|
| Of course it would prob be better if this was a toggle.
|
| I think webpack module federation may improve this situation
| too. I used webpack all plugin previously to speed up vendor
| dep compilation.
|
| Thing about webpack though is it's so complex how all this
| works that I always have to revisit it every few months to jog
| my memory.
|
| We need simpler abstractions on top. Next is nice but still, if
| you need to dive deeper it's painful.
|
| I think in like 20 years time we will probably be able to get
| rid of all of this tool chain and the new kids will never know
| the pains we went through.
| brundolf wrote:
| I haven't tried Vite, but I tried ESBuild last weekend on a
| personal project and was absolutely blown away. Even as someone
| who's become pretty comfortable working in the Webpack trenches,
| I don't see myself starting a new project with Webpack ever
| again. There's just no reason to when you can get the exact same
| output, much faster, without any of the headaches.
|
| Honestly it's so good I wonder if it will undercut Deno a little
| bit by lowering the barrier for bootstrapping a TypeScript
| project
| marclave wrote:
| It's always impressive to me that, the co-founder of Figma
| (https://twitter.com/evanwallace) who essentially built a browser
| in a browser (figma.com) built esbuild. Could honestly be the Woz
| of our generation.
| Vekz wrote:
| He has some insanely high quality projects. shout out to his
| His Kiwi Schema https://github.com/evanw/kiwi project that
| saved me from protobuff swamp monster hell
| nailer wrote:
| How is Figma considered a browser in a browser? It's a great
| design tool, I just haven't heard it described this way before.
| Palmik wrote:
| How do people using Vite deal with Common JS dependencies? As far
| as I tried, there were issues with those when using "vite dev".
| Sadly, at this point, I can't get rid of those (e.g.
| protobufs+grpc-web generated code).
| vijaybritto wrote:
| I recently ported a microfrontend based frontend to webpack 5 and
| replaced babel/terser with esbuild and the builds are 50%-60%
| faster now. I couldnt replace webpack because I am using Module
| Federation which is not available in other bundlers. Would
| recommend this approach if not possible to fully replace webpack.
| eliseumds wrote:
| I literally just spent days trying out Vite and comparing it to
| Webpack 5, and I can comfortably say that they are in two very
| distinct leagues. It isn't fair to compare Vite to a CRA build
| with Webpack. You can greatly improve Webpack's performance by:
|
| * Making sure `mode` is set to "development" (don't specify it
| all if in doubt)
|
| * Ditching babel-loader and using esbuild-loader instead
|
| * Adjusting build targets and making sure polyfills are not added
| in development
|
| * Making sure you don't import the entirety of libraries like
| Lodash and MomentJS (prefer date-fns)
|
| * [FUTURE] We'll soon be able to tell Webpack to output ES
| modules just like Vite [1]
|
| Vite still has many problems:
|
| * It just isn't suitable for proper server-side rendering, we'd
| need access to chunk names at build time
|
| * It has a weird mix of own and Rollup config settings that seems
| somewhat unpredictable
|
| * Many open issues regarding module imports, for ex, when a CJS
| module imports an ES one [2]
|
| Our current bottleneck with Webpack is actually sass-loader,
| taking at least 70% of the time during a fresh build, and we'd
| have the same problem with Vite.
|
| Something else that is worth pointing out is the ecosystem:
| Webpack's community has built tons of plugins for basically any
| use case you can imagine, and version 5 supports module
| federation, persistent caching, externals (very handy when doing
| SSR), customizable filename generators, performance hints, etc
| etc. Totally different game.
|
| Try to keep your build config simple, avoid too many loaders,
| plugins, and you should be fine 99% of the time. If you hit a
| wall, install _speed-measure-webpack-plugin_ to get some help.
|
| [1] https://github.com/webpack/webpack/issues/2933
|
| [2]
| https://github.com/vitejs/vite/issues?q=is%3Aissue+is%3Aopen...
| theon144 wrote:
| >* It has a weird mix of own and Rollup config settings that
| seems somewhat unpredictable
|
| Oh god, this is a giant red flag. This is precisely one of my
| biggest gripes with Quasar (a Vue framework), which, on top of
| webpack/vue adds its own config that are intermingled with
| vue's and webpack's, and its honestly a mess, and oftentimes
| just straight up makes problems harder to solve.
|
| I am obviously not railing against config dedicated to a single
| tool in a toolchain, but the way you described it rings a bell,
| especially the "unpredictability".
|
| >* Many open issues regarding module imports, for ex, when a
| CJS module imports an ES one
|
| This also seems to confirm my and other's suspicion, that the
| tool isn't really "deliver-grade".
|
| >If you hit a wall, install speed-measure-webpack-plugin to get
| some help.
|
| But on the other hand, this is at least the fifth plugin I have
| heard someone recommend, dedicated just to profiling Webpack.
|
| What do you think about the time difference shown in the
| article? I sort of feel it's a bit disingenuous since the test
| included a lot of other variables, but it seems hard to argue
| against it if it's this plain. Is this a config issue, or a
| "most commonly used loader" issue...?
| eliseumds wrote:
| I'd be dishonest if I told you I was able to compare them
| 1-to-1. I couldn't finish my Vite setup because of bugs and
| lack of proper SSR support.
|
| I believe that, at this point, people are just nitpicking.
| When working on a client-side-only app, Vite is faster, but
| not by that much. In one of our apps, I saw it starting up in
| 1s compared to 2s with Webpack, and reloads in 100ms compared
| to 250ms. This is a Preact/TS/Emotion app that outputs almost
| 7MB of assets, 61 files to be precise, and works on IE11. And
| I hadn't even tried persistent caching with it yet. Webpack 5
| with esbuild is a fast-enough solution.
|
| NextJS is a well-established tool now and version 10.2 uses
| Webpack 5 under the hood. V11 is looking insanely fast (I
| suspect they replaced Babel with esbuild):
| https://twitter.com/shuding_/status/1378086219708473344.
|
| So yeah, slow performance with Webpack is definitely caused
| by a bad set of loaders/plugins. Eject a CRA app and you'll
| see a monster coming out.
| earthboundkid wrote:
| If you figure out how to get Webpack to solve all these issues,
| that makes one working Webpack installation. When Vite solves
| their issues, all Vite installations will have the issues
| solved.
| eliseumds wrote:
| Vite is not a completely opinionated tool. You can still
| customise its behaviour and use plugins, so both
| installations would have very similar vulnerabilities at the
| end. For SSR, you need a self-written server entry point.
|
| Webpack 5 has introduced asset modules, so now you can safely
| ditch raw-loader, url-loader and file-loader. [1]
|
| You might have NextJS or CRA in mind.
|
| [1] https://webpack.js.org/guides/asset-modules/
| jitl wrote:
| We just switched from TypeScript/ts-node to esbuild for server-
| side code at Notion; it's been great. Would love to see the same
| kind of speed wins for our clients :')
| patak_js wrote:
| If you want to learn more about Vite, I recommend that you join
| Vite Land (https://chat.vitejs.dev). There is a very active and
| helpful community, and there are tons of opportunities to
| collaborate in the creation of plugins, integrations, and to
| improve Vite itself.
| rgovostes wrote:
| When I learned about Prolog in university I had a "eureka" moment
| where I wondered why I was spending all this time learning to
| implement algorithms in imperative code, when I could just
| express the output I want and then let some uber constraint
| solver figure out how to produce it. How liberating declarative
| programming would be if only we started coding with it more.
|
| When I try to use Webpack, as I click through obsolete
| StackOverflow posts, trying to figure out the right key-value
| pairs to get the output I want, I realize how mistaken I was. I
| hope build tools for the web become less "magical" and more
| predictable and debuggable, even if it means discarding their
| declarative form.
| zackkrida wrote:
| A similar tool in this space is Jason Miller's (@developit) WMR:
|
| https://github.com/preactjs/wmr
| TurningCanadian wrote:
| For people already on webpack, there's esbuild-loader
| (https://github.com/privatenumber/esbuild-loader)
| temuze wrote:
| We recently switched from ts-loader to esbuild-loader. It was
| super easy and it halved our build time with zero
| complications. Highly recommend.
| nailer wrote:
| Ooh next uses webpack right? Might be some free speed. Thanks.
| wetmore wrote:
| Yes but there are some difficulties you may run into when
| replacing the default loader nextjs uses, because it includes
| some custom babel plugins that get blown away when you
| replace the loader with esbuild-loader.
| nailer wrote:
| Thanks for the heads up.
| gwn7 wrote:
| I wonder how this compares to a proper manual Webpack
| configuration. Comparing it to CRA isn't really helpful to me, as
| CRA is already known to be very slow.
|
| I would consider trying it if it has significant performance
| benefits over a manual Webpack config, especially one making use
| of esbuild-loader (https://github.com/privatenumber/esbuild-
| loader)
| dmitriid wrote:
| > compares to a proper manual Webpack configuration
|
| What is a "proper webpack config".
|
| It's such a complex and arcane beast, that I doubt anyone could
| really figure out a "proper" way to do anything with it.
| zellyn wrote:
| I was a little surprised that Vite, which depends on esbuild and
| thus should know better, is written in Javascript.
|
| I presume this is a considered choice, and that what Vite does is
| unlikely to be on the critical path for edit/build/view cycle
| time...
| afavour wrote:
| > thus should know better
|
| I would posit that perhaps they know better than you.
|
| When pure performance is the concern it makes sense to go to a
| more performant language, like Go. But every time your
| JavaScript build tool moves away from JavaScript you close
| yourself off to a huge pool of potential code contributors and
| make it a lot more difficult to customise. So I think Vite has
| it just right: optimise the really intensive stuff, leave the
| rest more available and more editable.
| zellyn wrote:
| Hmmm. I knew I was being a bit of a smartass with, "and thus
| should know better", but I figured I mediated that in the
| second sentence, where I presumed they know what they're doing.
| -\\_(tsu)_/-
| wonnage wrote:
| The speedup from tools like esbuild, swc, etc. are not because
| of the language they were written in but because they're
| competing against Babel. Babel is this single-threaded highly-
| extensible behemoth. On top of this, you're encouraged to
| install dozens of plugins, and each plugin has access to global
| state.
|
| The new transpilers have worked around this problem by
| introducing various limitations. esbuild plugins literally
| can't modify the AST. It's basically a way for you to run a
| command on a string/file. So sure, if you redefine the problem
| as string transforms rather than AST transforms, you can get an
| O(N) speedup...
| eliseumds wrote:
| Precisely. I'd advise having esbuild behind Babel if you
| really need an specific Babel plugin, for ex:
|
| * Transform the file using esbuild first
|
| * Then use Babel with that one specific plugin (Loadable
| Components, Styled Components, Apollo, React Refresh...)
|
| This is much faster than letting Babel do all the work.
| andrew_ wrote:
| > thus should know better
|
| This reads as a very acrimonious, biased take. Authors choose
| the tools they use based on a number of criteria and personal
| preferences. It's one thing to disagree with them, it's another
| to project judgement without knowing the why.
| Daishiman wrote:
| Frankly, I would pass.
|
| The switchover of build tools in JS land is insane. I get that
| this has concrete performance improvements over alternatives, but
| I wonder if the same effort put towards improving an existing
| toolchain wouldn't get you a lot of similar efforts without
| breaking everything yet again.
| dlrush wrote:
| You can switch to esbuild now or you can switch later, but you
| will switch. It is superior in design, configuration and
| performance by orders of magnitude.
| root_axis wrote:
| That's the beauty of it, if the concrete performance
| improvements don't seem like a worthwhile tradeoff you don't
| have to use it. The idea that everyone should just contribute
| to one package instead of creating their own solutions is just
| silly, we are not able to dictate what people code up in their
| own time. Besides, there are dozens and sometimes hundreds of
| active contributors to every popular open source package, just
| adding more developers doesn't necessarily make things better,
| not to mention that the necessary quality control and code
| review demands for mature projects means many contributions are
| often misguided or not useful.
| vaughan wrote:
| A counter point would be to look at the Python ecosystem.
| They have many fewer libraries but the ones they have are
| very well maintained and widely adopted.
|
| JS/Node is full of unmaintained projects that people
| inevitably need to migrate away from.
|
| Of all the new choices in bundlers today, it's also
| inevitable that some won't work out, yet they will drive hype
| and adoption, which could have been spent on already
| established tools such as webpack.
|
| Yes, innovation is good and no one should tell someone what
| to do in their free time.
|
| But it's always going to be harder to build on top of old
| rather than to write something new, but what is new
| eventually becomes old...and the cycle repeats.
| root_axis wrote:
| > _A counter point would be to look at the Python
| ecosystem. They have many fewer libraries but the ones they
| have are very well maintained and widely adopted._
|
| So what? It is what it is - the python ecosystem faces
| completely different challenges than the JS ecosystem, if
| the browsers exclusively ran Python instead of JS it would
| be the exact same situation for Python.
|
| > _JS /Node is full of unmaintained projects that people
| inevitably need to migrate away from_
|
| This isn't true. jQuery, Angular.js, Angular, React, Vue
| etc are all still maintained (check their githubs if you
| are in doubt) and all still work just fine, so if you want
| to use the same tooling you did a decade ago that's totally
| possible.
|
| > _it's always going to be harder to build on top of old
| rather than to write something new_
|
| So what? If you want to contribute to old projects instead
| of writing something new you're free to do that, and if you
| don't like new stuff you don't have to use it, complaining
| about this stuff is just pointless contrarianism, but of
| course, you're free to do that too.
| bastijn wrote:
| Thanks for reminding me I'm getting old and corporate.
|
| My first two thoughts were:
|
| * Imagine all the smart people in webdev world would improve the
| existing tool rather than create a new one. [0]
|
| * "if you do less, it will go faster". I.e. Vite is young and
| new, supports a subset of Webpack and of course boasts how fast
| it is. Yet my repos can't use it because it doesn't has the
| support it needs for my repo sizes with legacy stuff. Of course
| it is "on the roadmap" and by the time it will be supported Vite
| is as slow (if lucky) as Webpack. Doesn't matter though as a new
| tool will be there long before Vite reaches Webpack..
|
| Yup. Getting old and also cynical in the evenings. Dammit!
|
| [0] https://xkcd.com/927/
| amasad wrote:
| Some stats not mentioned in the post. Create React App (webpack)
| vs Vite (esbuild) on Replit containers:
|
| - 1 second start up time on Vite vs 15 seconds for CRA
|
| - React.js hello world project is 234mb on CRA and only 34mb on
| Vite
|
| - 1GB RAM for Vite dev server vs 3GB+ for CRA
|
| This is a perfect example of how fast and efficient tools can be,
| and I think we can do even better! Super excited about the future
| of JavaScript tooling ecosystem with more focus on efficiency and
| speed.
|
| In addition to the UX win, and I wish we measured this, but I bet
| this saved us thousands of dollars in monthly cloud spend.
| [deleted]
| sjaak wrote:
| "Only" 34mb for a hello world project? I can't tell if you're
| being ironic but I hope so!
| amasad wrote:
| Nearly an order of magnitude reduction. What do you think of
| that?
| lhorie wrote:
| They probably mean that "hello world".length == 11 // bytes
| nine_k wrote:
| Most of the _build tooling_ gets installed along the way.
|
| The compiled JS is hundreds of bytes at most, usually
| because React creates a bunch of boilerplate for you (a
| basic CSS file, an application, a web worker, etc) which
| you may remove.
| JMTQp8lwXL wrote:
| As the "webpack" guy on my team, these numbers look extremely
| compelling, but I also know Webpack does a lot for us (e.g.,
| through Webpack v4, it includes browserfied node libs as
| needed). Beyond node libs, there's a long tail of niche things
| that need to be taken of... am I trading coverage of that long
| tail for speed?
| jakelazaroff wrote:
| In my experience, the vast majority of use cases are covered
| by these "no config" tools. If your app isn't a typical CRUD
| app you might fall into that long tail, but FWIW almost every
| app I've built has not :)
| desireco42 wrote:
| You still need webpack for production build :). So all is
| good.
| darekkay wrote:
| Vite uses Rollup for production builds, which is still much
| faster than webpack.
| simlevesque wrote:
| Why can't you use esbuild for production builds ?
| vijaybritto wrote:
| You still can do polyfills manually via browserify packages
| judofyr wrote:
| Previously I've been a heavy user of Webpack + plugins, but
| I've now moved over to ESBuild for all new projects. This
| means letting go of many fancy features, but the overall
| complexity is so much reduced and I'm a lot happier.
|
| Before: Chain together style-loader, css-loader, postcss-
| loader and the MiniCssExtractPlugin in some weird way. So
| complicated to understand which PostCSS plugins interacts
| with resolving imports. I often need to look into the
| webpack.config.js to understand how everything work. After:
| Use PostCSS and its tooling for CSS. Yes, there's now a
| separate process I also need to run in order to watch and
| build CSS. Yes, I can no longer `import "./style.css"` from
| the JavaScript files. But it's so much easier to reason
| about! The CSS tooling creates a CSS file; the JavaScript
| tooling creates a JavaScript file. Do I want to build SVG
| sprites? Well, that can very easily be a separate script
| which I can debug independently and _not_ couple into my
| builder's plugin system.
|
| In addition, now my JavaScript files are _actually_ just
| JavaScript and I can be pretty sure that it will work with
| _any_ new tooling without any problems. Once the successor to
| ESBuild comes out I will most likely be able to point it at
| index.js and everything will work.
| acdha wrote:
| > In addition, now my JavaScript files are actually just
| JavaScript and I can be pretty sure that it will work with
| any new tooling without any problems.
|
| That's been my feeling for years, too: if your team is less
| than, say, several dozen people there's a significant
| amount of merit to having something which doesn't require
| continous care and feeding for anyone to work, especially
| when it's combining a number of complex libraries with
| independent development teams.
| fiddlerwoaroof wrote:
| I'd like to see non-CRA numbers: I've found that a simple React
| + Webpack 5 project is not as bad to get off the ground as it
| used to be.
| amasad wrote:
| I'm sure it's less disk space because it has less deps but
| the most of the RAM and CPU usage in CRA is Webpack so I'd be
| surprised if that changed much.
| fiddlerwoaroof wrote:
| I'd like to see the numbers: the webpack config CRA eject
| gives you is a monster.
| mumphster wrote:
| webpack AND all the extra plugins and preprocessing and
| postprocessing CRA adds -- its not a small webpack setup by
| any means and you can get 1s build times with webpack
| pretty easily without CRA
| bavell wrote:
| Agreed, I use webpack for small and medium projects and
| it's basically instant. I use TS but not the compiler - I
| tell babel to strip types and use just a few plugins,
| transforms and loaders.
|
| I'm not in love but it's a core tool in almost all of my
| projects, personal and professional.
| wildpeaks wrote:
| Exactly: 99% of the time, "webpack is slow" is just code for
| "I have Babel in my toolchain" and forgetting to set ts-
| loader as "transpile only".
|
| Personally I removed it years ago, and Webpack 5 even allowed
| me to get rid of more loaders now that there are Assets
| Modules that automatically detect assets and webworkers using
| the "new URL()" syntax, and Typescript does everything else I
| need.
| joshxyz wrote:
| I can remove babel in my code?
| fiddlerwoaroof wrote:
| It depends on your target platform: ES6 modules are
| basically supported in every browser I care about, so the
| major reason for Babel is JSX
| fiddlerwoaroof wrote:
| The new URL() thing is amazing
| netghost wrote:
| Can someone clarify what the new URL() thing is?
| __s wrote:
| https://webpack.js.org/guides/asset-modules
| fiddlerwoaroof wrote:
| this is the release notes for it:
|
| https://webpack.js.org/blog/2020-10-10-webpack-5-release/
| #as...
| protonimitate wrote:
| This is informative.
|
| How is the configuration overhead? Is it relatively easy to get
| Vite + a custom react app template + tsx + testing up and
| running?
|
| CRA is bloated, but still one of the fastest ways to get a
| "full app" up and running with React.
| amasad wrote:
| I don't think Vite has a testing story yet. As for the rest,
| yes, it totally is straightforward. We only had to change one
| line of configuration in the base template for it to work on
| Replit. See https://replit.com/@templates/Reactjs
| mariusmg wrote:
| >Super excited about the future of JavaScript tooling ecosystem
| with more focus on efficiency and speed.
|
| Well they can't get worse than now... 234mb for a friggin hello
| world app
| koolba wrote:
| It's more of a hello import the world.
| spoiler wrote:
| It's worth noting that the tooling and build systems are that
| big. They include type definitions, binaries, scss
| preprocessors, typescript compiler, linter, and a lot of
| other tools to enhance DX. Some of them might include other
| non-code resources.
|
| The hello world app is _not_ going to be this big.
| ng12 wrote:
| Would you count the size of the JVM when you do Hello World
| in Java?
| [deleted]
| hombre_fatal wrote:
| You could, since it's a runtime dep. But a better
| comparison would be to the client dev tool chains in other
| ecosystems, like Xcode (11GB), though still not very
| interesting. Turns out client dev is hard and it doesn't
| make much sense hand wringing over dev tool size metrics.
|
| Better to look at how well they solve their problem space.
| Scarbutt wrote:
| No because they are not counting the size of the browser or
| nodejs
| larrymyers wrote:
| I tried out both snowpack and esbuild recently, and while the
| approach of using es modules was neat, these tools are still
| wildly immature compared to webpack.
|
| Need to handle non-js assets in your bundle? Need to integrate
| into both node and browser environments?
|
| You should stick with webpack. Any time you lose waiting for
| webpack to run you will get back 10x over by not fighting with
| your tooling because it doesn't handle a set of use cases you
| have.
|
| I'm sure the next generation of build tools and bundlers will
| mature over time and we'll all get to enjoy the benefits of es
| modules, but right now webpack's mature plugin ecosystem,
| documentation, and stability makes it my default choice.
| throwaway894345 wrote:
| > Any time you lose waiting for webpack to run you will get
| back 10x over by not fighting with your tooling because it
| doesn't handle a set of use cases you have.
|
| Generally I think this is good advice for tools--stick with the
| mature thing. But my former company's webpack builds were 30+
| minutes for a relatively simple site. No doubt something was
| misconfigured, but you really have to be a webpack expert to
| get any sort of insight into where the time is going, and even
| then it may not be especially actionable (or at least not
| obviously so). In our case, we were using a monorepo and we
| didn't have something like Bazel, so this was painful for
| backend engineers, data scientists, etc--not just frontend
| engineers.
|
| Maybe our case was pathological, but we would have saved a ton
| of time moving to esbuild and building whatever additional
| features we needed from scratch.
| theon144 wrote:
| Your experience mirrors mine to a letter - I appreciate the
| wide variety of use cases that are covered by Webpack (a
| number of which are crucial to our build process), but its
| performance is abysmal (20m+ on CI) and totally inscrutable;
| making the potential switch from it rather enticing.
|
| Especially as seeing that there is no good solution (but a
| lot of attempts at them), I feel it somewhat points to this
| overcomplexity being a problem central to Webpack.
| willhoyle wrote:
| > my former company's webpack builds were 30+ minutes for a
| relatively simple site
|
| I'm genuinely curious what simple site would cause a 30+
| minute build? Is it just one of those things that grow over
| time?
| throwaway894345 wrote:
| I wasn't a frontend developer, so I'm not familiar with the
| details, but it seemed to be pretty slow from the start,
| but compounded as our app grew in size. I.e., there was
| some large coefficient associated with our web pack
| configuration.
| vaughan wrote:
| I feel like there just needs to be a good plugin that gives
| you proper stats as to how long things are taking and tips to
| improve things.
|
| It's usually slow css loaders, or too-inclusive patterns for
| loaders ending up processing node_modules, and not good
| enough disk caching.
|
| There is a plugin called smc to monitor loader execution
| time.
|
| Dll plugin was the best speed up to avoid recompiling things
| that don't change, but now module federation is suppose to be
| a better solution. Disk caching in v5 will also do great
| things.
|
| Thing is, it's so complicated to setup, and debugging it
| involves so much config tweaking ans waiting.
|
| I think we are a few years out from when we have nice speedy
| builds in webpack with good abstractions.
|
| But then it's a question of whether people move away from
| webpack because we don't need all the plugins and
| transpiration and want native compile speeds.
|
| One thing for certain though is the hype cycle will continue
| on...
___________________________________________________________________
(page generated 2021-04-28 23:00 UTC)