Hacker News Reader

Comment by apphacker | Hacker News Reader

I don't think using JavaScript to fix something CSS can't do is the proper solution. I think to draw a static width box around the variable width items or just not worrying about the flush on both sides (something you can accomplish with CSS if you're willing to use an extra container to wrap all items except the last.)

But styling via JavaScript because you couldn't do it in CSS? Yech. Especially if it's not some kind of UI component that needs JavaScript interaction like an accordion or drag handle or something.

View on HN

Maybe I spent too long around TeX and Postscript, but it seems perfectly natural to me that when a layout can't be described in a declarative language like CSS, you would turn to a computational language instead.

Fixing layout in javascript has negative performance implications. Either you embed the js in the html, in which case every page is larger than necessary, or you put it in a separate file, in which case your layout can't be rendered correctly until another file is loaded.

I'm not sure what the author's point was exactly. There are tons of things that are easier to do with "classic" html or just plain hard to do with css alone. Even though we've been hearing ever since its invention that css is incredible, I'm still not convinced. It's certainly useful, but in so many ways limiting and annoying.

> Either you embed the js in the html, in which case every page is larger than necessary, or you put it in a separate file

Which is different from CSS how exactly?

Text is small and most sane server configs are gziping it on top of that. We're literally talking about 500 bytes.

Well, you can't reasonably avoid external CSS, but you can reasonably avoid external JS. I still have tons of pages without external Javascript. I'm fairly sure I don't have a single one without external CSS.

As for gzipping etc. it's the not the actual size that matters it's the latency + the fact that it's a new connection. TCP/IP connection takes a while and then (for larger files) you have to deal with slow start. This wouldn't be a huge deal if everyone supported pipelining, but they don't.

A significant number of people have modern browsers but browse with JS disabled (eg NoScript). If your layout relies on JS, you may be making your site inaccessible to them.

I keep reading this, but I'm yet to see any stats - and the stats from my site don't support this at all.

Can you cite?

There's not a whole lot to cite, estimates are fairly rough since many analytics programs are javascript based. I can point you to the Firefox "Popular Extensions" section (https://addons.mozilla.org/en-US/firefox/browse/type:1/cat:a...) NoScript is #5 at 354,158 weekly downloads, and the NoScript page itself which claims 65,864,095 total downloads (https://addons.mozilla.org/en-US/firefox/addon/722). Then there are the corporate offices where javascript is disable by IT, or even worse, I've heard of cases where a business uses a proxy service that switches out .js files with empty files, which not only gets rid of the JS, but it also means that noscript tags aren't visible since JS is still enabled.

Whether that's significant or not is a matter of opinion. Most estimates I've seen are 3-6%, but should be taken with a big grain of salt. For sites I've worked on I tend to see about 2-4% of users using Google Chrome as their browser, for comparison.

I realize this doesn't help much.

Thanks, no - it does help, I hadn't thought to check NoScript's download stats.

I was aware that most web stats packages use javascript to report stats - when we did the exercise of checking for disabled JS, that's where we looked.

Reply on news.ycombinator.com