It does depend what perspective you're looking at it from. I appreciate it generates awareness about a current state of affairs for newcomers. But it's always easier to complain about something that to grind your teeth on it and learn, research and develop. The latter, although more painful, is a driving force forward.
I'm fairly close to finishing the conversion of my `dev-toolkit` into an npm-module. It is almost no-config, has scss, server-side-rendering, hot-reload and more. I'm a one man band but will get there. It's all on https://github.com/stoikerty/universal-dev-toolkit
The npm-version sits in a feature branch, just look for the corresponding PR if you're keen.
I have a release ready. Just pinned it at 5.0.3
It is similar to `create-react-app` but also has CSS-Modules (with SCSS) and a few other features like Browsersync and root-relative imports.
I've been following their repo for a while, hopefully by next year they'll be far along for it to be usable.
Ghost has an excellent editor and it would be awesome to have a static site built in any way you like that links straight to your blog posts via API calls.
I agree, nesting has been one of the most helpful parts in SASS to keep everything organised. Nestin is just harder to do right, you need some experience in organising files.
Even with the specifity I vastly prefer nesting to a bunch of files with flat selectors and a huge amount of globals where you need a lot of time just to understand which elements affect which.
The post is quite opinionated and puts every issue in a bucket, as if there is only one way to write CSS. A few examples would have been useful.
Not using Nesting is the worst offender in the list.
The trouble is that untangling nested selectors can be a real challenge, especially if you have inheritance between them, and the implications can be chronic. On a project I was working on recently, a colleague reported to the team that the addition of one line of code to a SCSS file resulted in an increase in size of the target CSS by 800KB. Looking at the spaghetti code that had been written, none of us could work out how many rules were being combined out of the deceptively clean looking SCSS.
A recommendation for that project was to lint for some ground rules forbidding certain behaviours, nesting being one of them. I've actually been considering avoiding SASS altogether in the future.
Yes they can.
If you are interested here is how the rendering works.
The rendering happens in batches, the first render is always an expensive operation and includes both "paint" & "layout".
- The "layout"-operation recalculates the tree of visible elements.
- The "paint"-operation paints the element and is commonly done using a software rasterizer.
Every subsequent render happens if an DOM-element triggers a layout or a paint (or both). A re-paint occurs when changes are made to an elements skin that changes visibility, but do not affect its layout. Examples of this include outline, visibility, or background color.
When you use GPU-accelerated CSS properties such as opacity, translate, rotate & scale, both layout- and paint-operations are not executed. The GPU handles the changes for those properties. This is how famo.us wants to achieve its "60fps".
React by itself can cause expensive operations too if you trigger a CSS property that is not GPU-accelerated. In the process of rendering, a DOM-element can be destroyed and recreated when your state or model changes. So be vary of third-party React-components that promise "fluid" or "fast" speeds. IMO animation is still a research-topic for React. Their manual currently lists a method for basic CSS animations and transitions, but it's projects like React Canvas that make React a worthwhile contender for performant animations.
Mobile browsers are no different to Desktop browsers, almost every smartphone has a GPU of some sort. So you have 2 main-bottlenecks with every device. The first is the CPU (& RAM), the next one is the GPU (& the GPU-RAM).
