If I push enough shit in my DOM, even Chrome is too slow!!!1


  • area_deu

    Wow. Just... wow. This is a guy that rates fucking IE 10 over Chrome.
    WELL IF CHROME IS TOO SLOW FOR YOUR FUCKING "APP" THEN MAYBE YOUR "APP" IS SHIT.

    keep your JS/HTML/CSS payload under 1MB
    You want to keep a fairly low DOM node count, I target <5k nodes, ideally peak at <10k nodes
    Be very careful not to create too many GPU layers, especially nested ones.
    Get a smarter build pipeline

    I really don't know what to say here.

    Embrace "no work"

    No. "No work" is exactly what brought us here. "Oh no, I'd have to think for a minute before I write this function so that it does what I need. I better pull in some package that might already do that. Or better yet, I'll use Ember."

    Fuck you and fuck your idea of web development.



  • Yup and we got the same thing going on here, it's awesome, we get to see it in real-time.

    "Your mobile view is broken, it shows up all the time when it shouldn't."

    "Our framework does that! Shrug! We're helpless to fix it! Shrug! Not our bug! Shrug!"

    Quality software is dead. Dead and buried.


  • Fake News


  • area_pol

    My experience is actually opposite to his.
    I use Firefox and Chromium. Once I experimented with writing games with JS + HTML5 canvas. Testing revealed that Chromium has consistently higher FPS in the games than Firefox.

    I suspect the situation is similar on android, with Chrome being slightly faster and Firefox having more features (extensions).

    Also, my Android phone is over a year old and has no problem running even discourse (it was slow and unresponsive but not much more than in a desktop browser).
    If his site's performance is "painfully bad", his site must be "painfully bad".



  • @ChrisH said in [If I push enough shit in my DOM:

    really don't know what to say here.

    Embrace "no work"

    No. "No work" is exactly what brought us here. "Oh no, I'd have to think for a minute before I write this function so that it does what I need. I better pull in some package that might already do that. Or better yet, I'll use Ember."

    Way to reply to your own imagination of what he said than the fucking words that were right there on the page. Firstly, the point right before that one he had already warned against pulling in unnecessary dependencies, secondly, the ‘no work’ he's talking about there is no work being done by the browser, as in: making use of compile-time optimization, lazy evaluation where appropriate, etc.

    Since you apparently didn't read past the word ‘Ember’, I'll go ahead and provide a summary of what the article is actually about:

    Apparently chrome introduces new features before any otherbrowsers, before the features are standardized, and then has such shitty performance on android that developers are forced to use all of those features just to break even. Embrace/extend/extinguish all over again



  • @blakeyrat said in [If I push enough shit in my DOM:

    "Your mobile view is broken, it shows up all the time when it shouldn't

    Goddamn. Can't you keep this bullshit in your own thread?


  • Winner of the 2016 Presidential Election

    @boomzilla said in [If I push enough shit in my DOM:

    @blakeyrat said in [If I push enough shit in my DOM:

    "Your mobile view is broken, it shows up all the time when it shouldn't

    Goddamn. Can't you keep this bullshit in your own thread?

    QFT



  • @boomzilla said:

    @blakeyrat said in [If I push enough shit in my DOM:

    "Your mobile view is broken, it shows up all the time when it shouldn't

    Goddamn. Can't you keep this bullshit in your own thread?

    He did, but the mobile view reflowed it into other threads.



  • @boomzilla said in [If I push enough shit in my DOM:

    Goddamn. Can't you keep this bullshit in your own thread?

    Look at what's in my thread right now. Abandon fucking ship, man.



  • His comments about Chrome being slow is utter shite. We had some guys even test the CSS selectors and they were objectively faster than IE10 on mobile, JS selectors were faster than IE10 on mobile. All these tests were using pure JS and Pure CSS.


  • area_deu

    @Buddy said in If I push enough shit in my DOM, even Chrome is too slow!!!1:

    Way to reply to your own imagination of what he said than the fucking words that were right there on the page.

    Yeah, I should have stopped reading at "IE10: B".

    what the article is actually about:

    The article is about somebody writing shitty "apps" in JavaScript and then complaining when they suck. That's all I needed to know.


  • area_pol

    You want to keep a fairly low DOM node count, I target <5k nodes, ideally peak at <10k nodes and I make heavy use of occlusion and recycling to achieve that.

    I would like to know what his application actually is that he needs such a big DOM. Is this a 100x100 spreadsheet that he wants to run fast on a mobile device?
    If it is something usual, like an interactive form, let's say with 10 fields, and we give 10 nodes for each field (some layouting divs, labels, validation error messages), I would expect a dom size of 100-1000, not 5k.

    Also there is a limit to how many pieces of information I want to focus on one site. And if his application indeed has those 10k nodes, I suspect most of it is trash that just disturbs reading the important parts.



  • @Adynathos

    jQuery("*").length
    

    Says that this thread here has over 1000 nodes and what.thedailywtf.com has 2500 nodes.
    And when I scrolled down to last week's threads then my browser had already loaded 18000 nodes.



  • @julmu I actually want to point out that DOM node count isn't always a reliable indicator of whether a site is "slow" from a UX perspective.

    I ran document.querySelectorAll('*') on a couple sites for reference:

    • on NodeBB, this topic contains 1148 nodes
    • on a topic in Discourse, I got a count of 751 after opening a 22 post thread and scrolling to the very end
      • Interestingly, it started off around 970, but removed a bunch of elements as I scrolled
      • However, arguably, Discourse does much more DOM manipulation than NodeBB does, and this negatively impacts UX in terms of responsiveness especially on mobile devices
    • on Reddit's front page, the node count is 2282, yet the page loads very quickly and navigates fluidly on my mobile phone

    So DOM node count might actually be just as reliable as judging developer skill via LOC delta. Just saying...



  • @julianlam This makes sense.

    Discourse, for example, keeps very few posts in the DOM, "to save memory", dynamically adding and removing them from as you scroll. But they are still stored somewhere in memory as Javascript data. So what's the point of that? Let the browser handle the page! It's been optimized for that!

    Seriously: a static page with 1,000 user comments is much more fluid than a Discourse "page" showing just 20 comments.

    Maybe a better metric would be something like javascript events per second, measured during normal website usage?



  • @anonymous234 Here's the timeline view of this thread for approximately 10 seconds:

    0_1459093422597_Screenshot 2016-03-27 at 10.41.16.png

    Here's the timeline view of the first thread on meta.d for approximately 10 seconds:

    0_1459093464735_Screenshot 2016-03-27 at 10.43.11.png


  • sockdevs

    @ben_lubar …I knew Discourse was a poor performer, but two orders of magnitude worse on scripting alone‽


  • Discourse touched me in a no-no place

    @RaceProUK said in If I push enough shit in my DOM, even Chrome is too slow!!!1:

    two orders of magnitude

    But at least it does 75% less Idle!

    Waitaminute…



  • @blakeyrat said in If I push enough shit in my DOM, even Chrome is too slow!!!1:

    Quality software is dead. Dead and buried.

    it is for a long time now, you need to let it go and move on


  • Winner of the 2016 Presidential Election

    @fbmac said in If I push enough shit in my DOM, even Chrome is too slow!!!1:

    @blakeyrat said in If I push enough shit in my DOM, even Chrome is too slow!!!1:

    Quality software is dead. Dead and buried.

    it is for a long time now, you need to let it go and move on

    It is, was, and always has been... you need to let go of that fantasy and give up on the concept of good software.

    Yikes, software dev is nihlistic, isn't it?



  • Anything that does any DOM manipulation is going to be slow, this is like JS performance 101. This is why a lot of frameworks now do "virtual dom diffs" and then write to the page. Mithiril, Angular 2 and React are prominent frameworks that come to mind.


  • area_deu

    Oh look, someone has found the solution to all your Ember-related performance problems!

    FastBoot works by running your Ember application in Node.js. When a user visits your site, the initial HTML is rendered and served to the user. The very first thing they see is your content.

    Only after the content has loaded do they start downloading JavaScript. Once finished, your app takes over. You get the same snappy performance you're used to from Ember apps.

    :rofl:



  • @ChrisH "Hey this JavaScript thing sucks so we've added extra layers of JS to make it better, honest"
    That's the sort of thinking that gets you Discourse.



  • @loopback0 said in If I push enough shit in my DOM, even Chrome is too slow!!!1:

    you Discourse

    And complete madness



  • @loopback0 said in If I push enough shit in my DOM, even Chrome is too slow!!!1:

    @ChrisH "Hey this JavaScript thing sucks so we've added extra layers of JS to make it better, honest"
    That's the sort of thinking that gets you Discourse.

    "Hey, this javascript thing sucks, so let's render server-side and serve the html"

    {fidgets gets nervous OCD kicks in}

    "okay let's add in some javascript now just a bit and use it to load more javascript AND MORE JAVASCRIPT AHHHHHHHHHHHHHH!"


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.