Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up the JavaScript ecosystem – Polyfills gone rogue

marvinh.dev

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#101

Post by lenkite »

beepbooptheory wrote: post #41
josephg wrote: post #28

Earlier quoted context omitted.

> "Do not repeat yourself" was seen as a gold standard for programming. I remember this era. I’ve been using nodejs before npm existed and so many silly things have happened in that time. I think the core problem the JS ecosystem has always had is that most JS developers are relatively inexperienced. (JS is very beginner friendly and this is the price we pay). I still vividly remember being at nodecamp in 2012 or som…

I thought is-even/is-odd were satirical? Granted, satire echoing these same points... but, you know, just for-the-record.

There were packages for every color code in npm at one time.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#102

Post by forgotmypw17 »

samus wrote: post #76
forgotmypw17 wrote: post #60

Earlier quoted context omitted.

Thank you for supporting IE6. I also maintain some JS and ensure compatibility with older browsers. Someone out there still wants to use it, whether it's an old machine with nostalgic value, the only machine they happen to have available, or just retro-computing enthusiasts, and I take pride in accommodating them. Good on you.

Since IE6 depends on the schannel implementation of the OS, it should not support neither TLS1.2 nor TLS 1.3. This means that it simply can't access the modern web anymore. Maybe there are still webservers out there though that still support outdated SSL/TLS versions and were never patched shudder

For accessibility reasons, I make my sites available using HTTP.

It allows users to bypass using TLS in situations where it breaks being able to access the website, such as this one.

(There are many scenarios when TLS can break accessibility, and in many of them access to the information is more important than the integrity of the connection.)

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#104

Post by synergy20 »

will these unneeded polyfills etc be removed by treeshaking and code splitting in the production build via bundlers?

are Bun and Deno solving this problem to some extent?

node.js/bun/deno need a battery-included stdlib to me like what python provides.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#105

Post by pphysch »

corbezzoli wrote: post #91
pphysch wrote: post #47

Earlier quoted context omitted.

Those may be satirical, but `leftpad` is real. https://qz.com/646467/how-one-programmer-broke-the-internet-...

`left-pad` is the perfect amount of complexity and "I'm sure I can do it" ability by everyone who looks at it. I want you to write that logic and not have some stupid mistake that was fixed in that module 15 years ago. Now we have String.prototype.padStart thanks to that debacle.

Then copy-paste it from SO^H^H your LLM copilot. It's clearly not something that benefits from being an external dependency.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#106

Post by no_wizard »

mhagemeister wrote: post #19
no_wizard wrote: post #4

Marvin is doing wonderful work in the JS ecosystem around performance. It has been largely focused on tools and node, however, he did have an interesting set of things to say about how they optimized performance in Preact as well on his website that was really interesting too. One thing I've noticed is the rampant duplication of polyfills and babel helpers. To the point that I now have overrides setup via pnpm and I…

Author here. Thanks for the kind words! It's feedback like this that encourages me to keep writing about it. I share your experiences regarding babel helpers and haven't found a good solution myself. Similar to you, I often patch unnecessary stuff out via patch-package, but that approach doesn't scale well.

I use path resolution, it tends to scale better (not great but better) for Babel helpers because ‘Babel-runtime’ can 100% be re-mapped to ‘@babel/runtime’. Same with corejs 2 -> 3, they just need path mapping.

Patching packages is definitely something I still have to do to strip polyfills and convert CJS to ESM if I can’t simply re-compile source

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#107

Post by no_wizard »

shortcake27 wrote: post #85
lavax wrote: post #82

Earlier quoted context omitted.

I try to focus on the issues rather than individuals, but the root of the problems in the listed eslint plugin libraries points to ljharb. If you do some simple digging into these libraries, you will find that these types of commits are quite common within them. https://github.com/jsx-eslint/eslint-plugin-react/commit/e1d... https://github.com/jsx-eslint/jsx-ast-utils/commit/bad51d062... https://github.com/jsx-eslint…

ljharb is an extremely interesting person. There’s no doubting the positive impact he’s had on the OSS community and the work he’s done. However, there are some things he does that are incomprehensible. For example, Enzyme. Over three years ago this issue was opened for Enzyme on React 17: https://github.com/enzymejs/enzyme/issues/2429 Nothing moved for a while, and I think he said something along the lines of “if yo…

RTL is more flexible and arguably puts developers in the situation where they have to write better more user centric tests.

The complexity for me is around events which I imagine is somewhat common, that said in think it’s fair better and more durable than enzyme

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#108

Post by mhagemeister »

pbowyer wrote: post #87

This is a really nice post and series. I'm curious how you're doing the profiling and then generating the flame graphs e.g. in https://marvinh.dev/blog/speeding-up-javascript-ecosystem/ . Is this Chrome's built-in devtools being used or something else?

Glad to hear you like it! Those flame graph screenshots are taken from https://www.speedscope.app/ .

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#109

Post by mhagemeister »

synergy20 wrote: post #104

will these unneeded polyfills etc be removed by treeshaking and code splitting in the production build via bundlers? are Bun and Deno solving this problem to some extent? node.js/bun/deno need a battery-included stdlib to me like what python provides.

They are unfortunately not removed, because the way they are used makes it difficult for bundlers to detect them.

Deno encourages you to submit the original sources which can be even in TypeScript if you want. The users are very close to the newest Deno release and there is barely anyone staying on old versions. This works because Deno takes semver very seriously, which in turn encourages folks to upgrade. It removes the need for polyfills and allows you to always use the latest JS features.

Disclaimer: I work at Deno

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#110

Post by corbezzoli »

davedx wrote: post #100
corbezzoli wrote: post #90

Earlier quoted context omitted.

> massive load of work for negligible (if any) gain If you coded alone for 10 years and then add a strict linting config you're going to have a really bad time. If you actually follow the advice a linter gives you, you come up a 10x better developer. Of course not all lint rules are created equal, but some are arguably existential.

I’ve done that, and I’ve coded on projects with big teams, with and without linters, for way longer than that, with multiple languages. Linters have never contributed anything close to what a half decent type system does to a project.

Types, tests, lints are all complementary. Your comparison is meaningless. The fact that you'd even compare the two shows how much your experience with linters is worth.

"I don't wear a helmet because I can just drive slowly"

"I can eat this 8-patty burger because I'm going for a run later"

Post reply on HN