Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What an ambitious project, I love it.

> Longer-term, bun intends to replace Node.js, Webpack, Babel, yarn, and PostCSS (in production).

https://github.com/Jarred-Sumner/bun#limitations--intended-u...



I love these super-ambitious projects (see Parcel, Rome.js) because after several years they will still fail in many areas at once!

> Rome is a formatter, linter, bundler, and more for JavaScript, TypeScript, JSON, HTML, Markdown, and CSS.

> Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Haven't seen it since.

> Parcel: The zero configuration build tool for JavaScript, CSS, HTML, TypeScript, React, images, SASS, SVG, Vue, libraries, Less, CoffeeScript, Node, Stylus, Pug, Electron, Elm, WebGL, extensions, GraphQL, MD

As long as you do the bare minimum for each target.


One of the things that makes frontend dev a nightmare is having to wrangle so many different tools and configurations to build a site, even a simple one. The only next step to improve the situation is all-in-one tools. We're lucky that people are trying to tackle this hard problem.


parcel is great, I always use it for personal project and it works pretty well

Normally I start with something else (webpack, rollup, whatever happened to be there with the example I'm starting from), then when I hit some roadblocks I just parcel index.html and I have something working.


Parcel is great, until it isn’t. I regularly try to switch to Parcel and it’s just impossible on larger projects. If you start with parcel, great! (maybe, as long as you just need to bundle 2 modules and that’s it)


Oh that's all, okay, haha.


Webpack, Babel, yarn, and PostCSS

Something has done a bit wrong if you're running any of those tools in production.


What do you mean? Those are incredibly common tools for production builds.


You don't use them in production though. Your code is built in a pipeline somewhere using those tools, typically CI/CD, and then the artifacts from that process are what gets deployed to production. If you're actually running Webpack on a production server then you're doing something very unusual.


They are part of the production build pipeline. You need them to have the final product.


That's not what anyone means when they say "in production" though. When people talk about things being "in production" they mean "on a production server".


No, what most people mean when they say "in production" is "in a real project" in the sense that it is or will be published and used. It means something that is more than a demo / PoC / etc. You're being so ridiculously pedantic it's shocking.


No, what most people mean when they say "in production" is "in a real project" in the sense that it is or will be published and used.

Most companies have things that run "in dev", "in staging", "in CI", and "in production". These map directly to some tools - for example, React has "development" and "production" modes. When someone says a server or a database or a tool is used "in production" they're usually referring to the live environment that users access. Most people use tools like Webpack locally to run code when they're doing dev work, and in CI to build things. If someone said to me "We're running Webpack in production" then I would have questions.

If you use "in production" to mean "anywhere in a project", then how do you differentiate between a staging environment and a production environment? Do you talk about "the staging environment that's in production"? That would be confusing...


You're being absurdly pedantic


So then it's accurate to say that no one uses TypeScript in production??




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: