6 ms·

I feel like many people completely forgot about how simple and fast apps can be if there aren't tons of layers put on top of one another. Like you have drupal

I feel like many people completely forgot about how simple and fast apps can be if there aren't tons of layers put on top of one another. Like you have drupal with bunch of modules, it's slow as hell so you put redis caching. It's faster but not as fast, so you add varnish on top, so you don't even have to touch the php code unless you make a change. But then you've never solved the problem, you just hide it two layers deep. And same with javascript - 85% of sites are visit would work perfectly fine without any javascript. 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 fine sitting on 1Gbit connection waiting for your slow backend part that's not cacheable. JS isn't bad, it just feels like people think it can solve anything while not seeing issues it adds.

Existenceblinks 4y ago
Yeah, an html attribute on <head> or <body> for not having full page reload would make a big impact.
- linkdd 4y ago
  Like htmx[0]'s boost attribute? I've been building a webapp with Python/Django and HTMX, it works like a charm. [0] - https://htmx.org https://htmx.org
  - Existenceblinks 4y ago
    Sorry, I mean it should be in html spec.
cutler 4y ago
I find Hotwire/Turbo/Stimulus in Rails to be a perfect low-JS approach.
mbirth 4y ago
That JavaScript for loading contents and images is probably an effect of Google's changes a few years ago where it was all about the load time of the main page. So to rise up a few steps on the Google results page, people turned to serving empty pages with a small JavaScript (which finished loading fast - so bonus points from Google) which then starts pulling in the actual content.
- metadat 4y ago
  This is a nice insight. Dear Big-G: Thanks a lot for your hard work, you've really done something.
- saurik 4y ago
  I was under the impression that, because Google would have to execute all of that logic in order to even get the content people are searching for -- as I can't imagine an empty page would actually rank highly for anything ;P -- that they weren't using the time of the first request but the time it took to get the content that they decided was the page.
rektide 4y ago
> 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.
hulitu 4y ago
> I feel like many people completely forgot about how simple and fast apps can be if there aren't tons of layers put on top of one another. There is a trend in OSS SW development to "continously improve " programs. This means that the program stays mostly the same but it gets over time a "gui improvement" which brings almost nothing new but a lot of libraries and bloat. Two programs that stroke me were Xaos ( which got a QT dependency) and Xsnow. Maybe jwz was right that every program evolves until it can send email.
kypro 4y ago
Honestly I think a lot of what you're noticing is the product of junior frontend devs. The nice thing about HTML is that it's really hard to write code that won't load fast, but you can write SPA which load fast, you just need to be more deliberate about how you load things and what you're loading. The problem with SPAs it's easy to create huge bundles pulling in numerous large packages then loading it all in the head where it will block page render. Layer that with some poorly designed APIs and slow JS animations and you have what you're describing. I'm not saying SPAs should always be used because in most cases they shouldn't, but a well optimised SPA should in theory be quicker and provide UX improvements to the user.

Existenceblinks 4y ago

Yeah, an html attribute on <head> or <body> for not having full page reload would make a big impact.

linkdd 4y ago
Like htmx[0]'s boost attribute? I've been building a webapp with Python/Django and HTMX, it works like a charm. [0] - https://htmx.org https://htmx.org
- Existenceblinks 4y ago
  Sorry, I mean it should be in html spec.

cutler 4y ago

I find Hotwire/Turbo/Stimulus in Rails to be a perfect low-JS approach.

mbirth 4y ago

That JavaScript for loading contents and images is probably an effect of Google's changes a few years ago where it was all about the load time of the main page. So to rise up a few steps on the Google results page, people turned to serving empty pages with a small JavaScript (which finished loading fast - so bonus points from Google) which then starts pulling in the actual content.

metadat 4y ago
This is a nice insight. Dear Big-G: Thanks a lot for your hard work, you've really done something.
saurik 4y ago
I was under the impression that, because Google would have to execute all of that logic in order to even get the content people are searching for -- as I can't imagine an empty page would actually rank highly for anything ;P -- that they weren't using the time of the first request but the time it took to get the content that they decided was the page.

rektide 4y ago

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

hulitu 4y ago

> I feel like many people completely forgot about how simple and fast apps can be if there aren't tons of layers put on top of one another. There is a trend in OSS SW development to "continously improve " programs. This means that the program stays mostly the same but it gets over time a "gui improvement" which brings almost nothing new but a lot of libraries and bloat. Two programs that stroke me were Xaos ( which got a QT dependency) and Xsnow. Maybe jwz was right that every program evolves until it can send email.

kypro 4y ago

Honestly I think a lot of what you're noticing is the product of junior frontend devs. The nice thing about HTML is that it's really hard to write code that won't load fast, but you can write SPA which load fast, you just need to be more deliberate about how you load things and what you're loading. The problem with SPAs it's easy to create huge bundles pulling in numerous large packages then loading it all in the head where it will block page render. Layer that with some poorly designed APIs and slow JS animations and you have what you're describing. I'm not saying SPAs should always be used because in most cases they shouldn't, but a well optimised SPA should in theory be quicker and provide UX improvements to the user.