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

81–90 of 112 posts

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#81

Post by davedx »

romellem wrote: post #29

There is some interesting [drama][1] with this, since this article noticeably doesn't mention any PRs they opened to remove some of these older polyfills. The reason those PRs were never opened/merged is the maintainer of many of those libraries [has a strong stance on "breaking" changes][2] in software: > I have developed an intense avoidance for breaking changes in all of my packages, because I don't want to inflic…

Insanity. In projects where I have full technical control I don’t use eslint anyway, it creates a massive load of work for negligible (if any) gain. Typescript finds the important issues, prettier fixes formatting; linters just create giant swathes of useless busywork.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#82

Post by lavax »

romellem wrote: post #29

There is some interesting [drama][1] with this, since this article noticeably doesn't mention any PRs they opened to remove some of these older polyfills. The reason those PRs were never opened/merged is the maintainer of many of those libraries [has a strong stance on "breaking" changes][2] in software: > I have developed an intense avoidance for breaking changes in all of my packages, because I don't want to inflic…

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/eslint-plugin-jsx-a11y/commit/...

He would rather see the download count of these polyfill libraries https://github.com/ljharb/ljharb#projects-i-maintain increase, compared to assessing the health of the JavaScript ecosystem.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#83

Post by mhagemeister »

chatmasta wrote: post #54

Sometimes it can be a security vulnerability to call a polyfill instead of the now available default implementation. For example, this 2018 bug [0] in the Grammarly Chrome Extension had a much wider impact due to its reliance on a fetch polyfill that was able to make requests (via XHR) to origins that native fetch could not. I suppose in that case you could argue the real bug is in the XHR API, but it only affected t…

That's a very good point. Didn't know about the grammarly incident. I could definitely see this happening again with the amount of polyfills in npm packages. Polyfills are usually frozen in time and not developed further after they are released.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#84

Post by davedx »

cxr wrote: post #3

You'll never get NPM apologists to acknowledge this. One of their only skills is making non-specific appeals to the necessity of it all (as essential infrastructure) and vague arguments that boil down to "you need to trust the wisdom of the crowds" (and e.g. the fact that it exists and everyone else is using it means that anyone who disputes its value just doesn't understand it—bonus points for them if they manage to…

It is infuriating. I love the power of the node ecosystem but the total lack of critical thinking around it drives me bonkers.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#85

Post by shortcake27 »

lavax wrote: post #82
romellem wrote: post #29

There is some interesting [drama][1] with this, since this article noticeably doesn't mention any PRs they opened to remove some of these older polyfills. The reason those PRs were never opened/merged is the maintainer of many of those libraries [has a strong stance on "breaking" changes][2] in software: > I have developed an intense avoidance for breaking changes in all of my packages, because I don't want to inflic…

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 you want React 17 support, stop complaining and help”. So the community got involved. There are multiple PRs adding React 17 support. Many unofficial React 17 adapters. A lot of people have put a lot of work into this, ensuring compatibility, coverage etc. Yet to this day, none of them have been merged. Eg https://github.com/enzymejs/enzyme/pull/2564

Given the amount of time that has passed, and the work the community has put in, something is amiss. It feels like he’s now intentionally avoiding React 17+ support. But why? I don’t understand why someone would ask for help then ignore the help when it comes in. That isn’t much better than the swathe of rude/entitled comments he was getting on the issue before he locked it.

I ended up migrating to RTL, but this made many of my tests more complicated (especially compared to shallow rendering).

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#86

Post by hashar »

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…

I'd guess the issue with that project is that it is mostly a single person effort and if that person is busy with other projects/repos/real life, they might not have the bandwidth to keep-up with the review, loose interest or maybe did not notice the PR update in the stream of incoming requests.

I guess the community (if there is any) can request to have more maintainers added to the repository to share the burden, else you still have the option to fork the repo and publish it under a different name.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#88

Post by scns »

arthur2e5 wrote: post #63

These polyfills aren't just large, they're also slow because they never use the native implementation. The good news is that you can replace them all with "overrides" in package.json. That's what nolyfill ( https://github.com/SukkaW/nolyfill ) does. Oh, and of course the README mentions ljharb.

I'd upvote you a 1000 times if i could. To lazy to mail dang if it's possible to pin it on top.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#89

Post by Chernobog »

davedx wrote: post #81
romellem wrote: post #29

There is some interesting [drama][1] with this, since this article noticeably doesn't mention any PRs they opened to remove some of these older polyfills. The reason those PRs were never opened/merged is the maintainer of many of those libraries [has a strong stance on "breaking" changes][2] in software: > I have developed an intense avoidance for breaking changes in all of my packages, because I don't want to inflic…

Insanity. In projects where I have full technical control I don’t use eslint anyway, it creates a massive load of work for negligible (if any) gain. Typescript finds the important issues, prettier fixes formatting; linters just create giant swathes of useless busywork.

I think your description of linting can be true, but not necessarily for every eslint configuration. I feel that I've landed on configs that feel useful to myself and the rest of the devs in the team. Even with a rule set that contains many rules that can look nit picky at first glance, no one complains since they are auto fixable, and fixing is a part of a commit hook.

There are a handful of rules that are nice to have in a TypeScript project to make sure devs don't do things that break type safety. Plus some that avoids mistakes from slipping through (even though the code is reviewed).

One thing I've found super useful is to have @typescript-eslint/ban-ts-comment enabled, but configured so that you can still use @ts-expect-error and the others as long as you provide a comment when doing so. This is so nice when doing code reviews, either someone has provided a very good reason for the exception, or it is clear that the same result could have been achieved with a better approach. Same goes for disabling eslint rules inline in a file, also allowed if commented. I feel that this is a very good compromise between being strict with linting, but also not letting linting get in the way.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#90

Post by corbezzoli »

davedx wrote: post #81
romellem wrote: post #29

There is some interesting [drama][1] with this, since this article noticeably doesn't mention any PRs they opened to remove some of these older polyfills. The reason those PRs were never opened/merged is the maintainer of many of those libraries [has a strong stance on "breaking" changes][2] in software: > I have developed an intense avoidance for breaking changes in all of my packages, because I don't want to inflic…

Insanity. In projects where I have full technical control I don’t use eslint anyway, it creates a massive load of work for negligible (if any) gain. Typescript finds the important issues, prettier fixes formatting; linters just create giant swathes of useless busywork.

> 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.

Post reply on HN