Esbuild 0.9 • Hacker News Board

Re: Esbuild 0.9

#111

Post by jayair » Wed, Mar 10, 2021, 3:39 AM UTC

kraig wrote: post #63

jayair wrote: post #57

We love esbuild and we use it internally for SST https://github.com/serverless-stack/serverless-stack . The work Evan does is seriously impressive.

as a heavy user of CDK, sst looks pretty cool. i'm curious why you didn't go the direction of adding this functionality to CDK directly? i'd like to use some of the functionality in here like live lambda development, but i also don't want to take on converting my org's already built CDK extensions and deal with migrations.

Thanks!

We had to change the build process of Lambdas to support deploying a mock version of the function. And we need to add a new command that deployed the debug stack.

Here's how it works internally — https://docs.serverless-stack.com/live-lambda-development

Your existing CDK app should work with SST. The main difference is that SST deploys per stage (or environment). This allows you to do `sst start` that goes to one environment and `sst deploy --stage prod` that goes to another.

Re: Esbuild 0.9

#112

Post by dota_fanatic » Wed, Mar 10, 2021, 4:26 AM UTC

RussianCow wrote: post #104

dota_fanatic wrote: post #73

Earlier quoted context omitted.

> unless you have two monitors Or have your editor and browser window tiled next to each other? Given how often FE development dabbles with design, using at least one decently sized monitor seems requisite. And aren't FEers generally tweaking design in the DOM via a browser's developer tools when they're not sure what they want yet, copying back over into source once the design is finalized? Seems downright unpleasan…

It's often much faster to make the change in the code directly than in the dev tools. For instance, I can very quickly apply a LESS mixin to an element, which would require knowing and making those specific changes to the raw CSS via the browser. The same goes for pretty much anything that's more than a one-value change.

Yes, I agree for what you’re describing, but that’s not the scenario I was referring to: the one where you don’t know how far over, how tall, how opaque, etc something should be and there’s no existing pattern to reach for off-the-shelf, like a mixin. Iterative exploration of design space.

Re: Esbuild 0.9

#113

Post by brendyn » Wed, Mar 10, 2021, 4:27 AM UTC

wdb wrote: post #48

btd wrote: post #9

Earlier quoted context omitted.

you know about swc right? https://swc.rs/

Yes, but a bunch of the Typescript support is closed sourced . No idea, if that's important for you.

It's important to me. Could you please link me to where these nonfree bits are?

Re: Esbuild 0.9

#114

Post by nXqd » Wed, Mar 10, 2021, 4:40 AM UTC

This is an amazing work :)

Re: Esbuild 0.9

#115

Post by Sephr » Wed, Mar 10, 2021, 6:02 AM UTC

When can we have const back? At some point esbuild started to transpile all const/let/var statements to var, which can potentially cause a slight performance decrease in some hot code paths (or at least a slight memory usage increase as noted in https://stackoverflow.com/a/52749016/78436).

Re: Esbuild 0.9

#116

Post by windowojji » Wed, Mar 10, 2021, 6:07 AM UTC

Sephr wrote: post #115

When can we have const back? At some point esbuild started to transpile all const/let/var statements to var, which can potentially cause a slight performance decrease in some hot code paths (or at least a slight memory usage increase as noted in https://stackoverflow.com/a/52749016/78436 ).

Can you elaborate on this? const and let should be interchangeable from a performance perspective because it's not like the engine needs your input to know whether a binding is reassigned ever (that's a fundamentally easy thing for a compiler to check) so I must conclude that you're seeing performance benefits from using block scoped variables with TDZ that disappear when you use function scoped variables with var?

Re: Esbuild 0.9

#117

Post by taspeotis » Wed, Mar 10, 2021, 6:29 AM UTC

EMM_386 wrote: post #50

qbasic_forever wrote: post #37

The JS & frontend world is _seriously fun_ right now. If you blew it all off as a quagmire of complexity, sketchy engineering, treadmill of tools, etc... it's time to re-evaluate everything. I have more fun and feel more productive working on modern frontend stuff with tools like esbuild than any other GUI programming I've done in 30 years.

I agree. I was a web developer in the 90s when stuff was primitive, ugly and difficult. I switched to desktop .Net development in 2001 did that for almost 15 years. Since then I have been back on the web. I am full-stack so I find myself switching between front-end and back-end frequently. I am enjoying my time more in the world of TypeScript, VS Code, and Angular than I am writing the back-end REST APIs in .Net Core…

If you have the resources available to you (e.g. your employer is willing to pay) Rider is an excellent alternative to Visual Studio. It should make backend dev more enjoyable.

Re: Esbuild 0.9

#118

Post by [deleted] » Wed, Mar 10, 2021, 6:38 AM UTC

windowojji wrote: post #116

Sephr wrote: post #115

When can we have const back? At some point esbuild started to transpile all const/let/var statements to var, which can potentially cause a slight performance decrease in some hot code paths (or at least a slight memory usage increase as noted in https://stackoverflow.com/a/52749016/78436 ).

Can you elaborate on this? const and let should be interchangeable from a performance perspective because it's not like the engine needs your input to know whether a binding is reassigned ever (that's a fundamentally easy thing for a compiler to check) so I must conclude that you're seeing performance benefits from using block scoped variables with TDZ that disappear when you use function scoped variables with var?

[deleted]

Re: Esbuild 0.9

#119

Post by saagarjha » Wed, Mar 10, 2021, 10:49 AM UTC

brundolf wrote: post #40

earthboundkid wrote: post #31

Earlier quoted context omitted.

Good engineering is definitely key, but I think interpreted languages are a bad fit for developer tools (though they are extremely popular for writing developer tools). On the surface, writing JS tools in JS is good because hey, you definitely know JS, right? But in practice it is bad because I don't want the JS I am writing in any way constrained by the JS you wrote. The problem with any interpreted language is that…

Would I be right in guessing that most of your experience with dynamic languages comes from Python? 1) Modern JITed JS is fast. It's closer to Java than it is to what we typically think of as "interpreted languages". 2) "something like their intended versions to be present in the right locations on disk"; Node packages really just depend on the user having a new-enough install of Node and NPM, somewhere in the path.…

> Modern JITed JS is fast.

The caveat here is that it's not nearly as fast for code that isn't properly warmed up, even in the face of herculean efforts to make it so.

Re: Esbuild 0.9

#120

Post by FlashBlaze » Wed, Mar 10, 2021, 2:17 PM UTC

afavour wrote: post #22

AbuAssar wrote: post #6

esbuild makes it pretty clear that writing the JS ecosystem in JS is a bad choice*. now we need to rewrite tsc/babel/npm/eslint/etc... in a language that compile down to native binary that is also cross platform (like go or rust), to gain the same performance improvements across the entire JS tool-chain. * based on the benchmark on their landing page.

I don’t know about that. Just look at the performance difference between NPM and Yarn: both built with JS, but for me at least Yarn is way, way faster. I’m sure it would make sense to rewrite certain things in Rust or Go (then possibly pull them into Node as native modules) but they’re not magic. Good engineering will win out no matter what.

Agreed regarding yarn and npm comparison. During my development of React Native, I was using Yarn and I was blown away at the rate of installing the packages. Since then, I've pretty much used yarn over npm for all my React and React Native projects.