If they can come close to the beauty that is esbuild documentation, changelogs and focus on details it'd be interesting, but do we really need another tool that only touts performance and ignores the rest?
Turbopack, the successor to Webpack
301–310 of 331 posts
Re: Turbopack, the successor to Webpack
#302Earlier quoted context omitted.
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.
Vite uses both esbuild and rollup for the prod build. When doing React, it also adds Babel. This chaining of tools is the reason why it's so slow.
"so slow." JS-perf world is quite insufferable. We're talking 0.09s vs 0.01s https://mobile.twitter.com/youyuxi/status/158506616237077709...
Re: Turbopack, the successor to Webpack
#303After 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…
> 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
I did create a proof of concept how this could be done in parcel https://github.com/mochicode/parcel-fullstack-poc.
The /src folder contains:
1. /api => backend
2. /app => react frontend
3. /shared => shared code
Once everything is installed, just run "npm start" and it will:
1. build and watch your src folder
2. react hmr/fast-refresh works
3. nodemon will reload your node server when things change
4. serve your react app on localhost:8000/frontend, currently hard coded, but I could also load this from the package.json file.
Not zero-config, but it almost gets you there.
Re: Turbopack, the successor to Webpack
#304Earlier quoted context omitted.
Currently looking at a 1000 line webpack config..........
What does your 1000 line webpack config do?? I think part of the problem with webpack is it gives users the freedom to create 1000 line configs even though they’d be fine with a smaller more simple config
Problem with webpack is that freeform JS code is not "configuaration". Configuration presumes set amount of features driven by declarative statement.
Most of what I've seen done "in Webpack" in fact is shitty scripting in an awful language. I'm very happy to see movement away from this criminal waste of everyone's time.
Re: Turbopack, the successor to Webpack
#305After 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…
I just spent an entire evening a few days ago trying to make Parcel work for a new project and I just couldn't get it to spit out working js and css. The project is just a small server rendered web app (using Crystal) that I wanted to add papercss, trix, hotwire/stimulus and hotwire/turbo to (using yarn). Anyway, I never got it to output the css for papercss or the js for trix. Webpack on the other hand, I had workin…
IMO where Parcel shines is when you are building client side single page apps or JS/TS libraries.
I could see that it won't be the right tool for a multi page server rendered app.
Re: Turbopack, the successor to Webpack
#306Earlier quoted context omitted.
My disappointment related to this is that I still think Snowpack's philosophy was the right one for JS present and especially for JS future: don't bundle for development at all because ESM support in today's browsers is great and you can't get better HMR than "nothing bundled"; don't bundle for Production unless you have to (and have performance data to back it up). I know Vite inherited the first part, but I still m…
Vite is driven by pragmatism. They are bundling for prod because it is pragmatic. If they do not bundle for prod, then initial load will cause a flood of network request and cause slowness due to a lot of network requests
I thought http2 made the network requests a non-issue (at least for 100 files or so). The only advantage of the larger bundle is though compression.
Re: Turbopack, the successor to Webpack
#307Earlier quoted context omitted.
Rails also has a whole model/database thing going on. Next.js is just front end focused and has always left it up to the user to decide about data persistence. So to answer the original question, an equivalent would be Next+Database, and there is obvious stand-out answer for what Database should be. I often get stuck deciding what that Something should be when trying to go from 0 to 1.
Okay, great, I'll just use Next.js with PostgreSQL.
If you know and like Rails and ActiveRecord especially, then one possibility, which I intend to try on my next thing, is to build an API-only Rails app (JSON only; no HTML views) and a separate Next.js app that uses the Rails app as its backend. Although it’s two apps, it seems like it would be a really nice, clean setup to work with. You can easily deploy the Next app on something cheap and serverless like Vercel, and deploy the Rails app separately on something like EC2 or Fly.io.
I have written Next apps that just connect directly to PostgreSQL, but I always end up adding other tools in an attempt to recreate something like ActiveModel and other aspects of Rails in Next.js, and it ends up turning into a mess. I think Rails+Next would avoid this problem. It would be two apps, but each would very clearly focused and would be built following the golden path of their respective frameworks. (One thing I’m not sure about yet is how I would DRYly share endpoint schemas from Rails in order to have strong typings in the Next app based on the API endpoints. But I don’t think it should be too hard to find a nice way to do this.)
Re: Turbopack, the successor to Webpack
#308Earlier quoted context omitted.
What does your 1000 line webpack config do?? I think part of the problem with webpack is it gives users the freedom to create 1000 line configs even though they’d be fine with a smaller more simple config
Problem with webpack is that freeform JS code is not "configuaration". Configuration presumes set amount of features driven by declarative statement. Most of what I've seen done "in Webpack" in fact is shitty scripting in an awful language. I'm very happy to see movement away from this criminal waste of everyone's time.
Not gonna get into the details, as it's company proprietary code, but we aren't talking about a weekend project. This is a large, complex product that has a significant user-base, and it also has to handle a bunch of legacy stuff.
Re: Turbopack, the successor to Webpack
#309Earlier quoted context omitted.
Problem with webpack is that freeform JS code is not "configuaration". Configuration presumes set amount of features driven by declarative statement. Most of what I've seen done "in Webpack" in fact is shitty scripting in an awful language. I'm very happy to see movement away from this criminal waste of everyone's time.
Not gonna get into the details, as it's company proprietary code, but we aren't talking about a weekend project. This is a large, complex product that has a significant user-base, and it also has to handle a bunch of legacy stuff.
Sure, I did not mean you are doing something bad. I just happen to hate JS and Webpack with passion ;)
Re: Turbopack, the successor to Webpack
#310Earlier quoted context omitted.
Not gonna get into the details, as it's company proprietary code, but we aren't talking about a weekend project. This is a large, complex product that has a significant user-base, and it also has to handle a bunch of legacy stuff.
Sure, I did not mean you are doing something bad. I just happen to hate JS and Webpack with passion ;)
No worries! I like js, I'm just feeling the pain of trying to move off webpack.