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

A one-line package broke `npm create-react-app`

github.com

Post reply on HN
Print view View original

241–250 of 478 posts

Re: A one-line package broke `npm create-react-app`

#241

Post by throwanem »

gavinray wrote: post #232
morelisp wrote: post #121

Earlier quoted context omitted.

This analogy doesn't hold up at all. The UHH is a fun read, yes, but the biggest real-world problem with the Unix Wars was cross-compatibility. Your Sun code didn't run on Irix didn't run on BSD and god help you if a customer wanted Xenix. OK, you can draw some parallel here between React vs. Vue vs. Zeit vs. whatever. But there was also the possibility, for non-software businesses, to pick a platform and stick to it…

This is slightly off-tangent, but as someone who has written production software on the front-end (small part of what I do/have done) in: Vanilla -> jQuery -> Angular.js -> Angular 2+, React pre-Redux existence -> modern React -> Vue (and hobby apps in Svelte + bunch of random stuff: Mithril, Hyperapp, etc) I have something to say on the topic of: > "If you pick React, you're not getting hurt because Vue and React ar…

Web components aren't really there yet. They will be two or three years from now. Some time between now and then, I expect React will gain the ability to compile down to them, which shouldn't be too hard since web components are pretty much what happens when the React model gets pulled into core.

Re: A one-line package broke `npm create-react-app`

#244

Post by recursive »

oldmanhorton wrote: post #210
hu3 wrote: post #196

Earlier quoted context omitted.

There are alternatives to create-react-app. In fact, there are alternatives to React.

Have fun telling that to your boss

I rarely justify technical decisions to my boss, and when I do, they smile and nod.

Re: A one-line package broke `npm create-react-app`

#246

Post by throwanem »

monkpit wrote: post #190
gpm wrote: post #137

Earlier quoted context omitted.

A class with a `then` method isn't a rare thing that could only come up adversarially. Below I've linked two example from the rust std-library (I just chose that language because the documentation is really easy to search for objects which have a method name then). I think we can be sure that both booleans, and the "less than, equal to, or greater than" enum are not in fact promises. https://doc.rust-lang.org/std/pri…

Cypress.io has chainable .then functions but they are not await-able and the documentation clearly states they are not promises and cannot be treated as such. It’s a bad idea, but it is out there.

I haven't used Cypress, but looking at its docs, I don't know that I'd agree its use of "then" is all that bad. I agree they'd have done better to find a different name, but this at least seems like the least possible violation of least surprise if they are going to reuse the name.

At the same time, it is intensely wild to me that their "then" is an alternative to their "should", which apparently just re-executes the callback it's given until that callback stops throwing. If your tests require to be re-run an arbitrary and varying number of times in order to pass, you have problems that need to be dealt with in some better way than having your test harness paper over them automatically for you.

Re: A one-line package broke `npm create-react-app`

#247

Post by gpm »

throwanem wrote: post #234
gpm wrote: post #181

Earlier quoted context omitted.

It doesn't call into question the idioms of either language. It does call into question the idea of programmatically deciding whether or not something is a promise based on the assumption that the idiom was followed. People bounce around between languages, especially to javascript. An expert javascript dev might not call things "then" but the many dabblers might. Going back to the original point this is a footgun, no…

So your point ultimately is that duck-typing isn't ideal? I mean, I agree, but I'm not sure where this gets us that we weren't before.

I don't actually mind duck-typing.

My primary point is just that you are mistaken when claiming that this bug could only be surfaced by malicious code.

My secondary (somewhat implicit) point is that having an "is-promise" function is a mistake when there is no way to tell if something actually is or is not a promise. This library/function name is lying to the programmers using it about what it is actually capable of, and that's likely to create bugs.

Re: A one-line package broke `npm create-react-app`

#248

Post by rsj_hn »

throwanem wrote: post #225
x86_64Ubuntu wrote: post #195

Earlier quoted context omitted.

And your example is why we have the "lol javascript trash amirite" chorus, because as you've noted these problems were solved decades ago. Yet for some reason, the JS and npm ecosystems always seem to have some dependency dustup once or twice a year.

Yes, that's largely my point. I'm not sure why it is surprising to see an ecosystem, twenty-five or so years younger than the one I compared it to, have the same problems as that one did twenty-five years or so ago.

That line of reasoning suggests progress isn't being made and we are just reliving the past.

Re: A one-line package broke `npm create-react-app`

#249

Post by bdcravens »

recursive wrote: post #244
oldmanhorton wrote: post #210

Earlier quoted context omitted.

Have fun telling that to your boss

I rarely justify technical decisions to my boss, and when I do, they smile and nod.

I work in a similar environment, but I think it's fair to realize many do not.

Re: A one-line package broke `npm create-react-app`

#250

Post by znpy »

morelisp wrote: post #121
throwanem wrote: post #107

The problems that beset the Javascript ecosystem today are the same problems that beset the Unix ecosystem, back in the 90s when there still was one of those. TC39 plays the role now that OSF did then, standardizing good ideas and seeing them rolled out. That's why Promise is core now. But that process takes a long time and solutions from the "rough consensus and running code" period stick around, which is why instan…

This analogy doesn't hold up at all. The UHH is a fun read, yes, but the biggest real-world problem with the Unix Wars was cross-compatibility. Your Sun code didn't run on Irix didn't run on BSD and god help you if a customer wanted Xenix. OK, you can draw some parallel here between React vs. Vue vs. Zeit vs. whatever. But there was also the possibility, for non-software businesses, to pick a platform and stick to it…

    The UHH is a fun read, yes, but the biggest real-world
    problem with the Unix Wars was cross-compatibility. 
    Your Sun code didn't run on Irix didn't run on BSD 
    and god help you if a customer wanted Xenix. 
    OK, you can draw some parallel here between 
    React vs. Vue vs. Zeit vs. whatever.
    
    But
You made your point, proved yourself wrong, and then went ahead ignoring the fact that you proved yourself wrong.
Post reply on HN