Pug vs Sass: What are the differences?
Pug and Sass are primarily classified as "Templating Languages & Extensions" and "CSS Pre-processors / Extensions" tools respectively.
"Elegant html", "Great with nodejs" and "Open source" are the key factors why developers consider Pug; whereas "Variables", "Mixins" and "Nested rules" are the primary reasons why Sass is favored.
Pug and Sass are both open source tools. It seems that Pug with 18.3K GitHub stars and 1.9K forks on GitHub has more adoption than Sass with 12K GitHub stars and 1.93K GitHub forks.
StackShare, HubSpot, and thoughtbot are some of the popular companies that use Sass, whereas Pug is used by Sellsuki, triGo GmbH, and Key Location. Sass has a broader approval, being mentioned in 2082 company stacks & 1445 developers stacks; compared to Pug, which is listed in 173 company stacks and 118 developer stacks.
What is Pug?
What is Sass?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Pug?
What are the cons of using Sass?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
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.
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
For markup and style, I used Pug and Sass, since they’re the perfect match to me. I love the clean and strict syntax of both of them and even more that their structure is almost similar. Also, both of them come with an expanded functionality such as mixins, loops and so on related to their “siblings” (HTML and CSS). Both of them require nesting and prevent untidy code, which can be a huge advantage when working in teams. I used JSON to store data (since the data quantity on my website is moderate) – JSON works also good in combo with Pug, using for loops, based on the JSON Objects for example.
To send my contact form I used PHP, since sending emails using PHP is still relatively convenient, simple and easy done.
DevOps: Of course, I used Git to do my version management (which I even do in smaller projects like my website just have an additional backup of my code). On top of that I used GitHub since it now supports private repository for free accounts (which I am using for my own). I use Babel to use ES6 functionality such as arrow functions and so on, and still don’t losing cross browser compatibility.
Side note: I used npm for package management. 🎉
It was a little awkward building BS3 with LESS, and the rest of the site with SCSS, but it works. SCSS made building the UI elements (ink/flip buttons, img navs, etc) a breeze. It also drives the mobile menu open/close transitions - that would have been much too much with vanilla css.
Sass helps us write better stylesheets. One major improvement over CSS that we use a lot is variables - it allows for much easier theming to quickly change brand colors for new instances of the xCoLab.
When you realise that countless lines of CSS codes could be made countable. And off course, a wonderful and cool way to use the logic behind variables and nesting. Simply love it.
We use Jade when writing HTML, which is much easier to read and maintain. We compile it to HTML before deploying it though, and don't use Jade's client-side rendering features.
Sass is used as a part of Woltlab Suite Core, which offers to submit/configure own styles via the injection of own Sass-CSS. So we exclusively rely on Sass for our CSS needs.
CSS is a mess. There, we said it. Sass, on the other hand takes CSS and makes it pretty, easy to work with and has stuff like variables which make things seriously awesome.
We use Jade for constructing our modular UI. We also rely on Jade interpolation to pass reactive and static values from our Express server.
front-end 수업 때 들은 jade 입니다. html을 효과적으로 다룰 수 있고로 열고 닫을때 혼돈이 없어 좋아합니다. 현재 프로젝트에 gulp와 함께 붙이려는 계획을 갖고 있지만, 아직 연습이 더 필요하다고 생각됩니다.