161–170 of 279 posts
Both React and Lit's approach (that requires schedulers and user uncontrolled updates) are completely unnecessary for most if not all of the applications currently using React and I bet nobody even knows why they exist. Facebook made React like this because of these requirements: they wanted their chat application that requires various real time small updates to multiple parts of the page to run quickly where a wipe…
The section about trusting dependencies, the scenario where they go away, version churn etc doesn't resonate with me in regards to react. I don't know any project in JS-land that is more serious about semver, backwards compatibility and reliable upgrades than react. If facebook dropped the project tomorrow, Vercel alone could probably continue to maintain it well.
Not only that, but so many strong engineering orgs build on React that I can't imagine it degrading very soon. Even if the top contributors left, Facebook imploded, and Airbnb disappeared, I'm quite certain there would be a crowdsourced effort to rescue and maintain the framework.
Earlier quoted context omitted.
Yeah agreed. The arc of learning seems to be… This is interesting -> this is the best thing in the world -> here’s how this could be better The “use the platform” people have been making this case for web components for at least 5 years now. The reality is WC will take off when and if they are a better alternative and even then they’ll need to be paired with some sort of framework. They may even make their way into R…
React very much feels like its own platform to me - having its own browser tools to debug it is a dead giveaway.
Earlier quoted context omitted.
You implied it. What you should have alluded to is that it is necessary to use technologies today that won’t necessarily be in use in the future, merely as a stepping stone to get us to the next destination, where we will use a new but still temporary technology.
I think op was suggesting someday we’d be on hoverboard or something
Earlier quoted context omitted.
> Stateful components don't work so well in React. They work fine, though managing state outside of components via a state management library is common. > If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. Where do you find this recommendation? I’ve never seen anything like it, and keys are usually only used for repeating sets of elements,…
> Where do you find this recommendation? https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d... > keys are usually only used for repeating sets of elements Not true at all!
> In most cases, this is the best way to handle *state that needs to be reset*
You are talking about updating state, react author is talking about resetting. That's a big difference.
If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…
I am currently working on an app at work that wants SPA functionality, but they won't let me use any of the frameworks. Tons of vanilla JS and Jquery. I am sure what I have written is probably considered a crime against humanity in some place.
Does it work? Yes. Is it an elegant and maintainable codebase? Not by my definition.
> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really wo…
This has got to be gaslighting at the highest level: oh you're doing something wrong because that's not how you're supposed to do it in React. Not since Java's Spring have I encountered such weird zealotry for a relatively mediocre (but widely popular) framework.
If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…
> This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much I am currently working on an app at work that wants SPA functionality, but they won't let me use any of the frameworks. Tons of vanilla JS and Jquery. I am sure what I have written is probably considered a crime against humanity in some place. Does it work? Yes. Is it an elegant and maintai…
If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…
> without implementing a significant chunk of the frameworks In my experience, it hasn't seemed all that significant. These frameworks are absurdly general and cover a range of use cases and deployment methods that most people don't use. I just need the kitchen sink, not everything else. So far, just using custom elements and a small wrapper around the element, I've not been struggling to create the features I need o…
Also, the trend of hiring developers is a plague: if you know JavaScript and the DOM well, learning the basics of react is a couple afternoons of work and you can figure out the pitfalls via code review and learning on the job.
Earlier quoted context omitted.
> The library has a gigantic developer share.. So did jQuery, and that google framework used to create Gmail, what was it called? Oh yeah, nobody cares anymore because they're irrelevant in 2022.
> jQuery I still see it on resumes today. > that google framework Seriously, Google stuff is infamous for being smothered by Google itself, what's your point > nobody cares anymore Literally the only non-Google example you could think of is still popular. But jQuery wasn't a graceful idea with a strong implementation, it was a wrapper to alleviate the pain of browser APIs. React is a wrapper to alleviate the pain of…