3 ms·
>It's mostly comprised of content that is static in its nature Yes, but the readers of the content are not the only customers the site is built for. The people
by freehunter 7y ago
>It's mostly comprised of content that is static in its nature
Yes, but the readers of the content are not the only customers the site is built for. The people writing and editing content are also consumers of the site. The article isn't (and doesn't have to be) interactive, but the CMS on the backend is. The advertiser's portal is. The reporting dashboards are.
Just like how Ruby on Rails is slow but we deal with it because it makes programming so much faster, dynamic websites are slow but we deal with it because it makes their administration so much faster.
- yellowapple 7y agoThe authoring tools and the published article don't have to (and I'd argue shouldn't) be joined at the hip like that, though. Obviously the editing tools benefit from being JS heavy. That doesn't justify polluting the published article itself with JS (unless the readers are editing the article themselves? Even then, though; Wikipedia seems to get by just fine without trying to replace half my browser with shitty JavaScript code). > Just like how Ruby on Rails is slow but we deal with it Not all of us :)