3 ms·

> i feel like many people completely forgot about how simple and fast apps can be Most web apps dont have pretenses of being simple. They want to use tools tha

> i feel like many people completely forgot about how simple and fast apps can be Most web apps dont have pretenses of being simple. They want to use tools that have room for growth, that have deep capabilities. And they want to use the really good tools & libraries & technologies that will be used on more complex efforts. Specializing in being lightweight, narrowing the scope of your skills & capabilities is less attractive than getting good at something that works & ideally will also be fast in all cases. I think it's good to reflect nack to 2014, when React was coming out, & think of what rapid development looked like. Hand manipulating dom trees, course grained re-rendering by setting el.innerHTML,... React and the virtual dom were a huge huge performance win. Some up-front load price, but an amazing boon to rapid rapid developmemt, grossly reducing the scope of concerns one had to think about in webdev, & massively speeding up rendering/updates at the same time. React isnt the smallest but holy shit it propelled us into a massively massively faster world. Where development is just so stinking much faster/easier, where there are so mamy less bugs & memory leaks. Thanks react. So why focus on a niche, special purpose skill set? Why go back to hard mode? Is a 30kB preact bundle actually any kind of problem? Is a 100kB react bundle really a problem? > Loading would've been instant, and you don't even need ajax if you can spit html document fast enough - the browser makes it seamless anyways. But no, instead, we do animations and slow down the time to interaction Because it's javascript we can often run the same code on the backend, & store & cache our documents or if it's light weight enough just render it (with already started/initialized workers). Hence: server side rendering (ssr). SSR is very prevalent, actively supported out of the box in newer JS libraries/frameworks like Next. React has had support for "hydrating" a SSR page on the front end for a while, but required some investmemt & didnt just work out of the box. Im very mixed here, about performance in general. On the one hand I want us chasing technical excellence, being fast. But I also see two things, one, that waiting for a second isnt the worst. Second, a huge amount of the slowness is ads and trackers, is shitty other people prpolems that businesses just accept, and developers at a company dont get much say in. Why would we spend iterations dropping load times from 2s to 0.4s when the damned trackers are still gonna make the site take 5s to load anyways?

ipaddr 4y ago
How is developing with react quicker than jQuery for most websites? React never made development faster.. easier to manage complex state but not faster development.
- deleted 4y ago
  [deleted]
- rektide 4y ago
  With jQuery you are working with existing state & ongoingly trying to update it. In some cases you just need to turn on and off a class, but once you start making significant modifications, things get complex. Oops, you just replaced some DOM with some other DOM that's mostly the same, but now all your event handlers are lost- so now you've got to go add yet more band-aids to re-build event handlers. There's constant inter-dependencies when you try to keep working with one piece of state. React hides all that away. The virtual-dom just works. Event handlers all get faithfully reconnected. You never end up accidentally having multiple copies of content or having deleted too much content. As opposed to the DOM's native retained mode rendering, React gives a much simpler immediate mode rendering. And it's often faster. It's easy to do too much work, to end up replacing more than you need to when you are hand-working the DOM. React's diffing algorithm is quite effective at doing just what updates actually needed be done, where-as before I as tech lead would have to go re-walk through my teammates code & tune & optimize it, fix some of the gross inefficiencies. Working the DOM used to be a complex & subtle art. A lot of simple stuff you could just do & it was ok. The API was never delightful, even with jQuery. But there was so much latent knowledge, so many particulars, so many hazards. It, in my view, made even simple things much faster to develop.
  - ipaddr 4y ago
    If your website isn't managing complex state then jQuery will be quicker and easier. If you are making hundreds of dom changes react will be quicker.. but the average website isn't doing this. There should be complexity minimum reached before react can be used.

ipaddr 4y ago

How is developing with react quicker than jQuery for most websites? React never made development faster.. easier to manage complex state but not faster development.

deleted 4y ago
[deleted]
rektide 4y ago
With jQuery you are working with existing state & ongoingly trying to update it. In some cases you just need to turn on and off a class, but once you start making significant modifications, things get complex. Oops, you just replaced some DOM with some other DOM that's mostly the same, but now all your event handlers are lost- so now you've got to go add yet more band-aids to re-build event handlers. There's constant inter-dependencies when you try to keep working with one piece of state. React hides all that away. The virtual-dom just works. Event handlers all get faithfully reconnected. You never end up accidentally having multiple copies of content or having deleted too much content. As opposed to the DOM's native retained mode rendering, React gives a much simpler immediate mode rendering. And it's often faster. It's easy to do too much work, to end up replacing more than you need to when you are hand-working the DOM. React's diffing algorithm is quite effective at doing just what updates actually needed be done, where-as before I as tech lead would have to go re-walk through my teammates code & tune & optimize it, fix some of the gross inefficiencies. Working the DOM used to be a complex & subtle art. A lot of simple stuff you could just do & it was ok. The API was never delightful, even with jQuery. But there was so much latent knowledge, so many particulars, so many hazards. It, in my view, made even simple things much faster to develop.
- ipaddr 4y ago
  If your website isn't managing complex state then jQuery will be quicker and easier. If you are making hundreds of dom changes react will be quicker.. but the average website isn't doing this. There should be complexity minimum reached before react can be used.