314 karma · joined October 30, 2013
* By using a singleton you're not able to easily test different LocaleData contexts in parallel.
* By using a singleton you're not able to make your NodeJS server deal with users with different locale settings because you have only one global instance. Multiple requests arriving at the same time would corrupt each other. You could spawn a separate process for each locale but that's inconvenient.
Does that make sense?
> making them less transparent to readers of the codebase
Sometimes that's exactly what you want. It's the same as hiding CSS styles behind a set of props like `<Button buttonStyle="primary" buttonSize="large">Continue</Button>`. It actually makes your codebase much safer by reducing the combination of props and values you're able to pass.
See https://news.ycombinator.com/item?id=27031847 for more reasons.
import someFunc from 'someFunc';
// ...
return someFunc();
import SomeComponent from 'SomeComponent';
// ...
return <SomeComponent />Now, wishful thinking is about making it work even if not perfect, production-ready. It could be about rendering a hard-coded "Loading..." or "Success" or "Error" string before you hand it over to your translation team. Or just calling your param names `a` and `b` before you talk to your domain experts about the proper terms. This comes with experience.
This is not something the author invented, it's a well-known technique.
Another benefit of components is lifecycle. Imagine a "RelativeTime" component; you could have called library functions directly to render "20s ago", but by making it a component you could tell it to update periodically. Cool stuff.
Now, I understand that having such granular components can lead to some performance overhead if you're working on a massive application. If only there was an easy way to do AST transformations that would hoist small stateless components/hooks. Damn, AST transformations could even hoist stateful ones! I'll keep dreaming about it :)
In regards to examples such as `Fetch`, `UserRead` and `EntityActionDelete` from the post, I'm kinda on the fence because, at the same time they are uglier than hooks, they're also more performant because updates would only re-render itself and its children, and not the entire parent component. There's no right or wrong here.
I stay in the best neighbourhoods around the world, walk to coworking spaces, eat out almost every meal and still spend considerably less than what I did in Sydney.
vite-plugin-ssr can't even be integrated with Vue Router (I saw you're working on deep integration though). They're both very rigid, early stage endeavours. [2] What happens, for ex, if you used nested lazy components in those pages, are they going to be included in the server render as well?
I mean, fair enough that there are people trying to do better, but it's extremely hard to find the right abstractions for such complex builds and Webpack is definitely on top here.
[1] https://github.com/sveltejs/kit/blob/5c2665ff2280947a2fc6001...
[2] https://github.com/brillout/vite-plugin-ssr/blob/master/src/...
It looks like it shouldn't have been approved in the first place then.
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, and did some witchery): 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.
* 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.
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.
* 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...
I love esbuild though, and use it a few of our packages, it flies