Hacker News new | ask | show | jobs
by jasonpriestley 4345 days ago
Writing your styles in javascript is a better option. You get variables, as well as functions and modules (e.g. with browserify), all with sane syntax and semantics (no "cascade").

Preprocessors are an inferior solution, limited by the semantics of CSS and leading, by the pervasive use of macros, to needlessly large CSS file sizes.

3 comments

What's the best solution for writing styles exclusively in JS and avoiding CSS completely?
My practice is to build the DOM programmatically with jQuery, and add styles to the elements directly

   $("<div>")
     .css({width: 100, height: 20, color: 'red'})
     .appendTo(container);
Then, since these are just values in normal javascript code, you can refactor as normal. Pull commonly used patterns out into functions (e.g. `importantText(16, "size 16 important text goes here")`).

Most styles in the applications I write tend to be inextricably linked to the layout and function of a component (e.g., tabs should be next to each other); in the rare case that a style needs to be customized in different locations or at different times, it becomes a parameter (e.g. `confirmDialog(textStyle, message, onOk, onCancel)`)

No extra tools are needed, beyond jQuery (building up the DOM without jQuery or something like it is awful).

I've made this argument before, using JS exclusively for styling does not let you avoid CSS. It lets you avoid certain aspects of CSS that may, or may not, be helpful.
And does your styling work in a webbrowser where JS is disabled?
Not trolling, I really don't understand: why would you disable JS when browsing the web?
Not wanting to execute arbitrary untrusted code on your machine? While there has been lots of good work put into sandboxing browser by the browser vendors, the ability for attackers to run custom code within the browser makes many exploitable vulnerabilities a lot easier to exploit. Things like the various privacy leaks based on cache timing, visited link styles, and so on, or just exploiting buffer overruns that have been protected against by address space layout randomization but with arbitrary code the exploit can try the same thing over and over again with different size inputs until it finds one that works.

Running JavaScript in your browser automatically from any site that you visit is pretty darn scary when you think about it. You can protect from a whole host of vulnerabilities by disabling it, and then whitelisting only hosts which you trust.

Viewing some overly crufty sites can benefit from having JS completely off rather than "simply" using an ad-blocker. I'd wager that some tinfoilhats still run with JS off, or at least NoScript almost everything.