81–90 of 99 posts
Earlier quoted context omitted.
I take it you've never suggested to a front-end dev that maybe their contact form doesn't need a 1MB+ of JavaScript framework and could just be HTML that submits to a backend.
Live-form validation? Auto-complete? Any of these ringing a bell? It's almost like there are genuine UX improvements being done
Earlier quoted context omitted.
Perfect example of what I am talking about. People want faster software... until they are confronted by challenging decisions. JavaScript can be very fast. JavaScript, in the browser, reports a page load of about 0.06 seconds for my large personal SPA and that includes state restoration. That is determined by using: performance.getEntries()[0].duration in the browser. When conflicts arise people most frequently becom…
> When conflicts arise people most frequently become emotional and complain about the situation than make any decision towards resolution one way or the other. That is a psychological problem called cognitive conservatism[1]. About the half the time that emotional output is some form of deflection, such as hostility. Cognitive conservatism is only allowed to exist when there is insufficient pressure on the thought le…
Earlier quoted context omitted.
The good part is that the new tools do replace the old ones, while being compatible. The pattern is: * Rolldown is compatible to Rollup's API and can use most Rollup plugins * Oxlint supports JS plugins and is ESLint compatibel (can run ESLint rules easily) * Oxfmt plans to support Prettier plugins, in turn using the power of the ecosystem * and so on... So you get better performance and can still work with your favo…
So you really think everyone in JS should have to learn Rust or else be excluded from sharing in the ownership of their critical infra..?
2) With AI, languages and syntax matters even less nowadays.
3) There have been a good amount of contributors (e.g. for Oxc) that came out the JS world, so it isn't impossible
4) Realistically, the avg. web dev does not contribute to tooling internals, maximum custom rules or similar. The concepts are a bigger "hurdle" than the lang.
I'm very surprised the article doesn't mention Bun. Bun is significantly faster than Vite & Rolldown, if it's simply speed one is aiming for. More importantly Bun allows for simplicity. Install Bun, you get Bundler included and TypeScript just works, and it's blazing fast.
Bun can replace vite?
Earlier quoted context omitted.
> When conflicts arise people most frequently become emotional and complain about the situation than make any decision towards resolution one way or the other. That is a psychological problem called cognitive conservatism[1]. About the half the time that emotional output is some form of deflection, such as hostility. Cognitive conservatism is only allowed to exist when there is insufficient pressure on the thought le…
It’s not about right or wrong. It’s about the numbers. You are either faster or not. People that are easily offended really want it to be all about right or wrong. The only reason I can think of abandoning or discarding evidence is emotion. Whether that is right or wrong I don’t care.
I don't doubt you have been correct to say performance can be improved. Performance always can be improved. It just likely doesn't matter.
Earlier quoted context omitted.
The good part is that the new tools do replace the old ones, while being compatible. The pattern is: * Rolldown is compatible to Rollup's API and can use most Rollup plugins * Oxlint supports JS plugins and is ESLint compatibel (can run ESLint rules easily) * Oxfmt plans to support Prettier plugins, in turn using the power of the ecosystem * and so on... So you get better performance and can still work with your favo…
As far as I'm aware oxlint only supports plugins for non type aware rules, and type aware rules themselves aren't fully stable because it relies on a fork of tsgo.
Type-aware rule are indeed not marked as stable but work like a charm. tsgolint is indeed tsgo + shims + some works, but that won't change soon as tsgo won't have a JS API for a while.
Earlier quoted context omitted.
You can rip fast builds from my cold, dead hands. I’m not looking back to JS-only tooling, and I was there since the gulp days.
All I can say for sure is that the reason the old tools were slow was not that the JS runtime is impossible to build fast tools with. And anyway, these new tools tend to have a "perf cliff" where you get all the speed of the new tool as long as you stay away from the JS integration API sued to support the "long tail" of uses cases. Once you fall off the cliff though, you're back to the old slow-JS cost regime...
I don't have them at hand right now but there are various detailed write-ups from the maintainers of Vite, oxc, and more, that are addressing this specific argument to point out that indeed the JavaScript runtime was a hard limitation on the throughput they could achieve, making Rust a necessity to improve build speeds.
Earlier quoted context omitted.
So you really think everyone in JS should have to learn Rust or else be excluded from sharing in the ownership of their critical infra..?
1) This is not what I said, no 2) With AI, languages and syntax matters even less nowadays. 3) There have been a good amount of contributors (e.g. for Oxc) that came out the JS world, so it isn't impossible 4) Realistically, the avg. web dev does not contribute to tooling internals, maximum custom rules or similar. The concepts are a bigger "hurdle" than the lang.
You're stuck telling people what they can't have (and shouldn't want) while I'm now in a position to just give people what they want. I admire the people who work there, but you need a new business model and fast because I am unequivocally going to collapse your current one.
Earlier quoted context omitted.
It’s not about right or wrong. It’s about the numbers. You are either faster or not. People that are easily offended really want it to be all about right or wrong. The only reason I can think of abandoning or discarding evidence is emotion. Whether that is right or wrong I don’t care.
The success of an organization is very rarely dependent solely on website performance. Speed is just one dimension in a vast and multi-dimensional optimization space. Spending time improving performance means you are necessarily not spending time improving one of those other vectors. It is a question of priorities - and suggesting that others who say that other priorities are more important are "emotional" is failing…
If you don’t want to be faster it’s okay.
Earlier quoted context omitted.
e: ahhh frick this is just stupid AI spam for this dude’s project. Supports… some ESLint rules. It is not “easy” to add support to Oxlint for the rules it does not. The projects at my work that “switched” to it now use both Eslint and Oxlint. It sucks, but at least a subset of errors are caught much faster.
Yeah, no. Real human here. Oxlint does support core rules out of the box but has support for JS plugins[0] as mentioned. If you don't rely on a custom parser (so svelte or vue component for example) things just work. Even react compiler rules[1]. [0] https://oxc.rs/docs/guide/usage/linter/js-plugins.html [1] https://github.com/TheAlexLichter/oxlint-react-compiler-rule...