[HN Gopher] Esbuild 0.9
___________________________________________________________________
Esbuild 0.9
Author : swyx
Score : 170 points
Date : 2021-03-09 14:57 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| FlorianRappl wrote:
| I would love to switch to esbuild, but unfortunately some basics
| are still not in there. I read some people switched, but I wonder
| how they have projects requiring 30+ seconds when not utilizing
| bundle splitting. Maybe I am missing something... Are you
| outputting esm files or what?
|
| Would be great to get some insights how people are mitigating the
| lack of bundle splitting in non-esm output right now. Thanks!
| uses wrote:
| I tried this a week or so ago, and it was indeed 100x or 1000x as
| fast as my webpack setup. Shocking, really. I couldn't get
| dynamic imports / code splitting working, which seemed to not be
| fully implemented yet. I also wasn't sure how to make polyfills
| happen.
| carwyn wrote:
| How does this compare to https://www.snowpack.dev/ ?
| picardo wrote:
| Snowpack is a bundler, not a build tool. It works with a
| variety of file formats, and it uses esbuild to compile JS/TS
| assets.
| bpierre wrote:
| SnowPack is more of an all-in-one kind of tool (with dev
| server, HMR, etc.). Also it uses esbuild internally :-)
|
| https://www.snowpack.dev/guides/optimize-and-bundle#option-1...
| [deleted]
| qbasic_forever wrote:
| Snowpack uses esbuild internally now, there's a good rundown of
| it and other awesome snowpack features like streaming imports
| in their 3.0 release announcement:
| https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0
| arcatek wrote:
| We now use it to build Yarn, and it's been working very well.
| Still some rough edges that prevent us from adopting it at work
| (like the lack of dynamic imports when the import expression
| references variables), but I'm slowly making progress in
| implementing workarounds for that through loaders, and the first
| results are encouraging. At its worst, with a Webpack/Esbuild
| hybrid approach, we get at least 2x better perfs.
| nicoburns wrote:
| ESbuild is excellent for using with TypeScript and Node.js. We
| were previously using Nodemon to restart the server on changes.
| ESbuild is fast enough that rather than having to change our
| workflow and run a tsc --watch process in addition to Nodemon
| (which would be rather a pain given that we have 5-6
| microservices), we simply use ESbuild to recompile the entire
| service before restarting the code (it takes about 0.1 seconds to
| compile everything, so it effectively doesn't impact our workflow
| at all).
| madjam002 wrote:
| Amazing stuff, I was thinking of doing pretty much exactly this
| this morning.
|
| Out of interest, if you're bundling with Esbuild before
| running, how do you cope with native dependencies?
| nicoburns wrote:
| We don't use esbuild's "bundle" (--bundle) option, which
| means that our files get processed one-by-one and end up as
| separate files in the `dist` directory that we output to and
| that dependencies aren't processed at all and are just
| `required` like normal by our transpiled code.
|
| Our build command (in a bash script file to avoid string
| escaping issues) is: find src -type f \(
| -name '*.js' -o -name '*.ts' -o -name '*.sql' \) -print0 \
| | xargs -0 ./node_modules/.bin/esbuild --platform=node
| --format=cjs --outdir=dist --loader:.sql=text
| madjam002 wrote:
| Thanks for sharing, I've just given it a go with one of my
| larger projects and WOW!! Typescript incremental
| compilation was taking around 2 seconds on every save, then
| Nodemon would restart etc.
|
| I've plugged in Esbuild, I have used bundle mode though to
| see what it's like, it works fine if I external all of my
| node modules, it builds in 0.23 seconds (approx 350 source
| files in my project).
|
| Nodemon now watches for TS file changes and exec's the
| esbuild on every start.
|
| Thank you for the pointer to this as this will be a much
| needed productivity boost!
|
| I'll try bundling some node modules when I have some time
| but it will take more work as I use Yarn PnP (I've found a
| plug-in so will definitely try that)
| Kaze404 wrote:
| You can instruct nodemon to run "tsc" by itself when there are
| file changes, so you don't have to separately run tsc in watch
| mode.
| scaladev wrote:
| Hell yes, esbuild is an amazing tool. I not only use it in most
| CRA projects (where it replaces webpack and builds everything at
| least two times faster), but it's also easy to use for plain HTML
| pages to add some interactivity without writing thousands of
| lines of webpack black magic: esbuild App.tsx
| --define:process.env.NODE_ENV=\\\"production\\\" --bundle
| --minify --target=es6 --outfile=out.js
|
| where App.tsx is your entry point. Include out.js into the page
| and you're done.
| akhilcacharya wrote:
| This is exceptional - what's the downside when using it with
| CRA?
| lsmurray wrote:
| do you have instructions for integrating with cra
| scaladev wrote:
| Unfortunately it's not officially supported (as usual in CRA
| world), so you have to resort to one of the config rewriters.
| I've been using this0 and only had one problem with numeric
| enums in TypeScript. I don't remember the exact issue, but it
| was caused by my own stupidity, and was easy to fix.
|
| [0] https://github.com/pradel/create-react-app-
| esbuild/tree/main...
| picardo wrote:
| esbuild can be a good alternative to Webpack in some cases, but
| Webpack solves a lot of edge cases well. For example, just
| today I debugged an issue where a library had used `require` in
| an ES module instead of `import`, and that broke the build with
| esbuild. So I had to fork the library to fix that issue.
| Webpack handles that case without problems.
|
| I can think of at least a few cases like that where Webpack
| works better, but esbuild is (hopefully) going to catch up.
| It'd be ideal if Webpack and other bundler tools ditched their
| homegrown build tools and replaced them with esbuild.
| earthboundkid wrote:
| > Webpack solves a lot of edge cases well
|
| I would quibble with the word "solves". Webpack is a tool
| building tool. With Webpack, you can build a tool to solve
| your edge case problem, as long as you're willing to spend a
| lot of time and dig through random Github issues for your
| dependencies. Webpack itself however does basically nothing.
| [deleted]
| connor4312 wrote:
| > Webpack itself however does basically nothing
|
| This is not the case. I love esbuild and hope to see it go
| far, but Webpack does out of the box most of what esbuild
| (today) does as well, with the notable exception of
| TypeScript /jsx transpilation. For more advanced scenarios,
| like dealing with css modules, you do need plugins -- but
| esbuild doesn't support most of these scenarios today at
| all.
|
| It's like saying VS Code does nothing: you probably want
| extensions to help you out and let you do more complex
| things more easily, but it doesn't "do nothing" out of the
| box.
| encryptluks2 wrote:
| Love how this is used with Hugo:
|
| https://gohugo.io/hugo-pipes/js/
| earthboundkid wrote:
| Yes. When ESBuild came out, I made a feature request to get it
| added to Hugo, and I was surprised at how well it has worked
| out. Goes to show you should always open an issue!
| AbuAssar wrote:
| 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.
| brundolf wrote:
| One of the main benefits of Esbuild (if I recall correctly) is
| that all passes share a single AST. Whereas in a traditional
| setup your linter, transpiler, formatter, and sometimes even
| bundler and minifier all do their own totally independent
| passes on the source which means parsing it from scratch each
| time. So this would be a classic case of integrating everything
| into a monolith for a boost in efficiency.
| afavour wrote:
| 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.
| earthboundkid wrote:
| 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 to run the
| tool you need all the source and all the dependencies plus
| the interpreter in something like their intended versions to
| be present in the right locations on disk. This is a huge
| PITA, and if you're say writing JavaScript targeting ES5 but
| your tools are targeting ES2020 or vice versa, there can be
| painful yak shaving sessions getting everything on the same
| page.
|
| Essentially all developer tools should be static binaries.
| brundolf wrote:
| 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. Any dependencies that live on
| npm will install to the local directory to ensure against
| conflicts or permissions issues. The only exception I can
| think of is that occasionally (looking at you, node-sass)
| npm dependencies will have to do a native build of
| something and require a local C/++ compiler somewhere in
| the path. This is pretty rare in my experience, and isn't a
| super brittle dependency anyway.
|
| 3) "if you're say writing JavaScript targeting ES5 but your
| tools are targeting ES2020 or vice versa, there can be
| painful yak shaving sessions getting everything on the same
| page"; this really doesn't happen in any distributed NPM
| dependencies I've worked with. The great majority are
| written for the least-common-denominator of environments;
| if they use ES2020 internally, they'll do their own
| transpilation step to make sure you can use them in older
| environments. Also, "or vice versa" really doesn't apply
| because all ES versions are 100% backwards-compatible. You
| just need a Node version new enough to cover the newest
| features that any of your code or dependencies is using.
| Dependencies will be as compatible as they can be; your own
| code is under your control. Virtually never an issue.
| earthboundkid wrote:
| 1. My complaint is not about speed.
|
| 2. Node is much better than Python because the correct
| location on disk is pretty much project/node_modules.
| However, it is still that case that e.g. Babel was broken
| by Node 12.17.0 [1] last year, which necessitates
| something like NVM. I don't want to deal with that for my
| build tools. I just want a binary that is known to work
| to continue to work until it is replaced.
|
| 3. Yes, conventionally everything in Nodeland was written
| out to dist as ES5. This also sucks ass because now you
| end up shipping a bunch of ES5 crap to your end users
| even though you aren't targeting ES5. It is very hard to
| build an actual ES2020 module unless you're willing to
| not use external dependencies at all. Snowpack et al are
| shifting this slowly, but it has barely even begun as a
| trend.
|
| [0] https://nodejs.org/en/blog/release/v12.17.0/ https://
| www.google.com/search?q=babel+compat+data+corejs3+sh...
| arcatek wrote:
| Speaking of Yarn in particular since I maintain it, I
| strongly believe that more than speed we (package managers)
| need a good polish. And to do that, we need a community that
| feels empowered to make changes when they feel frustrated
| about something - which makes using JS / TS critical. By
| contrast, the UX of a bundler / linter is fairly
| straightforward (compared to Yarn's 46 builtin commands), so
| making external contributions easier isn't really necessary.
| deanclatworthy wrote:
| I think this comment undervalues the quality of engineering
| that Evan has put into esbuild. It's not only quick because
| it's written in golang, but also due to the decisions taken in
| architecture and an opinionated tool that does mainly one thing
| well.
| jakelazaroff wrote:
| I don't read OP as devaluing Evan's work. Presumably the
| TypeScript/Webpack/etc teams are also doing great engineering
| work -- but because they're writing in JS, the performance
| ceiling is significantly lower.
| christophilus wrote:
| I don't think so. I'd bet that a JS solution that followed
| esbuild's architecture would be in the same order of magnitude
| of performance.
|
| Now, you could argue that JS encourages complex, inefficient
| abstractions and over engineering and Go encourages the
| opposite. That, I'd believe.
| qbasic_forever wrote:
| 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.
| stefan_ wrote:
| Drag&drop building UI in Visual Whatever was plenty productive,
| hell they even had what the kids today call server rendering,
| and if it didn't look right I could always press F5 and see the
| result right there.
| Scramblejams wrote:
| Yep, I tried front-end way back and hated it. Can you mention
| some other tech that should be covered in my re-evaluation?
| qbasic_forever wrote:
| React & next.js are worth evaluating. It's a super powerful
| full stack with everything from server side rendered data
| (REST APIs even) all the way to complete client-side SPAs,
| all using the same react components. It's a slick little
| swiss-army knife that can make anything from a basic blog
| with markdown content, to a static marketing page, to a full
| client-first PWA experience. There is sadly almost nothing
| else really like it right now.
|
| MDX is another neat step, it's markdown + react components
| and fits in very well with next.js:
| https://github.com/hashicorp/next-mdx-remote
|
| Vue, and Svelte to just get an idea of what other components
| systems are like. They're all equally capable and just have
| different tradeoffs and styles. Keep an eye on Svelte in
| particular as its next.js-like system (SvelteKit) is working
| on a major revamp to be serverless-first and is quite
| interesting. Once you learn one component system it's easy to
| switch between them all--they're all cribbing and building on
| top of each other's ideas. The whole space is innovating in a
| great way.
|
| Web components are good to learn and compare to component
| frameworks above. It's still a changing space but points to a
| nice future where we can all just publish and share
| components.
| pandemic_region wrote:
| Yet none of the stuff you mention here will live beyond the
| next two years. Fun is as much as i would describe the js
| ecosystem, for more boring corporate use banking on these
| is the equivalent of getting a trojan horse in the
| application portfolio.
| asattarmd wrote:
| React was released in 2013, that's 8 years.
| Chris_Newton wrote:
| While that's true, code using React in 2021 often bears
| little resemblance to code using React in 2013, and the
| ecosystem around it looks very different too.
|
| It's easy to forget that hooks were only introduced in
| React 16.8, which was released just over two years ago.
| And yet today, if you visit popular forums for React devs
| like /r/reactjs, you'll find no shortage of people who
| will tell you that class-based components are ancient
| history and anyone who isn't using hooks for everything
| today is a dinosaur.
|
| This year, I've noticed a spate of online discussions
| about state management within the React ecosystem. Just
| like the hooks vs. classes debate of yesteryear, there is
| a striking contrast between those forever keen to do the
| new thing (sometimes using React's own context and hooks,
| sometimes using relatively new libraries) and those who
| prefer to rely on more tried-and-tested tech like Redux
| and MobX.
|
| In any situation like this, it's sensible to question how
| much real progress is being made, and how much of the
| change is just lost productivity due to churn in tools
| and "best practices". If so many developers think it's
| normal to swap out most of your tools and coding style
| every couple of years or less, you have to wonder how
| long they expect anything they ever build to be
| maintained for or how often they think longer-lived
| software should have big rewrites just to update the
| tools...
|
| In contrast, esbuild is shaping up to be an excellent
| tool. There seems to be a healthy focus on doing one
| common and important job well, it's _much_ better at it
| than the popular tools it potentially replaces, and it
| also seems designed to play nicely with others. It
| reminds me of the early days of 6to5 /Babel, actually.
| This is what we need more of in the front-end web dev
| community right now.
| qbasic_forever wrote:
| And I personally can't wait to see what amazing things
| the creators of these component systems will land on
| next...
|
| Next.js is pretty corporate-friendly. Very easy to split
| things up and have many folks and teams working on
| monoliths or services with it.
| johnfn wrote:
| React won't live past two years? What?
|
| I'd be willing to stake money on React, Vue, next.js and
| Svelte surviving at least 2 more years - roughly in
| descending order of probability, though all three well
| above 50%.
| wishinghand wrote:
| That's such an unqualified statement that I'd be
| embarrassed to say it out loud. Angular 1 apps are still
| in production. COBOL is still in production. I'd bet $100
| that two years from this date, all three of those are
| still popular, being used by enterprise, and have
| tutorials written for them on blogs or produced on
| YouTube.
| teryyy wrote:
| TailwindCSS, Svelte, and Snowpack are probably worth a shot,
| all pretty much bleeding edge
| 1_player wrote:
| The problem with front end development is that it's all
| bleeding edge and nothing that's stable and is improved for
| more than one hype cycle.
|
| Suggesting more bleeding edge tech is not a good argument
| to demonstrate that front end development got better.
|
| In my experience, it changed, it improved on many aspects,
| but it's still a pile of unstable crap running on the power
| of hype and over-enthusiastic junior engineers.
| qbasic_forever wrote:
| I get your frustration (and shared it a year ago), but
| you're really doing something like react a disservice by
| dismissing it like that as just hype. On the contrary
| react has evolved significantly over the years,
| introducing things like JSX (templating HTML + JS in the
| same file, now standard in every other component system),
| build tooling like create-react-app (zero config tooling,
| now standard in every JS build tool), functional
| component model with hooks (now copied by every other
| component library), and on the horizon stuff like server-
| side components. It has only gotten more stable, more
| proven, and easier to use over time.
| protoduction wrote:
| I'm really biased as I am building it myself: Starboard
| Notebook puts literate programming into the browser without a
| lot of magic.
|
| It's amazing what browsers can do these days without any
| build step!
|
| [0]: https://starboard.gg
| matt7340 wrote:
| I definitely agree with this in general, but there are
| exceptions where it's still a quagmire. Angular, for example.
| EMM_386 wrote:
| 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 and Visual Studio.
|
| I was dreading going back to web development when I switched
| back again but recently it has turned out to be nicely
| structured, performant, logical and enjoyable.
| christophilus wrote:
| My career sounds much like yours, and my conclusions are the
| same. Typescript is a decent language. The tooling is
| excellent. The old footguns are mostly behind us. It's
| definitely a completely new ballgame vs the old hackery I
| used to have to endure.
| lame88 wrote:
| Every time I am unfortunate enough to do something front-end
| it's just as bad as I remember.
|
| Edit: professionally, that is; when I do front-end related
| stuff for myself, it's fine, but they are small and I keep
| things simple - vanilla JS where needed, etc.
| wishinghand wrote:
| What do you remember? These days I'm no longer concerned
| about `this` pointing to the wrong object. Importing files is
| a huge step forward from when I started. The standard library
| has grown; a bunch of Lodash isn't needed anymore because of
| it. Promises and async/await. Even just template strings! So
| glad I don't have to concatenate with pluses and watching my
| double or single quotes.
| swyx wrote:
| totally! i have been developing a thesis around this I call the
| "Third Age" of JavaScript - TLDR: the arc of history is toward
| ES Modules, and polyglot tooling, like esbuild. Creating much
| faster dev tools and user experiences.
|
| http://swyx.io/js-third-age
| anfrank wrote:
| Release note says pinning version with "^0.8.0", should be
| "~0.8.0" right?
| machiaweliczny wrote:
| ^ is for minor version, ~ for patch, you can pin exact version
| without using anything, so "0.8.0"
| dilsmatchanov wrote:
| waiting for js bundler written in Rust
| btd wrote:
| you know about swc right? https://swc.rs/
| wdb wrote:
| Yes, but a bunch of the Typescript support is closed sourced
| . No idea, if that's important for you.
| searchableguy wrote:
| Type checker, yes. I don't think esbuild comes with a
| built-in typechecker either.
|
| Is there anything else I am missing?
| dilsmatchanov wrote:
| omg lol
| nicoburns wrote:
| I'd recommend esbuild over SWC. It's much more mature.
| [deleted]
| snemvalts wrote:
| For those who are actively using esbuild with TypeScript, how do
| you check the types?
| nicoburns wrote:
| In 3 ways:
|
| - Using the Language Server Plugin in editors
|
| - `npx tsc --noEmit` in a pre-commit hook
|
| - `npx tsc --noEmit` in CI
| mceachen wrote:
| I have a "lint" pre-test step that builds with tsc and runs
| eslint.
|
| I also have a `tsc --watch` running in a vscode window that
| highlights syntax and typing errors as I develop.
| emptysea wrote:
| I run tsc with noEmit passed as a flag. Esbuild is replaces my
| previous tsc, babel, uglify setup and is much faster.
| brundolf wrote:
| What some people do is use types purely for editor purposes,
| and let the build process just throw them away. We did this at
| my last company using Babel
| bpierre wrote:
| If you want to use config files with esbuild, esbuild-config is
| for you:
|
| https://github.com/bpierre/esbuild-config
|
| (disclaimer: I am the author)
| jmondi wrote:
| I really really wish this supported experimental decorators with
| reflection metadata so we could use this in our Angular and
| NestJS apps.
| privatenumber wrote:
| esbuild has flipped the JS community on its head. Not only as an
| impressive JS bundler, but through all the next gen tooling
| esbuild is powering.
|
| For example, you can now speed up your Webpack build with esbuild
| by replacing babel-loader/ts-loader/Terser:
| https://github.com/privatenumber/esbuild-loader
|
| (It also blows my mind that Evan is the CTO is Figma. How is he
| so productive!?)
| capableweb wrote:
| > (It also blows my mind that Evan is the CTO is Figma. How is
| he so productive!?)
|
| When Evan first joined Figma, he saw how much time the
| engineers spent on waiting for webpack and fighting JS
| configuration files. Then one time, during an outage, the
| developers tried to push a fix but the build was failing
| because babel-deduplicate-int had changed their API interface
| but only did a minor version bump when published to NPM, and
| Figma engineers are at the edge of technology so they use
| version ranges, not fixed versions.
|
| When Evan heard this he pored up some whisky and created
| esbuild in two nights. And the JS developers rejoiced. Now the
| developers were so productive, that Evan already had nothing to
| do. No one was fighting, all engineers were happy and playing
| ping-pong like any everyday was Friday.
|
| So now the only thing keeping all the JS engineers happy at
| Figma, is the continued success and improvement of esbuild. So
| Evan just spends his time with esbuild now.
|
| (This is all fictional, of course)
| swyx wrote:
| i said on twitter that esbuild is the best possible ad for
| working for figma that they could have ever done. (if this is
| what they do for _fun_... imagine what they do at work, etc).
|
| arguably he's doing his job just working on this thing all by
| himself
| astashov wrote:
| I switched my pet project (about 15000 lines of code) from
| Webpack to esbuild, and reduced the build time from 30 seconds to
| 2 seconds.
|
| The trickiest part was to make Tailwind CSS work. I used to do
| that via postcss plugin, but just running that plugin even
| without Webpack takes 15 seconds. Finally, with some
| modifications in my CSS I made it work, and purged the unused
| styles just by using PurgeCSS API manually.
|
| The setup got a bit hairier than with Webpack, but it builds damn
| fast now.
| deergomoo wrote:
| I believe the Tailwind team are currently working on addressing
| the performance issues. The project lead was recently tweeting
| about the new approach [0]; instead of building a huge CSS file
| and stripping out the unused classes, the new version will only
| generate the used classes to begin with.
|
| [0] https://twitter.com/adamwathan/status/1366514152517337089
| threatofrain wrote:
| How does Esbuild achieve such insane differences in speed?
| wffurr wrote:
| https://esbuild.github.io/faq/#why-is-esbuild-fast
| amatic wrote:
| It is written in go and compiled. Go is responsible for high
| parallelism. The fact it is compiled is an advantage over
| javascript-based bundlers because they are re-compiled every
| time you start building the source code (did I get that
| right?).
| parhamn wrote:
| As soon as esbuild gets react hot reloading capabilities I'm
| jumping ship. Although that might be out of scope and there is
| Vite. I'm hoping to avoid vite and go pure esbuild. Fantastic
| tool. It will make JavaScript distribution a much more pleasant
| experience across the board when it gets wider adoption.
| ccmcarey wrote:
| Think that's out of scope - doesn't snowpack (which uses
| esbuild) cover this though? https://www.snowpack.dev/
| keraf wrote:
| Snowpack uses ESM for development which allows really fast
| HMR. And ESBuild is used for production builds. Best of both
| worlds.
| lhorie wrote:
| He said in the past that he's not interested in implementing
| HMR[0]
|
| [0] https://github.com/evanw/esbuild/issues/97
| parhamn wrote:
| Makes logical sense from a library/unixy perspective. They
| offered similar reasoning for not including a file watcher at
| first but they eventually added that.
|
| HMR is pretty much the last missing piece to make this the
| only JS bundling and dev tool you need. It would be a bad
| decision to omit it.
| qbasic_forever wrote:
| Check out tools like vite or snowpack, which use esbuild
| internally. They're the HMR developer experience you're
| looking for.
| izelnakri wrote:
| I'm actually very happy that esbuild doesnt have HMR by
| default. Despite the fact that most frontend devs
| loving/hyping HMR, I prefer live-reloads more because it
| refetches data/makes network calls and run my route hooks
| without any additional step. This is particularly important
| when you run your application tests in the browser(thats
| better than running app tests in CI btw) and change these
| test files constantly. The fact that most frontend devs favor
| HMR over live-reload signals something that I really dislike.
| AltruisticGapHN wrote:
| Agree I hope Vite has a way to easily turn it off. Never
| understood the appeal. Way more fun to "see" what you're
| going for in your mind and write more at once and see what
| happens, then react compulsively to a tight feedback loop.
| I think these features sometimes don't make us better
| developers. I'm sure it has _some_ good uses, personally
| never needed it.
| nperez wrote:
| I've been a f/e dev for around a decade and I don't trust
| HMR. I end up refreshing manually anyway just so I know I'm
| not seeing issues that don't exist due to event bindings
| not refreshing properly, or app state getting messed up
| between loads. It's fine for styling, but worries me when
| there's too much complexity involved
| AltruisticGapHN wrote:
| That and the fact that unless you have two monitors often
| as you save the refresh happens out of view, when you're
| not seeing the page, so you lose the immediate visual
| feedback of what actually changes. When you make minute
| touches to a design it's annoying. When I hit F5 myself I
| can look at exactly what I'm interested and see if it
| shifted some pixels, if the font size is a bit better or
| worse...
| dota_fanatic wrote:
| _> 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 unpleasant to modify
| styling in the way you've described, and odd given
| there's a fantastic IDE in every major browser for
| styling exploration.
| wishinghand wrote:
| You bring up a good point. Wondering if there can be some
| way to have both side by side. When I'm working on markup
| or css I definitely want HMR. But when I'm in the script
| section I've run into issues where I needed to reload the
| page.
| capableweb wrote:
| > some way to have both side by side
|
| Yes, just hook up to the reloading event of HMR on the
| client-side and call `window.location.reload()` when that
| happens, now you have traditional "live reload".
| jayair wrote:
| We love esbuild and we use it internally for SST
| https://github.com/serverless-stack/serverless-stack.
|
| The work Evan does is seriously impressive.
| kraig wrote:
| 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.
___________________________________________________________________
(page generated 2021-03-09 23:01 UTC)