41–50 of 168 posts
Can someone tell me why this page needs 13MB of resources to display?
Would love to better understand why the site is pulling in the Babel transpiler in production?
Edit: siblings know more than me, thank you siblings!
If you don’t mind a slight tangent, where would you start today to learn front end development with React such that you learn this sort of thing as you go?
It's quite high quality and the learning environment is great: you're in a live code editor + hear and see the teacher's code/cursor movements.
Can someone tell me why this page needs 13MB of resources to display?
I know that Vercel/Next.js will lazily load in certain JS chunks but there seems to be some mechanism that is loading a ton of stuff up front. Edit: from other comments in this thread, it's the sandbox code, really crazy how much overhead that adds to the page!
Earlier quoted context omitted.
That's a fine idea if you're not expecting the team to grow beyond the original author(s). It's a pretty terrible idea if you're going to do it in a business setting, as the original author(s) will always be it's Achilles tendon, making the project a liability before it even goes into production. Most projects use react or angular because it makes onboarding new members easier, and these frameworks really aren't as b…
How much have you researched this space? Do you know of companies that are successfully building their products with web components? Hint: these would include Adobe, Microsoft, RedHat, and GitHub. How do they onboard new members to their terrible setup, one might wonder?
I can't speak for the specific companies you listed, but the number of times I've heard someone sing praises about a homegrown UI framework at their place of employment is approximately zero. The sentiment expressed about those is generally hatred and agony.
That's not to say it can't be done well, but most don't. Also, a company being able to hire/onboard engineers does not imply that their onboarding process is smooth, or that their house-made framework is well designed.
My personal biggest not-total-comprehension is around Hooks / effects. I've followed tutorials, used them in production, etc. I'm comfortable using them but I also consider them a bit of a black box, which I don't like (e.g. I'm not sure how they're implemented). The other (even bigger) question for me is "why" -- what prompted the React team to change everything over to "effects". Anyone?
Josh's content is always very very high quality. I look forward to him releasing his online React course [0] so that I can recommend it to others who are starting out. My personal biggest not-total-comprehension is around Hooks / effects. I've followed tutorials, used them in production, etc. I'm comfortable using them but I also consider them a bit of a black box, which I don't like (e.g. I'm not sure how they're im…
Can someone tell me why this page needs 13MB of resources to display?
Earlier quoted context omitted.
How much have you researched this space? Do you know of companies that are successfully building their products with web components? Hint: these would include Adobe, Microsoft, RedHat, and GitHub. How do they onboard new members to their terrible setup, one might wonder?
> How do they onboard new members to their terrible setup, one might wonder? I can't speak for the specific companies you listed, but the number of times I've heard someone sing praises about a homegrown UI framework at their place of employment is approximately zero. The sentiment expressed about those is generally hatred and agony. That's not to say it can't be done well, but most don't. Also, a company being able…
I am deeply puzzled by both your and the sibling comment, which suggest that the only way to go is to build a framework. To advance such argument, especially when comparing something to React, is to forget that:
- React also for a long time was advertised as a view-layer library for creating UI components, not as a "framework".
- There've been numerous debates in which advocates of Angular or Ember were suggesting that because of such inherent lack of structure, React apps were always different between projects, as opposed to the clear conventions used in Angular or Ember project. This did not deter React supporters and did not prevent React from succeeding.
- React was created as a library when web browsers did not have a standardized component model; just as jQuery was created as a library when browsers did not have a unified way of interacting with the DOM. Years have passed, and web browsers have matured to the point when a native component model has become a reality. You do not need to home-grow a framework in order to take advantage of them.Josh's content is always very very high quality. I look forward to him releasing his online React course [0] so that I can recommend it to others who are starting out. My personal biggest not-total-comprehension is around Hooks / effects. I've followed tutorials, used them in production, etc. I'm comfortable using them but I also consider them a bit of a black box, which I don't like (e.g. I'm not sure how they're im…
If you don’t mind a slight tangent, where would you start today to learn front end development with React such that you learn this sort of thing as you go?
Absolutely not what I need.
What I want to know is how to build things with React as performant as possible. This discussion of complex and performant apps seems elusive.