11 ms·

CSS Purge

190 points by tnorthcutt 10y ago

theaustinseven 10y ago
Yes, CSS might be a big problem, but people's obsession with overriding everything with Javascript is a much bigger problem. I think web developers/designers need to move more towards lighter webpages that use HTML for functionality whenever possible, which is something that might seem obvious, but is so rarely done.
- Smudge 10y ago
  For a while I worked on and made use of a very lightweight JS framework that would essentially do two things: * Intercept link clicks and form submissions and perform the exact same request asynchronously (AJAX) * Wait for the server to respond with the parts of the page that need to be swapped-out (a JSON map of section IDs to plain HTML content) and, as expected, swap out those parts of the page. This works REALLY well for, like, 80% of my use cases. With a little extra flavor functionality (such as automatic loading indicators and event listeners) I can enable like 90% of interactivity. The remaining 10% consists of things that affect only temporary state and don't require a server round-trip (e.g. a "select all" checkbox), and those I would handle with more traditional jQuery DOM manipulation. For the most part, once I had this basic system in place, I could rely on the server to render (and re-render) all of the HTML and rarely had to write any custom Javascript. I was essentially relying on the behavior of vanilla links and forms. The site would even continue to function if you disabled Javascript, because the server would see that it wasn't AJAX and just render the whole page instead. The downside was that preserving local state (e.g. partially completed form fields) was tricky whenever I had to make a change to one of its parent containers. Everything I learned about this approach eventually led me to appreciate what React.js is doing. I've been using it and I may not like all of its API or how heavy it feels overall, but the cycle of rendering and re-rendering different parts of the page feels very natural and is far easier to debug than most JS-heavy front-ends.
  - gkya 10y ago
    Why just don't let the hyperlinks do what they are supposed to do, which is what you do at the end of the day anyways, then? When I approach a link, I hover, see the href on the status bar, think and decide, and click. Thereafter, I expect it to take me somewhere else, while the browser pushes the url of the page I left into a stack, the history. This implemented and working in my browser already, why redo it with JS? To lower the load time? Then don't make the page multi-meg already, no? The ugly thing is govt websites and such are adopting a similar style of web app design, relying upon wizardy and tricks and hacks, for example, I sweat blood when I use my uni's web pages because I'll hit a bug in the js for an already-there popup or a button and it'll hurt my educational career.
    - TeMPOraL 10y ago
      The truth is, it's all because most websites are really ads, and they have to follow the fashion - otherwise you risk sending a message that your company or project is bad in some way. Web is a fashion-driven industry and any usability or ergonomics is not even a secondary consideration.
      - gkya 10y ago
        I made a website for my uncle's tile business. Real, international business with an office in the UK. I made it with ~180 lines of CSS, ~30 lines of JS ~20 lines of GNU (1) m4, and 60 lines of make. Got positive impressions from everybody he works with and probably improved our sales. External JS included, the WHOLE website source weighs in at 150 kb without images, with multiple pages, a gallery with a lightbox and on a proper grid (github.com/ThisIsDallas/simplegrid), a custom Google Maps map via the API, a carousel, and a consistent colour scheme, all done in an afternoon. And once compiled, the product weighs less than the source. I guess the problem is nowadays the designer folk gets to say too much on the development of websites and web standards. There is no prerequisite to become one. If you didn't study CS in depth, at the uni or by yourself, you can't do embedded, OS dev, etc., but mashing together some stuff from Github you become a web designer, no qualifications needed. Here we have a website that talks about bloat and lists nine or ten tools that have well established, better, more generic counterparts. Generating a file from another via a filter program (minifier, m4, awk, coffeescript compiler...) is what make excells at. Replacing strings is what m4, awk and sed do since 1980's. We don't expect from the designer folk to know anything about the basics of computing. And they spend their time duplicating and triplicating and quadruplicating effort spent decades ago to end up doing the same thing, only worse, and when it comes to actual work, all they do is mix and match some libraries and add bloat after bloat, instead of looking to see what needs to be done, and doing it, using the tools already available and fit. (1) Otherwise I'd have to implement a foreach macro, which would take some 10 lines more.
- Nadya 10y ago
  I agree with this entirely. The problem boils down to managers/designers hating default. As an example, take form behaviors. Default forms work. Built-in browser verification (for supported browsers) works. You can even have it match a regex! Built into the browser! Dropdowns in browsers? Those work too! So do radio buttons and checklists! Instead, people are tasked to reinvent the wheel and create their own hacky dropdown lists because they want things sorted into groups (what is an <optgroup>?) and they want super precision over how the list ends up getting styled. As a consumer: I absolutely hate this. I love browser defaults because I can expect all forms to just work. If I hit the letter "G" in a dropdown list I know how it will function! All of this knowledge is tossed to the side unless the reimplementation tries to remain faithful to the browser defaults. I know some developers are guilty of wanting to make custom things too - but by far it is a problem with clients and management. I always have to fight against anything that would change default browser behaviors because the UX on such things is terrible 99% of the time or whatever implementation via JS is going to either take a large amount of time or be buggy as hell.
  - Keats 10y ago
    Some defaults are pretty damn ugly though, just missing or not consistent between browsers. For example the input type date or range to only name 2. The browsers errors on html5 validation are equally ugly imo.
    - Nadya 10y ago
      You can still style them differently! I was focusing on functionality. Your users are going to primarily be using a single browser (per device) and expect each device to be, at least, consistent with itself. This is an area I feel devs make the largest mistake: they want browsers to conform to one another. That means they'll break default functionality to get there! I'm of the opinion the browser should change. That allows users of the browser to adapt to the new default (because every site will then be consistent for the user!) Functionality can differ between browsers [0] and your IE users will expect the numeric input field to function like it does in IE. Not like it does in Chrome/FF/Safari. Meanwhile, your Chrome/FF/Safari people will expect it to function how it does by default in their browsers. You shouldn't override or change this functionality because it breaks user expectations. Overriding IE because it is the "odd one out" will break expectations for users using IE! It doesn't matter so much if the experience is different for each user so much as the experience is consistent for each user within their environment. [0] https://css-tricks.com/numeric-inputs-a-comparison-of-browser-defaults/ https://css-tricks.com/numeric-inputs-a-comparison-of-browse...
WA 10y ago
And there, I thought for a moment, my 38 KB CSS file is a mess and way too big. I guess, this puts it into perspective.
- theandrewbailey 10y ago
  My blog's CSS is 100k. Take out the three embedded base64 webfonts, and it's 6k.
  - WA 10y ago
    Do you know a tool that turns Google webfonts into base64 for direct embedding?
    - theandrewbailey 10y ago
      https://www.fontsquirrel.com/tools/webfont-generator https://www.fontsquirrel.com/tools/webfont-generator Choose expert.
  - davidwparker 10y ago
    My blog's 2.4kb. It's way too big (and my blog sucks on mobile). I've been rethinking about how I can redesign my blog to be as close to http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/ as possible.
    - Nadya 10y ago
      965 bytes for mine. I should (but didn't, will tonight) minify the CSS, which will bring it down to 650 bytes. My site is very much in line with BMFW and IMO it looks pretty nice. But it's also very, very basic. There are very few things that I would style for a text-based website: 1) The h1, h2, p, strong, and a elements. Font-family, font-size, color, a:hover, and line height attributes only. 2) Create a container (eg: max-width 44em, margin: 0-auto, width: 100%) to wrap everything in. From there the "heaviest" parts of the blog would be navigation and how accessible you want a complete archive list to be or if Previous/Next links would be suffice. E: 800px -> 44em, see response below.
evbogue 10y ago
http://gitmx.com/ev/reserva http://gitmx.com/ev/reserva is only 5.4k
- dsego 10y ago
  h1 { color: #333; } is only 20 bytes
colmvp 10y ago
Why do some of these sites have font families numbering in the double digits?!
- KevanM 10y ago
  Designers.
  - paublyrne 10y ago
    Bad designers.
- wmeredith 10y ago
  Design by committee, legacy UI pattern support, browser support and accessibility fallbacks, excess frameworks, and do on... Designers on big projects share a lot of the same challenges with programmers. Edit: I'm not saying it's right. I'm saying I understand.
onion2k 10y ago
Unless data can demonstrate that reducing the number of classes or IDs on a page has a positive impact on things like returning DAUs, sign up conversions, etc, I'd argue these might be the wrong things to optimise. If adding another font to your site gets another 1% of users to buy something, you should add the font. Equally thought, if removing one gets 1% more sales, you should remove one. That's what counts, and it won't be the same for every site. Use data, not rules.
escape_goat 10y ago
Are you really sure you need to steer this conversation towards dispute? Because basically you're criticizing someone's experience of how they gracefully integrated ajax once upon a time. Like, in the past. I don't want people on HN to stop telling me what they did and how they handled situations, in the past, because they keep seeing that whenever someone like Smudge does that, someone like gkya really, really, urgently feel the need to tell them how they did it all wrong.
- gkya 10y ago
  > I don't want people on HN to stop telling me what they did ... because ... whenever ... Smudge does that, someone like gkya really, really, urgently feel the need to tell them how they did it all wrong. i.e. they discuss, on a discussion forum? > ... you're criticizing someone's experience of how they gracefully integrated ajax once upon a time. Like, in the past. Yes, what's the problem with that? He, as a developer, poses a way to do something, and I refute it as a person on the other side of the wire, i.e. the user/hacker. Where else than Hacker News is more apt for this sort of discussion?
  - deleted 10y ago
    [deleted]
  - escape_goat 10y ago
    My tone, previously, was not entirely useful, so firstly my apologies for that, I could have said the same thing in a less aggrieved way. As to your questions, well, I'd like you to consider my words in the context of the distinction between discussion, debate, and dispute. I believe I already adequately addressed what the "problem with that" was, but I'll reiterate it more clearly. Smudge was telling a story about a solution that he applied to a problem he was facing at one time, what the benefits and drawbacks of it were, and how it eventually led him to have respect for the value of React. He was sharing history. It was interesting. It would be interesting to discuss it if one had questions about the technical aspects of the thing he had done in the past, which he had shared with the audience in this forum, or rejected a similar solution at that time for reason one cared to describe. Smudge was not introducing or participating in a debate. He did not state a proposal. He did not invite a counter-proposal. He did not advocate anything. There is no debating that he did this thing. There is no debating that he did it for the reasons that he described. There is no debating that he came to the conclusions as a consequence of this experience that he shared with us. The statements that you have made seem to show a pattern of inattention to what is actually being said. You are not debating with anyone. Smudge did not intend to invite a debate, and he should not have had any reason to think differently. Instead, your behaviour is obnoxious, self-involved, and anti-social, because it would tend to discourage people who did not want to engage in debates with you from sharing history with the audience of the forum. What you were pursuing changed from debate to dispute. Firstly, rather than rebut points that had been made in the context in which they arose, you pursued disagreement beyond the bounds of the actual context of the matter under discussion. To give an example, whether or not "browsers are very smart these days" is not material to a discussion of how one developer implemented ajax updates with graceful degradation once upon a time when browsers were not very smart. You were not debating with Smudge, most basically because Smudge did not want or try to have a debate with you. You were not debating with Smudge because your statements were of little value in the context of what the topic of a debate would have been --- which would be something akin to 'decisions web developers made when faced with web developer problems [once upon a time]' --- and, by themselves, suggested that you were actually unfamiliar with this topic. Your words suggested a desire to turn a discussion into a dispute about a topic that Smudge was not discussing, and which was so tangentially related to the actual topic at hand that I would have found your need to dump your opinions upon this person as argumentation offensive even had you not stretched them to the ridiculous conclusion that front-end web development was a rent-seeking activity. To add the final part to what I had said before: behaving like this will discourage people from sharing their opinions and experiences. Just because someone said something, it does not mean that they or anyone else cares that you have opinions about a related topic or that that person is inviting you to criticize them. Wait until the lines of an actual debate have actually formed before you attempt to engage in a debate with someone, and never, never crash someone's thread in order to insist that they must debate you regarding a topic you yourself have brought to the table. Extending the reply to your last statements: firstly, no, Smudge did not propose a way to do something. You misread what he wrote. My apologies for the bewilderment that my response must cause you if you genuinely, rather than wilfully, misread what he wrote. However, he did not invite a debate, and your behaviour was not appropriate. If you thought that it was, it would serve you well to learn why it was not. Secondly, you did not 'refute' what he said. Your statements bore no relation to a refutation. "Everyone should use the latest web browser" is no more a solution to a problem than "Everyone should eat cake". Telling a person that they should use the 'default widgets' rather than write a very thin javascript library because you don't like too much javascript is confusing. What 'default widgets'? What do you mean by that... jQuery widgets? HTML does not come with 'default widgets'. Yes a lot of websites are clogged with useless shit, and yes you have a perfect right to not like this. But you can't 'refute' the decisions that a web developer makes "from the other side of the wire", and this is true of anything else or any other similar situation. You can't 'refute' a judicial decision on the basis of your own interpretation of written law. You have to learn about actual law first. You have to come to his side of the wire first. You could certainly refute mis-statement of fact, if you knew it to be incorrect, but you cannot refute a decision without understanding the context in which it was made.
andrethegiant 10y ago
I see many articles warning not to deeply nest selectors in sass. Doesn't gzipping your resources mitigate that problem?
- digestives 10y ago
  File size is a moot point with regards to long selectors - they are just a bad idea. [1][2] I am a fan of BEM to keep things sane. [3] [1] http://csswizardry.com/2012/05/keep-your-css-selectors-short/ http://csswizardry.com/2012/05/keep-your-css-selectors-short... [2] https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/ https://benfrain.com/css-performance-revisited-selectors-blo... [3] http://getbem.com/ http://getbem.com/
- dsego 10y ago
  Nesting selectors ties the css to your markup. These styles are not reusable components, but one-offs for that particular snippet of html. Look how bad it can get: https://github.com/edx/edx-platform/blob/master/lms/static/sass/course/courseware/_sidebar.scss https://github.com/edx/edx-platform/blob/master/lms/static/s... It's basically replicating the html nesting.
spankalee 10y ago
Shadow DOM and it's scoped styling is going to help this situation so much. Instead of large stylesheets with tons of highly-specific selectors, and quite a few broken and unused rules, web components will be able to use small stylesheets with simple selectors that only apply to their local scope, and developers will be able to reason about and maintain styles that are limited to a single web component.
oliv__ 10y ago
Ummm... Default or die: 15 tools? I thought I was just making a website here: you know HTML, CSS, and a dash of Javascript. ...Guess not.
partiallypro 10y ago
I dream of a day when you can have CSS loaded that has no dead weight. If one page doesn't have an accordion, there's no point in it loading the accordion CSS. Foundation slimmed down their base CSS files because it had so much dead weight from 5 to 6; but I wish there were some way (and I have seen some projects on GitHub) that I could load a page and it only would load the CSS needed for that page, but would still cache the common assets.
- onion2k 10y ago
  What problem would that solve?
  - partiallypro 10y ago
    Your server serving up tons of code that is not being used at all?
    - onion2k 10y ago
      That would assume the user is only going to view one page. If they look at several pages then it'd be better to have sent all the CSS necessary in the first request and have their browser cache it. If you only send the styles necessary for the page they're looking at then you lose all the benefits of caching. That's a far bigger problem than sending a bunch of unused code.
- CM30 10y ago
  Isn't this basically using a default 'main' CSS file and a bunch of small extra ones loaded on a per page basis? You can do that pretty much simply with most CMSes out there, or through rudimentary scripting. Though being able to do that with a single CSS file would be nice to see...
rhubarbquid 10y ago
This site is pretty CPU heavy for something reminding us to respect our users' resources...
phillipwills 10y ago
This site crashes Firefox mobile after being open for a few minutes... Sad...
- Washuu 10y ago
  I was thinking maybe it was just you. I tabbed back to the web site, Firefox desktop immediately began to crash.
known 10y ago
Brilliant analysis and presentation; Thank you;
- xufi 10y ago
  Indeed it is. Brushing up on CSS here myself. Its amazing to see the different sites that use more CSS like Wikipedia.
nmbr213 10y ago
It's funny how they say CSS should be optimized, while they use 6 different JS files for particle animation (one for each site + header, the only difference being canvas size, particle count and color)
royquilor 10y ago
Hi everyone, Thanks for the feedback and it has been insane. 3 big sites have accepted the challenge to purge their css. Css is just a small part of the bigger picture. Lots more topics to discuss, but i just focus on CSS. I've dealt with a large site working with 4 developers. I have failed a adapting a big site to be lean on their CSS, hence looking at different ways of doing your styling.
cheshire137 10y ago
I think they could spare a few more characters to set their body background-color. I have a custom dark gray color set in my Firefox CSS so the new tab page doesn't flash white when I open it at night, and the site shows that dark gray, making their tables and text pretty hard to read.

190 points by tnorthcutt 10y ago

Yes, CSS might be a big problem, but people's obsession with overriding everything with Javascript is a much bigger problem. I think web developers/designers need to move more towards lighter webpages that use HTML for functionality whenever possible, which is something that might seem obvious, but is so rarely done.

Smudge 10y ago
For a while I worked on and made use of a very lightweight JS framework that would essentially do two things: * Intercept link clicks and form submissions and perform the exact same request asynchronously (AJAX) * Wait for the server to respond with the parts of the page that need to be swapped-out (a JSON map of section IDs to plain HTML content) and, as expected, swap out those parts of the page. This works REALLY well for, like, 80% of my use cases. With a little extra flavor functionality (such as automatic loading indicators and event listeners) I can enable like 90% of interactivity. The remaining 10% consists of things that affect only temporary state and don't require a server round-trip (e.g. a "select all" checkbox), and those I would handle with more traditional jQuery DOM manipulation. For the most part, once I had this basic system in place, I could rely on the server to render (and re-render) all of the HTML and rarely had to write any custom Javascript. I was essentially relying on the behavior of vanilla links and forms. The site would even continue to function if you disabled Javascript, because the server would see that it wasn't AJAX and just render the whole page instead. The downside was that preserving local state (e.g. partially completed form fields) was tricky whenever I had to make a change to one of its parent containers. Everything I learned about this approach eventually led me to appreciate what React.js is doing. I've been using it and I may not like all of its API or how heavy it feels overall, but the cycle of rendering and re-rendering different parts of the page feels very natural and is far easier to debug than most JS-heavy front-ends.
- gkya 10y ago
  Why just don't let the hyperlinks do what they are supposed to do, which is what you do at the end of the day anyways, then? When I approach a link, I hover, see the href on the status bar, think and decide, and click. Thereafter, I expect it to take me somewhere else, while the browser pushes the url of the page I left into a stack, the history. This implemented and working in my browser already, why redo it with JS? To lower the load time? Then don't make the page multi-meg already, no? The ugly thing is govt websites and such are adopting a similar style of web app design, relying upon wizardy and tricks and hacks, for example, I sweat blood when I use my uni's web pages because I'll hit a bug in the js for an already-there popup or a button and it'll hurt my educational career.
  - TeMPOraL 10y ago
    The truth is, it's all because most websites are really ads, and they have to follow the fashion - otherwise you risk sending a message that your company or project is bad in some way. Web is a fashion-driven industry and any usability or ergonomics is not even a secondary consideration.
    - gkya 10y ago
      I made a website for my uncle's tile business. Real, international business with an office in the UK. I made it with ~180 lines of CSS, ~30 lines of JS ~20 lines of GNU (1) m4, and 60 lines of make. Got positive impressions from everybody he works with and probably improved our sales. External JS included, the WHOLE website source weighs in at 150 kb without images, with multiple pages, a gallery with a lightbox and on a proper grid (github.com/ThisIsDallas/simplegrid), a custom Google Maps map via the API, a carousel, and a consistent colour scheme, all done in an afternoon. And once compiled, the product weighs less than the source. I guess the problem is nowadays the designer folk gets to say too much on the development of websites and web standards. There is no prerequisite to become one. If you didn't study CS in depth, at the uni or by yourself, you can't do embedded, OS dev, etc., but mashing together some stuff from Github you become a web designer, no qualifications needed. Here we have a website that talks about bloat and lists nine or ten tools that have well established, better, more generic counterparts. Generating a file from another via a filter program (minifier, m4, awk, coffeescript compiler...) is what make excells at. Replacing strings is what m4, awk and sed do since 1980's. We don't expect from the designer folk to know anything about the basics of computing. And they spend their time duplicating and triplicating and quadruplicating effort spent decades ago to end up doing the same thing, only worse, and when it comes to actual work, all they do is mix and match some libraries and add bloat after bloat, instead of looking to see what needs to be done, and doing it, using the tools already available and fit. (1) Otherwise I'd have to implement a foreach macro, which would take some 10 lines more.
Nadya 10y ago
I agree with this entirely. The problem boils down to managers/designers hating default. As an example, take form behaviors. Default forms work. Built-in browser verification (for supported browsers) works. You can even have it match a regex! Built into the browser! Dropdowns in browsers? Those work too! So do radio buttons and checklists! Instead, people are tasked to reinvent the wheel and create their own hacky dropdown lists because they want things sorted into groups (what is an <optgroup>?) and they want super precision over how the list ends up getting styled. As a consumer: I absolutely hate this. I love browser defaults because I can expect all forms to just work. If I hit the letter "G" in a dropdown list I know how it will function! All of this knowledge is tossed to the side unless the reimplementation tries to remain faithful to the browser defaults. I know some developers are guilty of wanting to make custom things too - but by far it is a problem with clients and management. I always have to fight against anything that would change default browser behaviors because the UX on such things is terrible 99% of the time or whatever implementation via JS is going to either take a large amount of time or be buggy as hell.
- Keats 10y ago
  Some defaults are pretty damn ugly though, just missing or not consistent between browsers. For example the input type date or range to only name 2. The browsers errors on html5 validation are equally ugly imo.
  - Nadya 10y ago
    You can still style them differently! I was focusing on functionality. Your users are going to primarily be using a single browser (per device) and expect each device to be, at least, consistent with itself. This is an area I feel devs make the largest mistake: they want browsers to conform to one another. That means they'll break default functionality to get there! I'm of the opinion the browser should change. That allows users of the browser to adapt to the new default (because every site will then be consistent for the user!) Functionality can differ between browsers [0] and your IE users will expect the numeric input field to function like it does in IE. Not like it does in Chrome/FF/Safari. Meanwhile, your Chrome/FF/Safari people will expect it to function how it does by default in their browsers. You shouldn't override or change this functionality because it breaks user expectations. Overriding IE because it is the "odd one out" will break expectations for users using IE! It doesn't matter so much if the experience is different for each user so much as the experience is consistent for each user within their environment. [0] https://css-tricks.com/numeric-inputs-a-comparison-of-browser-defaults/ https://css-tricks.com/numeric-inputs-a-comparison-of-browse...

WA 10y ago

And there, I thought for a moment, my 38 KB CSS file is a mess and way too big. I guess, this puts it into perspective.

theandrewbailey 10y ago
My blog's CSS is 100k. Take out the three embedded base64 webfonts, and it's 6k.
- WA 10y ago
  Do you know a tool that turns Google webfonts into base64 for direct embedding?
  - theandrewbailey 10y ago
    https://www.fontsquirrel.com/tools/webfont-generator https://www.fontsquirrel.com/tools/webfont-generator Choose expert.
- davidwparker 10y ago
  My blog's 2.4kb. It's way too big (and my blog sucks on mobile). I've been rethinking about how I can redesign my blog to be as close to http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/ as possible.
  - Nadya 10y ago
    965 bytes for mine. I should (but didn't, will tonight) minify the CSS, which will bring it down to 650 bytes. My site is very much in line with BMFW and IMO it looks pretty nice. But it's also very, very basic. There are very few things that I would style for a text-based website: 1) The h1, h2, p, strong, and a elements. Font-family, font-size, color, a:hover, and line height attributes only. 2) Create a container (eg: max-width 44em, margin: 0-auto, width: 100%) to wrap everything in. From there the "heaviest" parts of the blog would be navigation and how accessible you want a complete archive list to be or if Previous/Next links would be suffice. E: 800px -> 44em, see response below.

evbogue 10y ago

http://gitmx.com/ev/reserva http://gitmx.com/ev/reserva is only 5.4k

dsego 10y ago
h1 { color: #333; } is only 20 bytes

colmvp 10y ago

Why do some of these sites have font families numbering in the double digits?!

KevanM 10y ago
Designers.
- paublyrne 10y ago
  Bad designers.
wmeredith 10y ago
Design by committee, legacy UI pattern support, browser support and accessibility fallbacks, excess frameworks, and do on... Designers on big projects share a lot of the same challenges with programmers. Edit: I'm not saying it's right. I'm saying I understand.

onion2k 10y ago

Unless data can demonstrate that reducing the number of classes or IDs on a page has a positive impact on things like returning DAUs, sign up conversions, etc, I'd argue these might be the wrong things to optimise. If adding another font to your site gets another 1% of users to buy something, you should add the font. Equally thought, if removing one gets 1% more sales, you should remove one. That's what counts, and it won't be the same for every site. Use data, not rules.

escape_goat 10y ago

Are you really sure you need to steer this conversation towards dispute? Because basically you're criticizing someone's experience of how they gracefully integrated ajax once upon a time. Like, in the past. I don't want people on HN to stop telling me what they did and how they handled situations, in the past, because they keep seeing that whenever someone like Smudge does that, someone like gkya really, really, urgently feel the need to tell them how they did it all wrong.

gkya 10y ago
> I don't want people on HN to stop telling me what they did ... because ... whenever ... Smudge does that, someone like gkya really, really, urgently feel the need to tell them how they did it all wrong. i.e. they discuss, on a discussion forum? > ... you're criticizing someone's experience of how they gracefully integrated ajax once upon a time. Like, in the past. Yes, what's the problem with that? He, as a developer, poses a way to do something, and I refute it as a person on the other side of the wire, i.e. the user/hacker. Where else than Hacker News is more apt for this sort of discussion?
- deleted 10y ago
  [deleted]
- escape_goat 10y ago
  My tone, previously, was not entirely useful, so firstly my apologies for that, I could have said the same thing in a less aggrieved way. As to your questions, well, I'd like you to consider my words in the context of the distinction between discussion, debate, and dispute. I believe I already adequately addressed what the "problem with that" was, but I'll reiterate it more clearly. Smudge was telling a story about a solution that he applied to a problem he was facing at one time, what the benefits and drawbacks of it were, and how it eventually led him to have respect for the value of React. He was sharing history. It was interesting. It would be interesting to discuss it if one had questions about the technical aspects of the thing he had done in the past, which he had shared with the audience in this forum, or rejected a similar solution at that time for reason one cared to describe. Smudge was not introducing or participating in a debate. He did not state a proposal. He did not invite a counter-proposal. He did not advocate anything. There is no debating that he did this thing. There is no debating that he did it for the reasons that he described. There is no debating that he came to the conclusions as a consequence of this experience that he shared with us. The statements that you have made seem to show a pattern of inattention to what is actually being said. You are not debating with anyone. Smudge did not intend to invite a debate, and he should not have had any reason to think differently. Instead, your behaviour is obnoxious, self-involved, and anti-social, because it would tend to discourage people who did not want to engage in debates with you from sharing history with the audience of the forum. What you were pursuing changed from debate to dispute. Firstly, rather than rebut points that had been made in the context in which they arose, you pursued disagreement beyond the bounds of the actual context of the matter under discussion. To give an example, whether or not "browsers are very smart these days" is not material to a discussion of how one developer implemented ajax updates with graceful degradation once upon a time when browsers were not very smart. You were not debating with Smudge, most basically because Smudge did not want or try to have a debate with you. You were not debating with Smudge because your statements were of little value in the context of what the topic of a debate would have been --- which would be something akin to 'decisions web developers made when faced with web developer problems [once upon a time]' --- and, by themselves, suggested that you were actually unfamiliar with this topic. Your words suggested a desire to turn a discussion into a dispute about a topic that Smudge was not discussing, and which was so tangentially related to the actual topic at hand that I would have found your need to dump your opinions upon this person as argumentation offensive even had you not stretched them to the ridiculous conclusion that front-end web development was a rent-seeking activity. To add the final part to what I had said before: behaving like this will discourage people from sharing their opinions and experiences. Just because someone said something, it does not mean that they or anyone else cares that you have opinions about a related topic or that that person is inviting you to criticize them. Wait until the lines of an actual debate have actually formed before you attempt to engage in a debate with someone, and never, never crash someone's thread in order to insist that they must debate you regarding a topic you yourself have brought to the table. Extending the reply to your last statements: firstly, no, Smudge did not propose a way to do something. You misread what he wrote. My apologies for the bewilderment that my response must cause you if you genuinely, rather than wilfully, misread what he wrote. However, he did not invite a debate, and your behaviour was not appropriate. If you thought that it was, it would serve you well to learn why it was not. Secondly, you did not 'refute' what he said. Your statements bore no relation to a refutation. "Everyone should use the latest web browser" is no more a solution to a problem than "Everyone should eat cake". Telling a person that they should use the 'default widgets' rather than write a very thin javascript library because you don't like too much javascript is confusing. What 'default widgets'? What do you mean by that... jQuery widgets? HTML does not come with 'default widgets'. Yes a lot of websites are clogged with useless shit, and yes you have a perfect right to not like this. But you can't 'refute' the decisions that a web developer makes "from the other side of the wire", and this is true of anything else or any other similar situation. You can't 'refute' a judicial decision on the basis of your own interpretation of written law. You have to learn about actual law first. You have to come to his side of the wire first. You could certainly refute mis-statement of fact, if you knew it to be incorrect, but you cannot refute a decision without understanding the context in which it was made.

andrethegiant 10y ago

I see many articles warning not to deeply nest selectors in sass. Doesn't gzipping your resources mitigate that problem?

digestives 10y ago
File size is a moot point with regards to long selectors - they are just a bad idea. [1][2] I am a fan of BEM to keep things sane. [3] [1] http://csswizardry.com/2012/05/keep-your-css-selectors-short/ http://csswizardry.com/2012/05/keep-your-css-selectors-short... [2] https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/ https://benfrain.com/css-performance-revisited-selectors-blo... [3] http://getbem.com/ http://getbem.com/
dsego 10y ago
Nesting selectors ties the css to your markup. These styles are not reusable components, but one-offs for that particular snippet of html. Look how bad it can get: https://github.com/edx/edx-platform/blob/master/lms/static/sass/course/courseware/_sidebar.scss https://github.com/edx/edx-platform/blob/master/lms/static/s... It's basically replicating the html nesting.

spankalee 10y ago

Shadow DOM and it's scoped styling is going to help this situation so much. Instead of large stylesheets with tons of highly-specific selectors, and quite a few broken and unused rules, web components will be able to use small stylesheets with simple selectors that only apply to their local scope, and developers will be able to reason about and maintain styles that are limited to a single web component.

oliv__ 10y ago

Ummm... Default or die: 15 tools? I thought I was just making a website here: you know HTML, CSS, and a dash of Javascript. ...Guess not.

partiallypro 10y ago

I dream of a day when you can have CSS loaded that has no dead weight. If one page doesn't have an accordion, there's no point in it loading the accordion CSS. Foundation slimmed down their base CSS files because it had so much dead weight from 5 to 6; but I wish there were some way (and I have seen some projects on GitHub) that I could load a page and it only would load the CSS needed for that page, but would still cache the common assets.

onion2k 10y ago
What problem would that solve?
- partiallypro 10y ago
  Your server serving up tons of code that is not being used at all?
  - onion2k 10y ago
    That would assume the user is only going to view one page. If they look at several pages then it'd be better to have sent all the CSS necessary in the first request and have their browser cache it. If you only send the styles necessary for the page they're looking at then you lose all the benefits of caching. That's a far bigger problem than sending a bunch of unused code.
CM30 10y ago
Isn't this basically using a default 'main' CSS file and a bunch of small extra ones loaded on a per page basis? You can do that pretty much simply with most CMSes out there, or through rudimentary scripting. Though being able to do that with a single CSS file would be nice to see...

rhubarbquid 10y ago

This site is pretty CPU heavy for something reminding us to respect our users' resources...

phillipwills 10y ago

This site crashes Firefox mobile after being open for a few minutes... Sad...

Washuu 10y ago
I was thinking maybe it was just you. I tabbed back to the web site, Firefox desktop immediately began to crash.

known 10y ago

Brilliant analysis and presentation; Thank you;

xufi 10y ago
Indeed it is. Brushing up on CSS here myself. Its amazing to see the different sites that use more CSS like Wikipedia.

nmbr213 10y ago

It's funny how they say CSS should be optimized, while they use 6 different JS files for particle animation (one for each site + header, the only difference being canvas size, particle count and color)

royquilor 10y ago

Hi everyone, Thanks for the feedback and it has been insane. 3 big sites have accepted the challenge to purge their css. Css is just a small part of the bigger picture. Lots more topics to discuss, but i just focus on CSS. I've dealt with a large site working with 4 developers. I have failed a adapting a big site to be lean on their CSS, hence looking at different ways of doing your styling.

cheshire137 10y ago

I think they could spare a few more characters to set their body background-color. I have a custom dark gray color set in my Firefox CSS so the new tab page doesn't flash white when I open it at night, and the site shows that dark gray, making their tables and text pretty hard to read.