Inside a fast CSS engine

Re:Inside a fast CSS engine by matthewmacleod on Tuesday August 22, 2017 @01:17PM (#15074455)

If that’s what you want to do, the you should ‘nice’ your web browser (or use whatever priority mechanism your environment had available). Artificially limiting performance is absolutely the wrong approach!

[ Parent | on HN ]

Re:Inside a fast CSS engine by taeric on Tuesday August 22, 2017 @01:27PM (#15074560)

It isn't artificially limiting. If my browser didn't need all of my cores to perform, we wouldn't be having this discussion. :)

And I seriously question whether my browser needs this to perform well. I am not completely closed to the idea, but I am highly skeptical.

[ Parent | on HN ]

Re:Inside a fast CSS engine by matthewmacleod on Tuesday August 22, 2017 @03:41PM (#15075701)

The fact that it's been done is some evidence that it's required. If it weren't, it's hard to imagine why limited resources would be wasted on it!

Almost every modern device running a browser has multiple cores, and that trend is almost certainly going to increase – so it definitely feels like allowing a core part of the web platform to expand across cores will be beneficial.

[ Parent | on HN ]

Re:Inside a fast CSS engine by taeric on Tuesday August 22, 2017 @04:00PM (#15075849)

I challenge that. That it was done is as much evidence that it was doable as that it was required.

It is also a bloat race. Web pages are getting increasingly complicated. With very little benefit to end users. I'd wager a growing number of the cycles and network requests are going to tracking, nowdays. Not to mention the ui language doing more and more contortions to give us a page that could be much more succinctly described.

None of this is to say I want it stopped. I just have a feeling of concern that this is leading to an ever increasing march to faster and faster machines to do basic work.

[ Parent | on HN ]