Hacker News new | past | comments | ask | show | jobs | submit login

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




There's actually a recent PR up for a `<Catch>` component:

- https://github.com/facebook/react/pull/26854


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.


What's wrong with components that expect to fail? Don't you need some way to notify users of predictable problems?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: