4 ms·

I'm a skeptic of the promises of reactivity and a fan of web assembly, but the main reason reactivity is a pain is because UIs are inherently a painful domain,

I'm a skeptic of the promises of reactivity and a fan of web assembly, but the main reason reactivity is a pain is because UIs are inherently a painful domain, not because of JS itself.

dolni 5y ago
Web browsers have had callbacks for DOM elements since... forever. Why did we need to add an entire component framework like React on top of it? Everything on a web page does not need to be interactive. It's a document first. Web applications are cool. Maybe React makes sense there. _But every site does not need to be a web application!_ And yet somehow, React and company became the industry default.
- culi 5y ago
  React doesn't have to be your whole website. Even the starter tutorial in the docs starts off by showing you how to just add in React through a CDN and make a react app as a single component of a bigger webpage Obviously that's not at all how it's used in practice (or even in the create-react-app template), but I do think there's a place for something like React
- eyelidlessness 5y ago
  I agree with you to the extent that components = interactive. But there are other benefits of a component model, even for pages which are mostly static. They allow you to develop the same page and its various (reusable) parts with the same code for rendering the static parts and the dynamic parts. This is especially nice on sites where the dynamic-to-static ratio may vary significantly between pages, or between areas of the same page. This use case hasn’t been particularly well supported by many component libraries (React among them; Marko being a long time notable exception), but it’s an area that’s currently having a bit of a renaissance: there is of course Marko which has supported this model for years, joined by other notable frameworks like Astro and Qwik. Even React is moving more in this direction with Server Components, just targeting other use cases. The component model will continue to thrive, not because everything is interactive, but because components are an excellent abstraction for developing for the web (and a lot of other formats).
dham 5y ago
> UIs are inherently a painful domain No they aren't. Developers think their a painful domain because they are the ones that introduce the complexity in the name of the customer who doesn't care, to increase the developers salary in some kind of crazy Ponzi scheme.
- steve_adams_86 5y ago
  I’ve been working on UIs for 15 years and when I read comments like this I have to wonder if you’ve worked on complex, stateful, feature-rich UIs. The potential for bugs to appear is almost exponential as you add layers, and it isn’t really the fault of the developer so much as the nature of nested behaviours. This is true in any environment, but easier to manage when human beings aren’t the ones executing your code in non-deterministic ways in variable execution settings. The tools we have in the browser are excellent up to a point. I think the challenge comes when you need to create reusable abstractions around them several layers deep. There are tools which help manage these challenges really well, like state charts, but they aren’t perfect and they come with their own challenges. The reality (I think) is that UIs can present quite incredible complexity, and creating tools with approachable APIs to help tame the complexity is a legitimately huge challenge. It could be that I’m a bad software developer (most days I’m pretty sure there’s some truth in that), but I’m passionate and spend a lot of time deep in this space and exploring ways to make it better. It isn’t rocket science, but it isn’t digging holes either. The react team is a bunch of smart people and they’re doing good work on solving a tough challenge. I don’t see a Ponzi scheme at all. Sorry if I’ve missed some sarcasm or something here - feel free to disregard if that’s the case (or if it isn’t, too)
- Strom 5y ago
  Text alone is already a painful domain [1][2] and text is just a small subset of the full UI domain. -- [1] https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/ [2] https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/
- sam0x17 5y ago
  One thing I've found is that things used to be a lot simpler. We've added tons of complexity in the last 15 years, but the fundamentals of web pages and the UI controls in them largely have stayed the same. We've largely moved backwards. And what's worse, I can't even hire junior devs who know how to do things the old simple way anymore. It's framework or bust now.

I'm a skeptic of the promises of reactivity and a fan of web assembly, but the main reason reactivity is a pain is because UIs are inherently a painful domain, not because of JS itself.

dolni 5y ago

Web browsers have had callbacks for DOM elements since... forever. Why did we need to add an entire component framework like React on top of it? Everything on a web page does not need to be interactive. It's a document first. Web applications are cool. Maybe React makes sense there. _But every site does not need to be a web application!_ And yet somehow, React and company became the industry default.

culi 5y ago
React doesn't have to be your whole website. Even the starter tutorial in the docs starts off by showing you how to just add in React through a CDN and make a react app as a single component of a bigger webpage Obviously that's not at all how it's used in practice (or even in the create-react-app template), but I do think there's a place for something like React
eyelidlessness 5y ago
I agree with you to the extent that components = interactive. But there are other benefits of a component model, even for pages which are mostly static. They allow you to develop the same page and its various (reusable) parts with the same code for rendering the static parts and the dynamic parts. This is especially nice on sites where the dynamic-to-static ratio may vary significantly between pages, or between areas of the same page. This use case hasn’t been particularly well supported by many component libraries (React among them; Marko being a long time notable exception), but it’s an area that’s currently having a bit of a renaissance: there is of course Marko which has supported this model for years, joined by other notable frameworks like Astro and Qwik. Even React is moving more in this direction with Server Components, just targeting other use cases. The component model will continue to thrive, not because everything is interactive, but because components are an excellent abstraction for developing for the web (and a lot of other formats).

dham 5y ago

> UIs are inherently a painful domain No they aren't. Developers think their a painful domain because they are the ones that introduce the complexity in the name of the customer who doesn't care, to increase the developers salary in some kind of crazy Ponzi scheme.

steve_adams_86 5y ago
I’ve been working on UIs for 15 years and when I read comments like this I have to wonder if you’ve worked on complex, stateful, feature-rich UIs. The potential for bugs to appear is almost exponential as you add layers, and it isn’t really the fault of the developer so much as the nature of nested behaviours. This is true in any environment, but easier to manage when human beings aren’t the ones executing your code in non-deterministic ways in variable execution settings. The tools we have in the browser are excellent up to a point. I think the challenge comes when you need to create reusable abstractions around them several layers deep. There are tools which help manage these challenges really well, like state charts, but they aren’t perfect and they come with their own challenges. The reality (I think) is that UIs can present quite incredible complexity, and creating tools with approachable APIs to help tame the complexity is a legitimately huge challenge. It could be that I’m a bad software developer (most days I’m pretty sure there’s some truth in that), but I’m passionate and spend a lot of time deep in this space and exploring ways to make it better. It isn’t rocket science, but it isn’t digging holes either. The react team is a bunch of smart people and they’re doing good work on solving a tough challenge. I don’t see a Ponzi scheme at all. Sorry if I’ve missed some sarcasm or something here - feel free to disregard if that’s the case (or if it isn’t, too)
Strom 5y ago
Text alone is already a painful domain [1][2] and text is just a small subset of the full UI domain. -- [1] https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/ [2] https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/
sam0x17 5y ago
One thing I've found is that things used to be a lot simpler. We've added tons of complexity in the last 15 years, but the fundamentals of web pages and the UI controls in them largely have stayed the same. We've largely moved backwards. And what's worse, I can't even hire junior devs who know how to do things the old simple way anymore. It's framework or bust now.