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

91–100 of 112 posts

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#91

Post by corbezzoli »

pphysch wrote: post #47
beepbooptheory wrote: post #41

Earlier quoted context omitted.

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

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.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#92

Post by shortcake27 »

hashar wrote: post #86
shortcake27 wrote: post #85

Earlier quoted context omitted.

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, e…

I get being busy. But it’s been three years, and he keeps saying the project isn’t dead, so he hasn’t lost interest. Also, he asked for help then largely ignored the help and/or started bike shedding the PRs. He’s 100% across everything that happens in the repo, investing a lot of time replying to every comment immediately.

I’m pretty sure people offered to become maintainers and he declined. Forking has its own set of problems, but yeah you’re right, this is at least a possibility.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#93

Post by DanielHB »

jongjong wrote: post #61

In the early days of the Node.js ecosystem, there was a trend which was all about 'tiny modules'; many developers published tiny 10-line or so modules and people in the community were promoting these tiny modules really hard. It went a bit out of control and a lot of higher level modules were including many of those tiny modules, then those modules were themselves included into other, even higher level modules, etc..…

I think a lot of the sentiment behind this was that the module system and bundlers didn't really support tree shaking so bringing in a big library with a lot of utility functions brought in a ton of code you didn't need.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#94

Post by corbezzoli »

deevus wrote: post #65

I haven't got much experience with WASM, but is dependency hell something that WASM completely solves? All of the cruft that you don't use will get optimised away by the compiler, right? I'm not aware of any production ready WASM frameworks, but I'm ready for it.

1. WASM is non-JavaScript code, so it's unrelated to npm

2. Whatever dependency hell exists in the source language still exists at WASM compilation time

3. There will never be WASM frameworks because they're generally not the bottleneck.

The closest to WASM framework was Cappuccino, which let you compose a whole application in a language close to Objective-C

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#95

Post by jeroenhd »

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…

I don't see the problem, to be honest. Everybody is using this guy's work for free and then he needs to deal with complaints that it's not good enough, because it supports ancient browsers in a way that's not to their liking.

You can always fork the projects with this guy's polyfills if you want, but you'll end up forking quite the collection of projects. Most of them are very minor and only end up polyfilling anyway, so you can probably get rid of the packages you don't want in an afternoon. Fork them and maintain them yourself if you're so inclined, don't complain that the free work he's doing for you isn't to your specifications.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#96

Post by deevus »

corbezzoli wrote: post #94
deevus wrote: post #65

I haven't got much experience with WASM, but is dependency hell something that WASM completely solves? All of the cruft that you don't use will get optimised away by the compiler, right? I'm not aware of any production ready WASM frameworks, but I'm ready for it.

1. WASM is non-JavaScript code, so it's unrelated to npm 2. Whatever dependency hell exists in the source language still exists at WASM compilation time 3. There will never be WASM frameworks because they're generally not the bottleneck. The closest to WASM framework was Cappuccino, which let you compose a whole application in a language close to Objective-C

1. Not related to npm, but related to the web.

2. True, but compilers are generally better than transpilers.

3. Have you seen https://yew.rs/ ?

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#97

Post by jeroenhd »

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…

> But regardless, no one is required to stick to a particular way of creating open source software, so the one benefit here is that you are free to fork the library (assuming its license allows for that) to remove some backwards compatibility that isn't relevant to you.

I think that's the most important takeaway here. The library author decided not to make breaking changes and to keep compatibility wherever he can. I don't think that's a requirement many people have (not to this level, anyway), but it's not unreasonable either.

No project is required to use or accept his code. People want qs, resolve, and nvm.sh, and this one person is willing to provide it to everyone for free.

I don't care if he refuses suggestions because of "breaking changes" or because "they don't spark joy". It's his project, you can disagree with him all you want, but you can't complain that the free work he's doing isn't to your liking.

I think it's telling that a lot of people are willing to argue with the maintainer but very few people are willing to step up to provide and maintain a better fork.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#98

Post by gryzzly »

I think /vendor/ folder should make a come back. This is how I’ve been doing all my side projects for a while now.

People really have no mercy upon themselves, to deal with the bloated crap of the [struggle-stack™](https://twitter.com/brianleroux/status/1643337745463644160)

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#99

Post by davedx »

Chernobog wrote: post #89
davedx wrote: post #81

Earlier quoted context omitted.

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 h…

Yeah there is like one rule that I often try to fix, the “no non-null assertions” rule (some.property!), because it often leads to bugs. I kind of wish you could just disable non-null assertions at the compiler level really. Maybe strict mode should do that.

I can’t think of any other lint rules I find valuable. For the giant mass of node_modules you need to run eslint, I think its cost-benefit is pretty darn terrible.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#100

Post by davedx »

corbezzoli wrote: post #90
davedx wrote: post #81

Earlier quoted context omitted.

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.

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.
Post reply on HN