Changes to the way we develop CSS and JS

[tunetheweb]

@HTTPArchive/developers as you can see I have lots of questions today!

First a bit of background:

At the moment, we lovingly handcraft our CSS and JavaScript from raw bits and bytes.

We don't use any large libraries and frameworks and I think that's the right decision given the fact we are basically a static site (see #1222) with few pages or complex components (though that might be changing - see #985 , #986 and particularly #1052 ).

We've worked hard to make our site progressively enhanced – it should work on even the most basic browser, but be a better experience for more capable browsers. To do that we add appropriate fallbacks to our CSS, and ensure our JavaScript doesn't use any new ES6 (or even ES5!) syntax that might trip up older browsers.

At the same time we, haven't had to add a lot of vendor prefixes in our CSS (hurray for quickly evolving browsers!) and similarly we don't usually polyfill JavaScript functions. This is to avoid code bloat for a small subset of users, and instead we rely on the site still rendering reasonably well but with less features. The content is after all the most important part of our site and not some fancy scrolling table of contents or menu animations which truly are progressive enhancements.

Note: the exceptions to this is that I did add IE 11 grid support in #786 (because it was annoying me when I tested on IE11 and because it was relatively simple) and still have px fallbacks for rem sizes (mostly because I still find it hard to think in rems - but think I'm about ready to remove this now).

So, in summary, it's important to us, that we continue to support a functional basic version of the site for old browsers, but also demonstrate the power of more modern CSS and JS APIs.

And now for the questions:

Should we change our way of developing CSS and/or JavaScript? Are we missing a trick by handcrafting this?

I still vote against large libraries - but willing to hear the arguments for them if people want to make them?

Should we make more use of Transpilers (like Babel) to ensure backwards compatibility, or transcompilers (like TypeScript) to ensure more robust code? Or are they overkill for us?

Should we consider CSS pre/post processors like SASS or PostCSS

Any other suggestions?

[sudheendrachari]

With my limited understanding of the codebase, here are my thoughts..

Should we make more use of Transpilers (like Babel) to ensure backwards compatibility, or transcompilers (like TypeScript) to ensure more robust code? Or are they overkill for us?

IMO Typescript would be an overkill, since the amount of dependency on JS for the core functionality of the website is less and thus JS footprint itself isn't too huge to leverage the advantages we get over moving to Typescript

That said, I would still love to see better organisation of our JS code, a file like chapter.js is ~400 LOC, and it would be be great if we can split this into smaller and more manageable chunks of code which are held in separate files. And then we can possibly use a bundler (like rollup or parcel; tooling.report might help us pick bundler which works for our use-case) with very simple configuration to bundle them together into same output that we ship today

So the intent is to keep the code more modular and maintainable, while still keeping the output bundle exactly same as it is today

I still vote against large libraries

+1

Should we consider CSS pre/post processors like SASS or PostCSS

I would vote to consider using a preprocessor like SCSS or SASS mostly for the following reasons:

• Better code organisation

1. With capability to use nested selectors, it would make things easier to logically group all related styles together in one place
2. We've one huge file 2019.css which is roughly 1300 lines, which would ideally be split into smaller chunks. Typography into one, navigation (header and footer) into one, main content in another etc, etc..

• Use of variables and mixins: We do have some theme colors like yellow(#f7f779), dark blue (#1a2b49) etc., which are used across the site and currently we have to repeat the values everywhere. If this were picked from SCSS variable it would be more readable and makes it easy to spot any incorrect usage of theme colors in the review stage itself. Same argument holds for mixins as well, any repetitive styles can be moved into mixin and they can be reused anywhere (DRY). Eg: Primary button styles, dark blue background with white text, and rounded corners
• IIRC SASS provides minifying capability out of the box when it compiles to css, which will be an added advantage

The intent here is also the same, to keep code more modular and maintainable, while still keeping eventual css output file that we ship the exact same as it is today

[MSakamaki]

Should we consider CSS pre/post processors like SASS or PostCSS

I fully agree with @sudheendrachari on the use of scss/sass.

Should we make more use of Transpilers (like Babel) to ensure backwards compatibility, or transcompilers (like TypeScript) to ensure more robust code? Or are they overkill for us?

If going to benefit from Babel (TypeScript) then it might make sense to create a separate repository and, I thinkprovide WebComponent via CDN.

[tunetheweb]

JavaScript:

I think the general consensus (that I agree with) is that Babel and/or Typescript may be be overkill but there's potentially some gains in refactoring our JavaScript code: perhaps to break up our chapter.js file (at least in source, even if the built file ends up being the same).

I also think the "Language and Year switching" function, which is currently inlined in to every page, should potentially be pulled out to a separate JS file as would prefer to keep inlined JS for super critical JS code whereas this isn't needed for first paint.

CSS

Seems like a lot of support for better structuring our CSS code, potentially with SCSS/SASS. Any takers on this one?

[tunetheweb]

Closing this for now as what he have seems to be working and doesn't seem a huge appetite for taking on move from CSS to SCSS/SASS at the moment.