Could you be more specific about which payment is upsetting you?
Assuming OP is not a billionaire themselves, I can only think of cash flowing from a billionaire employer to OP for work done by OP. But I don't see how that could "pay for" the billionaire's yachts?
I like how this went from “piracy is categorically theft” to “trickle down economics is real and good” in so few posts, it is an impressively rapid display of statements that look like silly opinions but are actually objectively false assertions
> If you want to talk about those things, I suggest starting a new thread at the top level.
It seems like if you didn’t want to talk about the things that you implied in your posts you would elaborate on what you really meant, instead of asking folks to repost the points that you were trying to make.
As long as it is based on AOSP, it is at the mercy of Google to release source code and updates. Given recent trends, I wouldn't be surprised if Google stops shipping Android source completely.
I would love if there were a different OS name to designate "Android phones with Google Services snooping in the background" but with the Android Open Source Project being called what it is, I fear "Android" will continue to be understood as a word for either variant
> I fear "Android" will continue to be understood as a word for either variant
Well, "Android" generally means either variant. I run GrapheneOS and I call it Android. If someone asks, I say I run Android, not GrapheneOS. Actually in terms of experience, it is Android to me.
But in a context where we oppose GrapheneOS to Android, then I think it's important to be clear. GrapheneOS belongs to the family of OSes that are based on AOSP (like Android, LineageOS, IodeOS, /e/OS, CalyxOS), while Android is itself a "subfamily" of that, including the Google Android, the Samsung Android, the Xiaomi Android, etc.
In a way, I personally feel like GrapheneOS is closer to Google Android than the Samsung Android is from the Google Android, if that makes sense. Moving from GrapheneOS to Google Android, I really don't see significant differences. Now Moving to a Samsung Android, I need to adapt a little.
All that to say, I really only make a difference when we are talking about AOSP-based systems as a distinct group, by opposition to "Android certified" systems. Just like it sometimes make sense to talk about GNU/Linux in specific conversations, but generally, we refer to a Linux distribution as "Linux".
I take that point, that's a useful thing to do. Not sure that many people even in threads like these will get it unless explained (at which point you might as well word around it) but on a close forum or chat this is definitely a useful approach
I am honestly getting tired of people complaining about the fact that there is a less ambiguous way to name things. Those projects are more and more converging into saying "AOSP-based" (but that's evolving, interesting how language works!). GrapheneOS always says AOSP-based. The English wikipedia page of LineageOS says AOSP-based. In the past we used to call them custom ROMs, but the naming has evolved.
Of course, it is only relevant when it is relevant.
You can join a discussion about cars, where people talk about their Honda or Opel or Fiat, and when they ask you what you drive, you say "a car". And when they say "no but... which brand", you can go on and explain to them that they don't know how to use language, that "a car" is the common way to talk about those vehicles and that nobody in the world cares about a brand, even though you just witnessed a discussion where those people did care about the brand. Sure, you can do that.
But don't expect to have an enjoyable social interaction this way. And don't tell me "but you started it!": I answered to a comment that was making the article sound ridiculous by proudly conflating the two concepts.
> It's ridiculous to say it's incorrect that GOS is not Android based.
I totally agree, but that's not what I'm saying, is it?
Someone said:
> "Break Free from Android and iOS" looks inside - Android
I answered that there is actually a nuance that is relevant in the context of this article. Ignoring that nuance to make the article sound stupid is simply unfair.
It's not necessary to spam the comments with your personal reinterpretations of widely known project names that don't match how these names are actually being used. If you really feel the need to be wrong on the Internet at least try to not repeat yourself.
Jumping up and down in the file is not much better and you still need to come up with names for classes. I want to look at an element and immediately know how it's styled.
I think your point has very little to do with tailwind and everything to do with CSS. Tailwind is optimized for modification and maintainability. We could replace your example with
<div class="hero-header hero-header--large">...
but now any time we want to modify hero-header, we're trolling through the whole site to find where else these classes might be used so we know what to test to avoid breaking anything
Sure it's easy to look at the element you shared and say it's too complex (it's really not, it's very declarative), but the complexity must live somewhere, and I'd choose Tailwind over any other prevailing system because it's isolated and safe to modify
You can fold it, format it, and IDEs preview it. This is like me posting the equivalent CSS in one big line. But even without all that I still prefer this over dealing with cascading styles in stylesheets. Never again.
What stops you from doing the same thing in CSS? It is trivial to assign a specific CSS class to an element that is the root node of a "component" and scope rules under that.
Angular is pretty decent in that it gives you everything you need (the concept of a page and routing, services etc) but one thing I'll give React is the simplicity of changes to attributes just triggering updates.
From where I am standing it is mostly Angular or Next.js, both have separation of HTML and CSS by default, naturally they cannot block someone to come in and put tailwind on the project.
In my lived experience, shared components just become another problem. Especially in a fledgling company, the iteration velocity is actually negatively affected by shared libs because there's always overhead to (not) break legacy. so shared components bloat to address every evolving need.
And now with AI generated code i see so many wrapper patterns that forward endless props down, it's crazy!
TLDR: i almost always end up branching out into evergreen "reusable" components anyway.
Very unlikely the component library the CTO asked claude to DRY up the code with, is the one to rule them all.
FWIW, “colocation in component-based architecture” doesn’t necessarily mean shared code. It can just mean the one thing has all of its parts in one place, instead of having HTML in one file, CSS in another, JS in another.
You’re right about DRY and code reuse very often being a premiere (wrong) abstraction, which is usually more of a problem than a few copy/pastes, because premature wrong abstractions become entrenched and harder to displace.
Without a lot of discipline it is very easy to end up with a css with lots of unclear and hard to guess effects. Eg consider the case of <A type=1><B><A type=2></A></B></A> where A and B are complex templates. Any selector with the " " operator on A risk expanding to the inner A even if it was intended only for the outer. Similarly a :has selector might catch a descendant of the wrong element.
@scope fixes a lot of this, but it is a complex problem. With tailwind you mostly have to worry about inheritance
I find it to be more difficult. Especially if I can't pane the files in view comfortably (ie. beyond 2 or 3 it gets significantly harder to work across them).
Some frameworks or coding styles really lean into having lots of tiny files. That necessitates a more complicated directory structure for the project. Locating files eventually tends to requires search capability rather than being able to look through the tree in a sidebar.
None of this is "hard" per se but I find the opposite is nicer to work with typically.
The problem is that the styles for something can be defined in multiple places, and that makes it hard. Especially with CSS and (potentially) having specificity issues if things aren't managed well. Having them as a part of the component means that problem goes away.
this is grey text from tailwindcss.com, I wouldn't call it easy and readable.
<div class="relative before:absolute before:top-0 before:h-px before:w-[200vw] before:bg-gray-950/5 dark:before:bg-white/10 before:-left-[100vw] after:absolute after:bottom-0 after:h-px after:w-[200vw] after:bg-gray-950/5 dark:after:bg-white/10 after:-left-[100vw]"><p class="max-w-(--breakpoint-md) px-2 text-base/7 text-gray-600 max-sm:px-4 dark:text-gray-400">Because Tailwind is so low-level, it never encourages you to design the same site twice. Some of your favorite sites are built with Tailwind, and you probably had no idea.</p></div>
In my editor this looks like this, with an extension like Tailwind Fold or Inline Fold:
<div class="...">
<p class="...">
Because Tailwind is so low-level, it never encourages you to design the same site twice. Some of your favorite sites are built with Tailwind, and you probably had no idea.
</p>
</div>
There's nothing in Tailwind that makes the craftsmanship dead, and your proposed solution with scoped styles somehow a revival of said craftsmanship.
Note how your solution literally depends on a build tool (Vue) to work. Whereas Tailwind can work with no build tools (tailwind build tools removes unused classes, and that's mostly it).
And then you go:
--- start quote ---
Juniors still come along and just do margin: 13px. In tailwind, they do m-[13px]. No difference. At least with CSS its centralized.
--- end quote ---
When your scoped CSS example is literally decentralized per-file CSS that has `margin: 5px` in it. That gets compiled into a meaningless `class-678x8789g` by the build tool.
> The people I've seen who are most excited over tailwind are generally those that would view frontend as something they have to do, not something they want to do.
Cognitive load of looking at 12 open files trying to understand what’s happening. Well, in fairness some of those 12 are the same file because we have one part for the default CSS and then one for the media query that’s 900 lines further down the file.
If you have a complaint about your styles being so complicated and in a giant 900 line mega file, I don’t see how you address physical size other than breaking up the file.
Granted, nesting support was also added fairly recently in the grand scheme of things, which boggles the mind given how it was such an obvious problem and solution that CSS preprocessing came about to address it.
Also modern CSS is often written in a <style> tag either in a native web component or in a framework which supports single file component like vue or svelte.
- Allows you to use async/await and generators (useful for pagination/infinite scroll)
- You can test the view model independently of the rendering logic
- Dramatically reduces the code that lives directly in the component (it's only TSX)
- Allows for better abstractions and state management (services)
- Clear path to leveraging threads in front end applications
- Simple "visual" components (like <Input />, <Button />) don't need view models, just orchestrating components.
In practice, when writing traditional React, I focus too much on rendering cycles and the nuances of managing component state while spending much less time on making the application look good and feel performant/nice to use.
Having a component be pretty much exclusively TSX gives me a clear separation of "view" and "what the view needs" - so I just think of the html structure and css. I tend to create much better looking and nicer applications this way.
> It's way more skipping around in the codebase to find the parts you actually care about
Not really. You cnt+click to an implementation. Say you have "await someApi.getItems()" - you just click and go directly there. Traditional React apps need to thunk with redux or have a bunch of custom hooks that quickly become a source of confusion.
The original model of computer security is "anything running on the machine can do and touch anything it wants to".
A slightly more advanced model, which is the default for OSes today, is to have a notion of a "user", and then you grant certain permissions to a user. For example, for something like Unix, you have the read/write/execute permissions on files that differ for each user. The security mentioned above just involves defining more such permissions than were historically provided by Unix.
But the holy grail of security models is called "capability-based security", which is above and beyond what any current popular OS provides. Rather than the current model which just involves talking about what a process can do (the verbs of the system), a capability involves taking about what a process can do an operation on (the nouns of the system). A "capability" is an unforgeable cryptographic token, managed by the OS itself (sort of like how a typical OS tracks file handles), which grants access to a certain object.
Crucially, this then allows processes to delegate tasks to other processes in a secure way. Because tokens are cryptographically unforgeable, the only way that a process could have possibly gotten the permission to operate on a resource is if it were delegated that permission by some other process. And when delegating, processes can further lock down a capability, e.g. by turning it from read/write to read-only, or they can e.g. completely give up a capability and pass ownership to the other process, etc.
It's been a while since I've Swifted but it was mostly with combinations of nested generics, lambdas, and literals. Annotating the type of the variable those were assigned to could improve performance a lot.
You don't need to add an annotation on `let foo = bar()` where bar is a function that returns `String` or whatever.
The only ways I know to take a full backup of an Android device require it to already be at least bootloader unlocked. There are unprivileged ways to take backups, but they don't work for all apps.
As far as I understand, on the mobile implementation not even the OS can access the buffers. So even with root you can stream L1 content but not screen record it
reply