281–290 of 331 posts
Earlier quoted context omitted.
Vite uses it under the hood and has it running crazy fast.
I think Vite only uses it for the production build, no? As far as I know Vite doesn't do bundling (yet) in dev mode.
Does it have module federation?
These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever type…
Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because,…
This is the point folks really must understand when setting up a new tooling pipeline to deal with TypeScript. Certainly all of the module bundlers I'm aware of operate in this way.
To explain further for anyone curious; for TSC to work effectively it must construct and understand the entire "compilation". To do this it starts by performing a glob match (according to your include/exlude rules) to find every TypeScript file within the project. Resolving and type checking the entire compilation every time the bundler calls for a transform on a file is very slow due to lots of repeated and unnecesssary work so most TS bundler plugins have to work around this. Unfortunately, they're still relatively slow so type checking and bundling code separately is often the best way to go.
Earlier quoted context omitted.
By my count its 23 years. The biggest issue in FOSS is folk don't wanna join a "good enough" project and move it. Sometimes the project is contributor hostile (rare?) And we end up with basically: "I'll build my own moonbase with blackjack and hookers!" All that starting from scratch costs loads of impossible-to- recover-time.
Well, that's what is really frustrating here. Turbopack is built by the creator of Webpack. So, instead of fixing the bloated megalith that webpack has become, they are just moving on to greener pastures. But this time it'll be different™
Megalith? Isn't it super modular and configurable?
Earlier quoted context omitted.
Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because,…
>Running the typechecker independently of the bundler is really common in TypeScript maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking an…
Awesome!
> but half the time it's broken because it didn't do any type checking and you have to wait for the IDE based type checker anyway. On every build.
Huh? The IDE checks your types as you type. Not on every build.
This works great and de-duplicates effort. I have an extra "check" script that runs all the linters including the Typescript checker that you can run before making a PR or production build (tells you the same thing as the IDE). I'm glad it doesn't block my development build because it takes many seconds (10-20) while without it you can get updates in far below one. That's a night and day difference.
> you never want a fast, silently broken build which is what you get with non-typechecked fast builds.
You're misinformed about what I want. I want fast builds. Decoupling linting from building is a great way to achieve that. I am yet to experience any problems with it.
If you want to type check on every build you can put that into your pipeline, but it will unnecessarily slow things down. I for one am very happy with fast builds with no downside.
Earlier quoted context omitted.
Thats not how one usually work. Whats the point in running tsc (the official transpiler) on each save? Plus, you are using an LSP client right? right?? Im a user of esbuild, and its so fast it can recompile on each save (see esbuild `serve` option) and i wont notice anything locally. Theres also a watch mode, and production build with minify. So i work locally without a typecheck for my builds, and let my LSP client…
I recompile on every save too, all with full typechecking in under a second. As I've suspected, this is probably because most people here work in bigcorp projects where there are so many thousands of files that you cant work like this anymore. It's not because it's actually better workflow wise, it's only better for you now because otherwise the compilation is too slow. Same as the situation that has developed with R…
This is not a bigcorp thing. The Typescript compiler starts becoming annoyingly slow much earlier. I have a project that's one 2000-line TS file that already takes 1.5 seconds to compile. Not yet slow enough to be frustrating, but ridiculous for the amount of code.
After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the bro…
Parcel felt really fast, zero-conf and “opinionated” in a good way. But I’m still searching for a zero-conf full-stack pipeline which could manage both frontend and backend in a single project under a single watch command, with modules shared across sides. This frontend/backend separation is too alien to my idea of development (coming from desktop programming), and it feels like some artificial border. Thankfully, No…
https://m.youtube.com/watch?v=oCiGjrpGk4A
but more importantly, I recommend embracing the frontend-backend separation. it's important in desktop contexts too. after all, you don't want to block the UI thread with waiting for I/O, right?
of course the last ~2 decades were about coming up with various hacks, workarounds, solutions to make the whole threshold easier to pass (from Java applets to Ajax/XHR, comet/long-poll, websockets, server sent events, localstorage, WebSQL, WASM, service workers, and so on), but the basic architectural separation of concerns remains.
...
regarding sharing things between frontend and backend: OpenAPI + openapi-generator; monorepo works okay in VSCode, etc.
many people opt for RoR-like frameworks where they don't have to write frontend JS if they can avoid it (see also htmx)