Technology Deep-Dive: The CSS Edition

As Trey mentioned in Dusting off Open Source CU, we want Open Source CU to serve as a platform for discussing technology trends and sharing code in addition to more strategic discussions. We’re passionate about our craft and spend significant time and effort exploring the (near) future of web and mobile development. Over time we’ll present this research within the context of building high-quality member experience and show how these pieces fit together, but we also want to engage those who are building the next generation of banking.

In this post our focus is on some of the changes happening in the world of CSS. Here are some articles we found interesting:

• The End of Global CSS CSS React Webpack

  Organizing CSS becomes more difficult as the size of the user interface increases, and this seems like an interesting way to reduce the complexity, particularly when combined with React (we’ll be talking more about React in the future).

  Related links:

  • Block, Element, Modifying Your JavaScript Components
  • PostCSS Local Scope
  • CSS Loader: Local Scope

• Solved by Flexbox CSS Flexbox

  Layout in CSS is painful but important, particularly to support multiple screen sizes. We’ve used grid systems like those provided by Bootstrap and Neat (in addition to some custom solutions), but they’re still constrained by the limitations of CSS and require significant amounts of work. Flexbox is the solution to this problem and it’s becoming more widely available (including its use in React Native). We’re not able to use it in production yet (thanks, IE), but we’re able to use it in prototypes and look forward to the day when controlling layout via CSS is straightforward.

  This site shows how to solve common layout challenges using Flexbox.

  Related links:

  • React: CSS in JS
  • Flexbox in 5 minutes

• PostCSS CSS Build Tools

  Layout isn’t the only issue with CSS. It’s not the most elegant of languages and browser vendors often outpace the standards development process (which is a good thing). These rough edges are often handled by preprocesors such as Sass, Stylus, and Less. PostCSS fills the same need but does so by, as the name implies, post-processing the CSS. The big win here is speed, flexibility, and easier extension via a vibrant plugin ecosystem. I’m particularly interested in it because the processing is done via JavaScript, which means that I can use familiar tools and can include the PostCSS processor without having to use another language stack (my previous favorite, Sass, requires a compiler written in either Ruby or C++).

  The most popular PostCSS plugin is Autoprefixer, and if you’re going to use newer CSS then it’s a huge time-saver. From the “Solved by Flexbox” site referenced above:

  If you’re writing Flexbox code and not using autoprefixer, well, you’re making a horrible mistake.

  Last night was the first time I used it, but so far I’m impressed.

  Related articles you may find interesting:

  • Breaking up with Sass: it’s not you, it’s me
  • PostCSS: the Future after Sass and Less
  • I’m Excited About PostCSS (But I’m Scared to Leave Sass)

This week we also released a small module for using RAML-based API specifications in JavaScript projects: https://github.com/opensourcecu/raml-loader. We’re using it to build tools for documenting and exploring APIs and will talk more about those tools when they’re ready (you can follow the progress at https://github.com/opensourcecu/react-raml if you’d like). We’ll also be using those tools to facilitate future API discussions and explorations on Open Source CU.