[fxbl0i]

I assume people who don't think about DOM manipulation and the performance toll it takes are responsible for how slow the web is today and, what's even worse, how that waste of CPU has been pushed from the server to the client.

[StevePerkins]

I assume the web is slow today due to packing a couple megabytes of libraries, and adware / tracking malware, into each page load. More so than two milliseconds of jank in how you constructed that SELECT pulldown.

I don't believe that contemporary webdev's main problem is how we construct a SPA. I think it's the assumption that everything needs to be a SPA.

[ryanbrunner]

There's downsides with every approach though. While taking a "render HTML and manipulate DOM" approach falls down hard when the DOM mutations become frequent or complicated enough that they take a performance toll, the alternative most commonly peddled, "ship JSON and let the client render everything" has increased in massively increased JS bundle sizes and horrendous initial load performance on many sites.

I suppose there's the alternative of "ship HTML and forget about Javascript for the most part", but very, very few people are following that nowadays, and besides which, JQuery supports a "Javascript not required" progressive enhancement model far far more than most other front-end frameworks.

[keanebean86]

I wrote a spa at my last job using jQuery. It rendered page fragments on a php backend, detached the current fragment, saved it, then appended the new fragment. If a fragment was already downloaded it would hydrate by ajaxing some json.

It was extra work and sometimes brittle but it was also my first "big" web project. Even though it didn't use all the cool new libs and build tools I still learned a lot from it.

[sh87]

Can you please point me to some evidence of how bad DOM manipulation actually is ? Its worked just fine for all my professional use-cases so far. Enlighten me!

[peteforde]

crickets