81–90 of 123 posts
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.
Is there anything else I am missing?
Earlier quoted context omitted.
TailwindCSS, Svelte, and Snowpack are probably worth a shot, all pretty much bleeding edge
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.
Earlier quoted context omitted.
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.
React was released in 2013, that’s 8 years.
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.
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…
[0] https://twitter.com/adamwathan/status/1366514152517337089
Earlier quoted context omitted.
He said in the past that he's not interested in implementing HMR[0] [0] https://github.com/evanw/esbuild/issues/97
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. T…
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.
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.
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!?)
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)
Earlier quoted context omitted.
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. T…
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.
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".
Earlier quoted context omitted.
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 rea…
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.
Would be great to get some insights how people are mitigating the lack of bundle splitting in non-esm output right now. Thanks!