What is PostCSS?
Who uses PostCSS?
Here are some stack decisions, common use cases and reviews by companies and developers who chose PostCSS in their tech stack.
Simple controls over complex technologies, as we put it, wouldn't be possible without neat UIs for our user areas including start page, dashboard, settings, and docs.
Initially, there was Django. Back in 2011, considering our Python-centric approach, that was the best choice. Later, we realized we needed to iterate on our website more quickly. And this led us to detaching Django from our front end. That was when we decided to build an SPA.
For building user interfaces, we're currently using React as it provided the fastest rendering back when we were building our toolkit. It’s worth mentioning Uploadcare is not a front-end-focused SPA: we aren’t running at high levels of complexity. If it were, we’d go with Ember.js.
However, there's a chance we will shift to the faster Preact, with its motto of using as little code as possible, and because it makes more use of browser APIs. One of our future tasks for our front end is to configure our Webpack bundler to split up the code for different site sections. For styles, we use PostCSS along with its plugins such as cssnano which minifies all the code.
All that allows us to provide a great user experience and quickly implement changes where they are needed with as little code as possible.
ReactQL is written in TypeScript to provide full types/Intellisense, and pick up hard-to-diagnose goofs that might later show up at runtime. React makes heavy use of Webpack 4 to handle transforming your code to an optimised client-side bundle, and in throws back just enough code needed for the initial render, while seamlessly handling
import statements asynchronously as needed, making the payload your user downloads ultimately much smaller than trying to do it by hand.
React Helmet was chosen to handle
<head> content, because it works universally, making it easy to throw back the correct
<title> and other tags on the initial render, as well as inject new tags for subsequent client-side views.
<style> tags when using #StyledComponents.
React Router handles routing, because it works both on the server and in the client. ReactQL customises it further by capturing non-200 responses on the server, redirecting or throwing back custom 404 pages as needed.
Koa is the web server that handles all incoming HTTP requests, because it's fast (TTFB < 5ms, even after fully rendering React), and its natively #async, making it easy to async/await inside routes and middleware.
Originally, I was going to start using Sass with Parcel, but then I learned about Stylus, which looked interesting because it can get the property values of something directly instead of through variables, and PostCSS, which looked interesting because you can customize your Pre/Post-processing. Which tool would you recommend?
We use Sass because I invented it! No, that's not a joke at all! Well, let me explain. So, we used Sass before I started at Rent the Runway because it's the de-facto industry standard for pre-compiled and pre-processed CSS. We do also use PostCSS for stuff like vendor prefixing and various transformations, but Sass (specifically SCSS) is the main developer-focused language for describing our styling. Some internal apps use styled-components and @Aphrodite, but our main website is allllll Sassy. Oh, but the non-joking part is the inventing part. /shrug
We in our #Frontend team prefer to use the modern and clean syntax of #CSS instead of Sass or Less. On bundle step, we use post-processing by PostCSS to add prefixes, minify code, uploading assets and more. PostCSS get CSS more powerful, it‘s a fantastic tool.
PostCSS essentially allows you to set up your own CSS preprocessor with the features that matter to you. It has a modular plugin-based architecture, which means that if someone comes up with a useful new feature, you can easily add it to your stack as a PostCSS plugin. PreCSS and PostCSS-cssnext are some of my go-to plugins. PostCSS