5 ms·

`instanceof Array` is a famous JavaScript footgun you should not use anyway. The same happens when sharing objects with an `iframe` (aka "cross-realm objects").

by fathyb 3y ago

`instanceof Array` is a famous JavaScript footgun you should not use anyway. The same happens when sharing objects with an `iframe` (aka "cross-realm objects"). This is why `Array.isArray` exists. That said, Jest used to be so good when it was first released, and got gradually slower and more complex. Same with Yarn. I hope React won't face the same fate. I loved integrating the recent suspense and async rendering features. It made my app feel so much better by removing loading flickers with no architectural changes.

CSMastermind 3y ago
npm took up most of yarn's significant changes to the point where I switched back years ago. I think the Jest situation is a little different as it was the incumbent not the challenger. React is similar in the it's become an incumbent, though probably with less marketshare. Ironically I believe the lack of a virtual DOM is a big selling point for Svelte (sp?) which my frontend developers are really excited about.
- pcthrowaway 3y ago
  I mostly use npm, but does npm have anything like yarn's workspaces or ability to patch dependencies with project-specific changes? Those are the "killer features" for yarn IMO, and why I think a lot of projects using it would have friction moving to npm
  - uallo 3y ago
    https://docs.npmjs.com/cli/v9/using-npm/workspaces https://docs.npmjs.com/cli/v9/using-npm/workspaces https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package
meese712 3y ago
Think the biggest slow down is from it running all the test suites in isolation in separate contexts (think that's the right word). I got frustrated with how slow our frontend tests were one day like 4 years ago and wrote a hacky jest runtime that reused the context unless it detected jest.mock or jest.spy or timer stuff in the file it was on. It speed it up by 2x with cache cleared. It was still pretty slow though... There was also an existing issue opened requesting this to be built in by a lot of people and facebook said lol no.
afavour 3y ago
In a way React has already had the same fate. It really astounds me that react-dom is >100KB big while the API-compatible Preact is something like 7KB. There are edge cases where you can't just drop it in directly as a replacement but you can very, very many times. Really makes me wonder what React is doing with that extra 93KB of JS, it's not actually even that fast compared to other frontend frameworks.
- franciscop 3y ago
  I wrote a jQuery (30kb) alternative called Umbrella JS (2.6kb) and based on my experience and if I had to guess, probably most of the rest of React's size is in compatibility stuff. Like making sure events work uniformly across browsers, I remember that making everything work with SVGs was also a big milestone, normalizing events (e.g. we have synthetic events which are basically React's events on top of the normal DOM events), etc. An astute/old fashion dev will realize that React's onChange actually behaves like `addEventListener('input')` and not really like `addEventListener('change')`, since the latter only triggers on blur and not on each keystroke. I strongly believe React team is shooting themselves on the foot by not making Error Boundaries into Hooks. If they did, someone could create a Preact 2.0 so to speak that is like React but purely functional (no classes). But since we don't have that, and error handling IS an important part of React, any react alternative would have to implement classes fully as well, which might retract many from even trying to create a React alternative (I don't think myself smart enough to do a React alternative properly, but I'd certainly tried if they did this).
  - acemarke 3y ago
    There's actually a recent PR up for a `<Catch>` component: - https://github.com/facebook/react/pull/26854 https://github.com/facebook/react/pull/26854
  - awayto 3y ago
    I wonder if error boundary components/functionality are an anti-pattern. They invite the developer to create components which expect to fail. Even basic hide/show logic is better than expecting devs to orchestrate unified error handling across the app.

by fathyb 3y ago

CSMastermind 3y ago

npm took up most of yarn's significant changes to the point where I switched back years ago. I think the Jest situation is a little different as it was the incumbent not the challenger. React is similar in the it's become an incumbent, though probably with less marketshare. Ironically I believe the lack of a virtual DOM is a big selling point for Svelte (sp?) which my frontend developers are really excited about.

pcthrowaway 3y ago
I mostly use npm, but does npm have anything like yarn's workspaces or ability to patch dependencies with project-specific changes? Those are the "killer features" for yarn IMO, and why I think a lot of projects using it would have friction moving to npm
- uallo 3y ago
  https://docs.npmjs.com/cli/v9/using-npm/workspaces https://docs.npmjs.com/cli/v9/using-npm/workspaces https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package

meese712 3y ago

Think the biggest slow down is from it running all the test suites in isolation in separate contexts (think that's the right word). I got frustrated with how slow our frontend tests were one day like 4 years ago and wrote a hacky jest runtime that reused the context unless it detected jest.mock or jest.spy or timer stuff in the file it was on. It speed it up by 2x with cache cleared. It was still pretty slow though... There was also an existing issue opened requesting this to be built in by a lot of people and facebook said lol no.

afavour 3y ago

In a way React has already had the same fate. It really astounds me that react-dom is >100KB big while the API-compatible Preact is something like 7KB. There are edge cases where you can't just drop it in directly as a replacement but you can very, very many times. Really makes me wonder what React is doing with that extra 93KB of JS, it's not actually even that fast compared to other frontend frameworks.

franciscop 3y ago
I wrote a jQuery (30kb) alternative called Umbrella JS (2.6kb) and based on my experience and if I had to guess, probably most of the rest of React's size is in compatibility stuff. Like making sure events work uniformly across browsers, I remember that making everything work with SVGs was also a big milestone, normalizing events (e.g. we have synthetic events which are basically React's events on top of the normal DOM events), etc. An astute/old fashion dev will realize that React's onChange actually behaves like `addEventListener('input')` and not really like `addEventListener('change')`, since the latter only triggers on blur and not on each keystroke. I strongly believe React team is shooting themselves on the foot by not making Error Boundaries into Hooks. If they did, someone could create a Preact 2.0 so to speak that is like React but purely functional (no classes). But since we don't have that, and error handling IS an important part of React, any react alternative would have to implement classes fully as well, which might retract many from even trying to create a React alternative (I don't think myself smart enough to do a React alternative properly, but I'd certainly tried if they did this).
- acemarke 3y ago
  There's actually a recent PR up for a `<Catch>` component: - https://github.com/facebook/react/pull/26854 https://github.com/facebook/react/pull/26854
- awayto 3y ago
  I wonder if error boundary components/functionality are an anti-pattern. They invite the developer to create components which expect to fail. Even basic hide/show logic is better than expecting devs to orchestrate unified error handling across the app.