For those who are actively using esbuild with TypeScript, how do you check the types?
I also have a `tsc --watch` running in a vscode window that highlights syntax and typing errors as I develop.
71–80 of 123 posts
For those who are actively using esbuild with TypeScript, how do you check the types?
I also have a `tsc --watch` running in a vscode window that highlights syntax and typing errors as I develop.
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…
Earlier quoted context omitted.
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
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...
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.
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.
How does Esbuild achieve such insane differences in speed?
How does Esbuild achieve such insane differences in speed?
Release note says pinning version with "^0.8.0", should be "~0.8.0" right?
Earlier quoted context omitted.
Yep, I tried front-end way back and hated it. Can you mention some other tech that should be covered in my re-evaluation?
TailwindCSS, Svelte, and Snowpack are probably worth a shot, all pretty much bleeding edge
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.
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!?)
arguably he's doing his job just working on this thing all by himself