Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Esbuild – An extremely fast JavaScript bundler

esbuild.github.io

Post reply on HN
Print view View original

51–60 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

#51

Post by lstamour »

tiew9Vii wrote: post #45
phillu wrote: post #26

I'm using this to compile typescript lambda functions for AWS with great success. Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.

I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors. Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradic…

This is pretty common if you're looking for build performance. E.g. typecheck as a lint step with tsc, build with babel removing your typescript (it doesn't typecheck either), etc. It's true that tsc on its own can replace a build step for some folks, but you'll quickly find it limiting both in the options to rollup or combine files and in its ability to be extended with plugins (unlike Babel), etc. On the other hand, tsc and its language server is a first-class type-checker when run with no-emit. ;-) I haven't played as much with esbuild yet but it's on my todo list.

Re: Esbuild – An extremely fast JavaScript bundler

#52

Post by onion2k »

kohlerm wrote: post #3

That's old news or? For complex projects moving to esbuild from say Webpack is not necessarily easy.

For complex projects moving to esbuild from say Webpack is not necessarily easy.

Why would things be easy in a complex project? If you've built complexity into your project it seems a little unreasonable to expect someone else's tool to fix that for you. At some point you need to accept that building things that are simple is your own responsibility. But building things that are simple is incredibly hard so don't be too down on yourself if your project is complex. Software complexity is like entropy; it's very easy to add complexity to a system, and very hard to remove it.

It's also worth noting that you probably don't really want a tool to make your complex project appear more simple. That would only hide the complexity from you, but it would still be there. If your project is complex then your best approach to solving that is a lot of documentation, a lot of testing, and a lot of refactoring.

Re: Esbuild – An extremely fast JavaScript bundler

#53

Post by Vinnl »

tiew9Vii wrote: post #45
phillu wrote: post #26

I'm using this to compile typescript lambda functions for AWS with great success. Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.

I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors. Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradic…

Consider TypeScript like a linter. ESBuild doesn't run ESLint for you either - you can run it separately, or in parallel.

This means that for example, during development, you can see your running code quickly, while your editor runs tsc to highlight type checking errors. And in your build system, you can produce a production bundle to test while in parallel checking for type errors.

Re: Esbuild – An extremely fast JavaScript bundler

#54

Post by albertgoeswoof »

hit8run wrote: post #21

What do you think of the importmap approach propagated by dhh on rails 7?

the only problem with this is that it's an option.

As a rails dev, I want one, strong opinion on what the default/best approach is. I don't want to configure anything

Re: Esbuild – An extremely fast JavaScript bundler

#55

Post by satvikpendem »

See also SWC, something similar to esbuild but written in Rust. NextJS uses SWC as well as Deno.

Rome is also being rewritten in Rust, it's more of a complete set of packages that subsume Webpack, Babel and all the other parts of the JS / TS development experience.

Re: Esbuild – An extremely fast JavaScript bundler

#56

Post by o_m »

satvikpendem wrote: post #55

See also SWC, something similar to esbuild but written in Rust. NextJS uses SWC as well as Deno. Rome is also being rewritten in Rust, it's more of a complete set of packages that subsume Webpack, Babel and all the other parts of the JS / TS development experience.

The announcements from NextJS has been really confusing. I don't think they are using SWC yet. They are just working on it. The reason for the confusion is because they write about the progress in the release notes, making it look like they are using it.

Re: Esbuild – An extremely fast JavaScript bundler

#58

Post by cute_boi »

o_m wrote: post #56
satvikpendem wrote: post #55

See also SWC, something similar to esbuild but written in Rust. NextJS uses SWC as well as Deno. Rome is also being rewritten in Rust, it's more of a complete set of packages that subsume Webpack, Babel and all the other parts of the JS / TS development experience.

The announcements from NextJS has been really confusing. I don't think they are using SWC yet. They are just working on it. The reason for the confusion is because they write about the progress in the release notes, making it look like they are using it.

May be in next release we get swc in nextjs?

Re: Esbuild – An extremely fast JavaScript bundler

#59

Post by wruza »

truth_seeker wrote: post #33
nsonha wrote: post #29

Earlier quoted context omitted.

what is the point of the comment? It reads: I have an opinion (and here it is, but who gives a shit if you don't elaborate)

I don't think context (JS build tool) is missing here. If someone has open mind, they can also google what is Parcel.

“What is” is a vague question with no clear details in the answer. For example, parcel may have the middleware mode while esbuild may not. But then it’s parcel 1, but not 2, where it was removed to streamline plug-in development, so I better stick with 1 for a while. That is the context. By not providing it, the root comment has zero value, because an interested reader cannot learn at least some of the whys by simply reading the frontpage. Almost everyone knows it and thus will not follow your “open mindness” advice, because it’s pointless in this case.

Re: Esbuild – An extremely fast JavaScript bundler

#60

Post by kitd »

tiew9Vii wrote: post #45
phillu wrote: post #26

I'm using this to compile typescript lambda functions for AWS with great success. Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.

I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors. Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradic…

Practically, it isn't an issue if you use VSCode which has the Typescript language server built in to catch type errors for you.

If you want, your build script can include

  `tsc -noEmit`
to type check before the build.
Post reply on HN