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 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'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'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.
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).