I have also found that CSS becomes a lot more tolerable with CSS Modules, in combination with React, which allows you to write CSS that targets one component and only that component. By eschewing cascading, you can finally write modular, reusable CSS that avoids side effects and still allows fine-tuning (overriding) by the component user.
There should be something in the license of JavaScript frameworks & libraries to prevent them from being used in blogs, newspapers, trade publications etc :-/
For now all innovations in JS just seems to provide us with even heavier web sites for no real benefits. I feel I'm starting to dislike JS the way I disliked Flash which would be quite a feat.
Of course, nobody does this in practice.
(Oh, BTW, JavaZone 2016 was Oracle-free and all talks seems to have been uploaded to vimeo with no restrictions on downloading.)
I made this comment in another thread, but it fits right into this one too.
Like, most game dev frameworks (especially for mobile) leave you with device-level looping, under language-level looping, under framework-level looping, under code-level looping. This, obviously, is hell.
The result is that something as simple as "play this sound file, looping when finished" ranges from awkward to literally impossible. Memory access, garbage collection, and framework timing all collide and leave you with mysterious multi-second gaps while everything tries to sync up. And so everyone building something serious has to dive down past LibGDX into awful, ground-level things like Hammer or un-frameworked C++/Java/etc.
I'm not sure what the cure is - unlike a AAA game, there's room for a tiny bit of inefficiency in a webpage. 0.1-0.5 second loads are reasonable, instead of 0.01 second frame renders. But right now the endless layers are spitting out far too many 10 second load times, and no one even seems to notice the redundancy.
> teetering Jenga tower of hacks?
How is any programming language not capable of being brittle?
I've been programming since before the web was invented. The web, as a development platform, is the worst layer-cake of kludges I've ever seen.
Unlike many other web programming approaches -- this stack should help avoid the need to invent new hacks for every new feature or slightly different situation ...
A big design mistake was the global cascading/inheritance system. It's a huge pain to write CSS that doesn't leak into nooks and crannies where it shouldn't. CSS is supposed to be modular, but you can't just import someone's stylesheet (e.g. for embedding something in your page, like a video player) and trust that it won't override everything around you, intentionally or accidentally.
More than that, CSS was designed for "styling documents" — the idea being that you could display the same document with different stylesheets, sort of like themes, and so the stylesheet obviously had to be separate from the document. But almost nobody who uses CSS these days do it to "style" anything, let alone "documents". One particularly egregious issue coming from this design is the attempt to separate layout from content, when in truth layout is content, and for pretty much any application today, the style is also content. We're well beyond the point where an HTML document can be "semantic".
Shadow DOM may be the way forward in the future, but CSS Modules is a nice stopgap solution, at least, and you can use them with React + PostCSS (+ SASS) + Webpack in a nicely seamless way, without requiring any browser support.
Proper abstractions are supposed to compress large bundles of information into a smaller set of [broad] concepts, which then imply all the large sets of details they're abstracting away. High level languages are pretty good abstractions on top of raw assembly code for example, because you don't have to think about what the assembly for your java code is going to look like, it's already implied that it's going to work.
As for react, I'm also not a huge fan, but that's because it's still a relatively leaky abstraction that comes with a lot of the same baggage as plain js+html+css. Especially when compared to a fuller abstraction like Elm[0]. But even that's still lacking a complete abstraction of html/css stuff. And that's not even taking the leaky abstractions on the backend side of the equation into account:
http://haskell-web.blogspot.com/2014/04/towards-deeper-integ...
Ref: https://medium.com/javascript-scene/what-is-webassembly-the-...
* DOM,
* HTML Layout,
* CSS,
* A small variety of crappy events ( onDomLoaded ),
* a fairly rubbish heavyweight communication layer ( AJAX )
* Keyboard bindings that never work cross app, never cross platform
* Accessibility ??
* No idea of the energy impact of your code
* No ability to do queries on important device metrics ( energy consumption, clipboard, user presence, login / logoff, single sign on )
* History management and back button mess
C -> ASM / byte code -> machine code -> primitive CPU operations
All these javascript and css transpilers however, they force you to know the higher level, the lower level and many of the intricacies of how one translates to the other.
Tis a trick question. The actual complexity experienced by humans depends on the job they are trying to do with the object. If you are a botanist/arborist driving to work, then clearly it is the apple. If you are a mechanic on your lunch break, then clearly it is the engine.
It's true that abstractions can lead to a lot of trouble when they are failing to work correctly. But when they are good they add a lot of good value. When did you last have to debug a system call, because you couldn't open a file? There are really good, old abstractions that no one thinks about anymore, since they're just really good.
A framework in web development is of course another matter, where complexity can sometimes be staggering. I believe that the lifecycle of React components is really nice. Instead of initialising X things you can think about how a single component will change over time.
There are endless examples of good and bad abstractions, I guess. But at the end of the day, we have to choose abstractions when we need them to reason about what we're doing, despite adding more points of failures.
After all, if an abstraction just enables us to think faster and more clearly about a problem, AND allows us to write less code, that means that less bugs will be in the final product, assuming that the density of bugs is constant. ;)
The problem that haunts me -and a lot of other hackers I presume- is that we have this urge to understand every little detail of the systems we design. Nothing is good enough.
The other problem is that by using arcane and primitive tools we limit ourselves in the ability of producing real work. As with everything in life, we need to make the distinction between tinkering and doing real work.
If all we do is tinker, very little gets done :).
PS: I just read the satire Real Programmers Don't Use Pascal [1], my comment could be highly biased from that.
[1]: http://www.pbm.com/~lindahl/real.programmers.html Bonus: Here is a little bookmarklet I wrote for styling unstyled html pages for easier reading.
javascript:(function() { document.body.style.maxWidth='700px'; document.body.style.margin='0 auto'; document.body.style.lineHeight='1.5'; document.body.style.fontSize='20px';} )();