It's great for document formatting. For app layout, it's very easy for the cascading aspect to shoot you in the foot if you're not careful (which is why even the most purist CSS writers will tend to layer abstractions or rules on top of it, even if it's only convention based ones without technology like BEM.
I'd argue that it's impossible to have locality in all aspects. If your style, logic, and DOM are separated almost certainly you have a separation in domain - you're going to have styles, logic, and DOM concerned with "widgets" in your product and if they're separated by whether they are style or logic that means they can't be correlated by their "widgetness".
Really the decision comes down to whether it's better to separate based on style/logic/dom or on the business domain, and I think at least for web apps, separation by domain wins out in most cases.
Artists and DJs are a separate category than what the original article is talking about, and I'd agree that there's more need for creativity in those cases (although I have definitely seen websites for people in more creative fields that have thrown usability and legibility out the window in pursuit of annoying "gee whiz" overly designed sites.
The mechanic is a separate argument - the article is talking about uniqueness of design and creativity, not cleanliness / orderliness. These sort of Tailwind designs are exceptionally clean and orderly, they're just predictable and not unique. To apply the article to your analogy, I wouldn't particularly care if my mechanic had the same coveralls that most mechanics wear as opposed to some unique design of coveralls.
I like predictable UI even if it's a little "boring" because given the choice between utility and style, I'll choose utility every time. It is possible to make stylish things that also have very high utility, but it's a lot harder than favoring one, and I will always favor utility.
Take the author's example in this article - he calls out two things more than anything - a single sentence "pitchy" description of the product, and plan cards that look and feel extremely samey from site to site. I'd argue that both of these "downsides" are an upside for me as a consumer:
- Having a one sentence quick summary of what a product does allows me to make a quick decision about whether I'm interested in reading more about this product.
- Consistent plan cards lets me leverage my shared understanding of how plan cards work to instantly answer questions like what the monthly / annual pricing is like, what tiers are available, etc, that a bespoke presentation would require me to think about.
If I come to a landing page for a product, I'm more interested in answering questions like "is this a product I would like" and "how much does it cost" than appreciating the design of a page.
I mean we can also change laws again in europe (in favour of that) - but we could also keep it as a separate module. So the LTE chip only gets used for an emergency call and nothing else. No remote control.
Unlikely to happen, but possible (not 100% safe, but good enough).
If you don't turn on the LTE chip, it can take a while to get registered or a network in order to perform an emergency call. If the LTE module is turned on (the same applies for mobile phones) the network operator will know your coarse location because of the LTE specification itself. Furthermore, all communication equipment is legally required to support Lawful Interception; and LTE is no exception to this.
Was my sentence that unclear? I constructed it as a OR. Either change the laws (my favourite solution as I don't like enforced modification of my car) - or use a technical solution to just meet the law.
Physical controls are worth it for me. Having a press to talk button, track advance and volume controls on my steering wheel is a pretty nice quality of life feature. I could do without a screen if the car has that.
That is an amazing use of the technology, and for sure something that should result in a pretty successful company - but not enough to bet the entire VC ecosystem on.
I think anyone saying AI has no use is being willfully ignorant, but like every hype cycle before it since mobile (the last big paradigm shift), IMO it's going to result in a few useful applications and not the paradigm shift promised.
Allowing multiple versions of a library to run simultaneously is a design decision - there are definitely shortfalls to allowing this (increased code size, a relative nightmare to audit, increased tendency towards downstream dependencies opening vulnerability potential). Culturally with bundler it tends not to be an issue since the inability to run multiple versions of packages tends to reduce the number of secondary dependencies to only pretty core libraries, and encourages permissive version requirements for gems.
Do you mind sharing some details? This doesn't match my experiences at all really - while I think running into messes with NPM is sometimes a little overstated, the number of times I've needed to do something drastic like `rm -rf node_modules` is not insignificant and I've never had to do anything at all like that with Bundler.
The only problem I can really think of is working through issues when two gems require different irreconcilable versions of a library, and that's more of a fundamental ruby issue / design choice than a problem with bundler itself.
I have had to use older versions of npm on unsupported nodejs. There was no pinning, or guard rails with upgrading. I have borked the entire npm install doing that because the later npm wanted to use newer syntax that was not backwards compatible.
What you and I describe is not a bundler or npm problem so much that the software we are working on requires an outdated version of ruby and nodejs.
I agree with the the other comment though — npm has more problems even when with the latest version. Like Nodejs, it is flawed by design.
reply