undefined | Better HN

0 pointsbranko_d5y ago0 comments

> Plain HTML renders several order of magnitudes faster than post-load JS rendering

Well, "several orders of magnitude" is a bit much, but the point stands.

However, that's only during the initial load. After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again. If done properly (and that's a big if!), and where appropriate, this can be much faster.

> Most web devs develop on localhost and test on some of the best connections you can get today, leaving network performance testing as an afterthought at best... and it shows.

Very true! And on beefeir CPUs/GPUs, more RAM, faster storage etc.

For the last couple of years, I've been careful to develop on "midrange" hardware, exactly so I can spot performance problems earlier.

0 comments

forgotmypw175y ago

> However, that's only during the initial load.

Primary and by far most frequent use case.

> After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again.

And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly.

Anyone who doesn't support JS to the level you want? Well, fuck those people, let them make their own wheelchair ramps.

> If done properly (and that's a big if!), and where appropriate, this can be much faster.

A big IF, indeed.

branko_dOP5y ago

I think you have "document paradigm" in mind.

For "application paradigm" my points stand. That's where JS is appropriate. I did say "where appropriate", after all.

> Primary and by far most frequent use case.

In document paradigm.

> And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly.

Not if the client-side routing is done properly. I did say "if done properly".

> Anyone who doesn't support JS to the level you want?

With modern transpilers, you can produce lowest-common-denominator JS. Essentially you are treating JS as a build target / ISA.

> Well, fuck those people, let them make their own wheelchair ramps.

What's the alternative? They can download a native app, but that doesn't work for everyone either (both from the developer and the user perspective).

forgotmypw175y ago

The alternative is HTML, which is accessible to most.

j / k navigate · click thread line to collapse

0 pointsbranko_d5y ago0 comments

> Plain HTML renders several order of magnitudes faster than post-load JS rendering

Well, "several orders of magnitude" is a bit much, but the point stands.

> Most web devs develop on localhost and test on some of the best connections you can get today, leaving network performance testing as an afterthought at best... and it shows.

Very true! And on beefeir CPUs/GPUs, more RAM, faster storage etc.

For the last couple of years, I've been careful to develop on "midrange" hardware, exactly so I can spot performance problems earlier.

0 comments

forgotmypw175y ago

> However, that's only during the initial load.

Primary and by far most frequent use case.

> After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again.

And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly.

Anyone who doesn't support JS to the level you want? Well, fuck those people, let them make their own wheelchair ramps.

> If done properly (and that's a big if!), and where appropriate, this can be much faster.

A big IF, indeed.

branko_dOP5y ago

I think you have "document paradigm" in mind.

For "application paradigm" my points stand. That's where JS is appropriate. I did say "where appropriate", after all.

> Primary and by far most frequent use case.

In document paradigm.

> And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly.

Not if the client-side routing is done properly. I did say "if done properly".

> Anyone who doesn't support JS to the level you want?

With modern transpilers, you can produce lowest-common-denominator JS. Essentially you are treating JS as a build target / ISA.

> Well, fuck those people, let them make their own wheelchair ramps.

What's the alternative? They can download a native app, but that doesn't work for everyone either (both from the developer and the user perspective).

forgotmypw175y ago

The alternative is HTML, which is accessible to most.

j / k navigate · click thread line to collapse