Let's build coolest web components purely in CSS, NO JavaScript
technical.nailfashionsweden.se
technical.nailfashionsweden.se
I would love to hear from anyone who actually uses this kind of code for large web application.
Maybe the typical CSS knowledge is way, way too low considering CSS itself is really not complicated and that it'd actually be a good thing that your developers actually know the language they're using, no ? You wouldn't hire a C++ guy telling you he only knows the C-compatible parts of the language, would you?
But then that's a very specific requirement, which pretty much requires you to use only the C features. Embedded development is probably 5% of the entire C++ jobs. Should the 95 other percent ignore C++'s features because the other 5% do ?
First of all, embedded probably constitutes more than 5% of all C++ jobs. Second, embedded is not the only area where C++ is essentially written like C. It might be changing no, but for decades, that's how most C++ was written.
In games, for example, it's common to see the only C++-specific features used being operator overloading for vectors and matrices and maybe a couple templates.
In highly-regulated safety-critical domains, the language is restricted by style guides that essentially limit the available features to a subset of C.
And beyond that, writing C++ as just "C with some extra features I want" is a popular style. GCC, for example, uses only destructors and templates, and is otherwise just C.
It's not a bad thing. It's not clear that C++ is an improvement over C in terms of ease of use or maintainability. Projects written in C++ tend to develop complexity faster than those written in C.
Well, to be fair, that's because the GCC codebase was written in C and later switched to bootstrap in "C++ mode". Introducing C++ features in to an existing production-ready, 30 year old, C codebase is not going to happen quickly. Both Clang and LLVM, on the other hand, use C++ features pretty readily.
> It's not clear that C++ is an improvement over C in terms of ease of use or maintainability. Projects written in C++ tend to develop complexity faster than those written in C.
Complex projects can grow complex because they're... well, inherently complex. So maybe inherently large, complex projects just require the power of C++?
We both clearly have a personal bias one way or the other. Personally, I despise C. As well as a lot of the things I like, pretty much everything I hate about C++ comes from C (header files, implicit integer narrowing, and undefined behaviour wrt signed types, for example.). Cs lack of power and expressiveness has also lead to pervasively poor, lazy API design (libc and most of the POSIX APIs, for instance, are total garbage).
But you KNOW those features. You know that you shouldn't use overloading because of perf reason A, or that templates are bad for reason B (in the case of your project). However, if you saw those two features in code, you'd know how to interpret it, how they work, etc. The typical C++ knowledge is not just C.
The OP to which I replied to implied that counter() (or any of the other features that are part of the standard) isn't typical CSS knowledge. Well then the typical CSS knowledge is terrible and should be fixed, because they're not exactly obscure functions, and CSS isn't exactly a huge monstrosity like C++ is.
I think that web developers should spend less time playing the latest JavaScript framework, and more time getting to know XQuery selectors.
But I realize that this sounds like an "Old man yells at clouds" argument.
But usually, browser compatibility is the biggest reason stuff like this isn't so common in production environments. A lot of large companies use outdated browsers that don't support much in the way of modern CSS or HTML 5 stuff, and they don't usually like being told that their CSS only tab system or progress bar doesn't work in their browser cause they're using IE8 or something else that's equally outdated.
But I have used this sort of stuff before on real websites and applications.
The web is better without JavaScript. I can't wait until it is looked down upon as hamfisted and passé, as Flash is now.
Also, you didn't address any of OP's points about the separation of styling and function.
However I do believe JS will lose most of its popularity when web technology gets even faster. The slight performance boosts that JS gives you now - which is the predominant reason it's become so popular - won't matter as much; if things are so fast that you don't need an ajax architecture, you won't need front end JS frameworks.
I worry about implementing such techniques in production because JavaScript options in legacy browsers are clear, where nuances in CSS between browsers can be fuzzy and polyfilling CSS3 selectors is not reliable.
Better the devil you know.
For example, to toggle a button is really similar to set a rule like $("button.cta").on("click", fn); vs $("input.cta").on("change", fn);
http://www.cssdesignawards.com/articles/best-pure-css-pens-o...
Without JavaScript these cannot be web components, as there is no declarative standard for custom elements yet. You need JavaScript to at least call document.registerElement, and usually to create and populate a shadow root.