Oliver Kühn JSS is... well... hmm. My reaction to it is a mixed bag. Mostly negative, but I could see some corner cases where it MIGHT be acceptable.
As a rule of thumb, it violates the separation of concerns that should be the cornerstone of building websites properly. The biggest drawback being that much like manipulating Element.style -- something I've always tried to avoid when possible (but isn't always possible to avoid) -- it is quite difficult in document inspectors to go "hey, where the f* is this STYLE tag coming from?". This is only further exacerbated by "JSS Isolation" which is one of those attempts to automate fixing a problem that wouldn't exist if people understood and used selectors properly... and STOPPED mindlessly throwing wrapping DIV and dozens of classes at everything willy-nilly.
I also really dislike the concept since it means adding STYLE tags to the markup, a tag that really should have been deprecated as soon as it was introduced. I've always written my HTML and CSS on the principle that if you need a STYLE tag you're screwing the pooch. Same as how if you stylesheet LINK without a media="" you probably aren't ready to be using CSS yet.
BUT, most of the problem with the STYLE tag doesn't exist in JSS -- that problem being the failed caching attempt. For all the talk about putting static style unique to one page into the markup to 'speed up rendering' simple fact is that RENDER is rarely a bloody bottleneck on a properly written page. BANDWIDTH IS! If you're already going to have an external stylesheet placing everything into a single monolithic sheet is just ONE handshake, and means style can be cached across pages and pre-cached for ALL pages. Pre-caching/read-ahead typically paying more benefits once things like gzip compression are in the mix than any alleged render time savings.
Though to be fair I come at that from the point of view of one who typically uses half to a fifth the HTML and at MAXIMUM 48k of CSS per media="" target for an entire site -- because for the majority of websites if you bother meeting accessibility norms THAT'S ALL YOU NEED!
Which is why when I see dozens of separate stylesheets being loaded (not counting social plugins), half a megabyte or more of CSS, 48 to 256k of markup being used to do 8 to 32k's job, megabytes of scripting on websites that don't even warrant the PRESENCE of JavaScript, and LINK tags without media="" or set to media="all" I automatically assume I am looking at either developer ignorance, or outright willful incompetence.
But with JSS, JavaScript in an external file is cached separate from the markup, so that concern goes away. The lack of specifying media targets being the only major niggle... one that is more an issue of implementation than it is one of
That implementation issue though reeks of the real problem, the people who would use such a thing failing to grasp the core concept of why HTML and CSS are separate, and how realistically unless you're doing something like animations (which would be mind-numbingly dumbass to do using JSS anyways) your scripting has about as little business controlling style and layout as your markup does.
The whole point of CSS is to allow different appearances off of one core markup -- allowing HTML to return to its roots of semantics and pitching all the HTML 3.2 idiocy (center, font, align, border, color, bgcolor, alink, vlink, etc, etc) that NEVER should have existed in the first place in the trash where it belonged! As the saying goes:
If you choose any of your HTML tags based on their default appearance, you are choosing all the wrong markup for all the wrong reasons!
In that same way unless you are directly controlling positioning, size, opacity, and the like for animations, using Element.style means you're doing it ALL WRONG! Has NO business in your JavaScript in the first bloody place -- and since JSS is completely unsuited to those situations I can only conclude it too was created by people who probably failed to grasp why CSS even exists.
Again as evidenced by how most of them don't grasp why the media="" attribute exists, and could give a flying purple fish about anything more than perfectly sighted screen media users... Flipping the bird at anyone who doesn't meet that perfect match of "scripting + screen" defeating the ENTIRE point of using HTML as the base we build off of!
But that just plays to the current mentality of "hurr durz, I cans has teh intarwebs" development where scripting this and scripting that and scripting some other damned thing, and to hell with accessibility and usability.
I don't play that game, and I'm not kind to those who do.
Jason Knight
The less code you use, the less there is to break
NO! ... because I do not recommend front-end frameworks. EVER
They are bloated trash that make you work harder, not smarter. They flip the bird at accessibility, usability, and sane/rational development; more often than not resulting in non-semantic markup, two to ten times the markup you should be using, and basically telling the entire reason HTML even exists and why CSS is separate from it to go bend over and run jack-a-willy wally-sucker over itself.
They are universally incompetently built rubbish that just gets in the way of learning to use HTML, CSS, and JavaScript properly. You start out with two to three times the code your entire project should have, to write two to ten times the markup you should need, to have a result that tells users with accessibility needs to sod off and is a pure nightmare to maintain - all whilst making it harder to do even the simplest of tasks said 'framework' wasn't designed to do.
THEN thanks to propaganda and mindless parroting of catchphrases from people who don't know any better, this manure is spoon fed to the masses like it was chocolate ice-cream, with wild unfounded nonsensical claims of it somehow being magically "Simpler" or "easier" or "makes you more productive".
When the truth is, if you find any of the positive claims about 'front end frameworks' to be true, you simply don't know enough about HTML, CSS, or JavaScript to be flapping your gums on the topic.
There's a reason I say the only thing you can learn from bootstrap is how NOT to write HTML or CSS -- and usually refer to it as bootcrap; since your best bet is to go find a stick to scrape it off with before you go tracking it all over the Internet's carpets.
As to be brutally frank, if you don't know what's wrong with OUTRIGHT INEPT HTML like this:
<body> <div class="d-flex flex-column flex-md-row align-items-center p-3 px-md-4 mb-3 bg-white border-bottom box-shadow"> <h5 class="my-0 mr-md-auto font-weight-normal">Company name</h5> <nav class="my-2 my-md-0 mr-md-3"> <a class="p-2 text-dark" href="#">Features</a>Do the world a favor, back the {expletive omitted} away from the keyboard, and go take up something a bit less detail oriented like macramé.
... and compared to some other train wrecks of ineptitude like W3.css, bootcrap is a shining gem. Web development as a whole is dumber for this idiocy even existing!
I've NEVER seen one that was worth a flying purple fish, or even approached proper competent use of HTML and CSS. They are a LIE! A Scam. Flim-flam. Bunko. 100% grade A farm fresh prairie pies! Biff Tannen's '48 Ford Super De-Luxe was less full of it!!!