that said: still a nice write up, learning about some of the architectural choices that AMEX makes is definitely insightful (and relavent/useful to what i am working on right now as well!)

what gives you that impression?

Google is spends millions of dollars researching and implementing SynthID [0]; ensuring all videos generated have a watermark to ensure they can be detected. As well as using SynthID to detect AI-generated videos, which is what I am guessing they are using @ YT to detect and label the AI videos.

I am far from a Google or AI fanboy, closer to an admiring hater, but I just don't see how they are making AI generated video impossible to detect if they are going out of the way to ensure SynthID /AI watermarks are present in any video generated on the platform.

unless you mean impossible to detect by human eyes; but if that's the case, so is everyone else. except everyone else is NOT spending resources on research for watermarking and keep the detection algorithms ahead of the curve.

C'mon, I'm not even apart of the movement to move away from GitHub, but that's not really a valid argument. Sure, they CAN download the source code, but its not nearly as automatic. They don't get to download it all, en masse, from copying hard drives/databases they already own. They have to go over the internet. They don't get automatic notifications when new code gets pushed. And finally, if one wanted, they can make it harder for bots.

I certainly believe that these companies do get away with a lot more than the average Joe - see: Facebook downloading Anna's Archive, every pirated eBook - but that doesn't mean you have to hand it to them on a silver platter.

Plus, even if your code is private on GitHub, you can guarantee that they can't train there models on it anyway; unlike if you host it yourself, or somewhere else.

Does anyone else find it ironic when closed-source GitHub claims it's some super hero for open source?

FAANGS love to give away money to get people addicted to their platforms, and even they, the richest companies in the world, are throttling or reducing Opus usage for paying members, because even the money we pay them doesn't cover it.

Meanwhile, these are usable on local deployments! (and that's with the limited allowance our AI overlords afford us when it comes to choices for graphics cards too!)

transportation government operations natural resources community development education & social services agriculture international affairs science & space and energy

...anxiety rises.

Pretty cool to see all 6 layers, paste layers, and adhesive layers as well. I've always wondered how the cake was made and if big projects do/could use KiCad. Seems like a lot more work relative to those Single Layer PCBs on YouTube for things like emulators and custom PCBs. Glad I now know for sure, that I can't do this.

IMO, rounding for cash purchases only sounds worse than keeping the pennies.

But with 5 trillion dollar companies these days that are "worth" more than the entire GDP of Germany, why not. It's not real. It's just a number on a computer at this point.

I'm going to say this because I think you might not know this, but also because I think many others might not have thought about this:

Almost always, a programming language is UI agnostic. Swift SDK for Android means: You can now write Android Apps in Swift. This doesn't magically include Apple's components / SwiftUI. When you write code for a platform, specifically an SDK for an OS, all you do is expose that platform to that language.

So, as long the SDK/bindings are there, a new "Window" means whatever a the OS thinks is a Window. A Button is what is defined (or exposed/binded to) as a Button in Android.

Swift was sorta released for Windows: a new Window looks like a generic Win32 Window. The same one you would get if you used C, C++, Rust, etc..

All your examples are GREAT examples to explain how this works: - Flutter has "Cupertino" to allow people to use Flutter to make Apple apps, and not have to learn names/methods/interface of the native Apple UI. - React Native: A LOT of work was put in to make/bind Apple native objects to a React component. And the same for Android.

So again:

The Swift SDK for Android means you can write your Android apps in Swift. The same apps you might of wrote in Java or Kotlin, you can now use Swift. Meaning whatever it looked like in Java/Kotlin (using native api's), it would look like in Swift.

The SwiftUI, Apple's component library written/exposed to Swift, is something completely different.

1) The code that is running is not what's presented; it executes (non-transpiled) vanilla JS.* Why not just show that?

2) Removing the box shadow massively makes the two closer in performance.

3) The page could just be one sentence: "Reflowing the layout of a page is slower than moving a single item." GPU un-related.

---

*Code that actually is running:

```js

        , u = t => {
        h && clearTimeout(h),
        l.forEach( (e, s) => {
            const {top: o, left: n} = m[r[s]];
            t ? (e.style.transform = "translate(0px, 0px)",
            e.style.opacity = "0.7",
            e.offsetHeight,
            e.style.transform = `translate(${n}px, ${o}px)`) : e.style.transform = `translate(${n}px, ${o}px)`,
            e.style.top = "",
            e.style.left = ""
        }
        ),
        t && (h = window.setTimeout( () => {
            l.forEach(e => e.style.opacity = "1")
        }
        , 500))
    }
        , d = t => {
        y && clearTimeout(y),
        l.forEach( (e, s) => {
            const {top: o, left: n} = m[r[s]];
            e.style.top = `${o}px`,
            e.style.left = `${n}px`,
            e.style.transform = "",
            t && (e.style.boxShadow = "0 14px 28px rgba(239,68,68,0.45)") // REMOVING THIS LINE = BIG DIFFERENCE
        }
        ),
        t && (y = window.setTimeout( () => {
            l.forEach(e => {
                e.style.boxShadow = "none"
            }
            )
        }
        , 500))
    }
           

Honestly, the "could of" is more of a "sometimes I write how I sound" thing, but anything else, is more of a middle of the night brain mush.

I actually re-wrote that bottom part at least twice because I had a lot to say, but didn't know how to say it concisely. As I was writing it, I kept having less and less confidence that any readers would have prior knowledge about I was writing about (ex: Plex, HDHomeRun, TiVo Edge), so I kept defining or explaining things in parenthesis and re-ordering the sentences; so at one point I just had to say, good enough, click reply

I hate lengthy/wordy comments that coulda' () been just a couple of sentences, but I also love to explain things in a way that a wide range of people can comprehend, so it's a battle at times. (this reply is a good example...reply)

I felt like they had consumer awareness at one point. Maybe if they went with there own premium streaming service, as oppose to only trying ad-based streaming services (like Pluto) OR continuing to try to make money charging people monthly for a subscription to use a device they first have to purchase.**

Instead they kept the old business model and went to more of a business-to-business service oriented offerings. Selling metadata, APIs, TV Guides, Car infotainment, all oddities IMO as most IPTV providers like to use turn key solutions.

I actually use the Tivo Stream 4K as my smart device. Works great, gives me 4K, can download Android TV apps, and is cheap $35.

Not a fan of ad-based TV (which is the Tivo+ thing, like Pluto, etc...), but I use it mostly for YouTube, Plex, etc.

--

*: My Plex server uses my HDHomerun for live tv; TiVo could have been both if it was more open. A TiVo competitor to Plex's Pass + Live TV service could of been there subscription revenue, and a TiVo competitor to HDHomeRun's devices could of replaced their DVR revenue. They could take the Tivo Edge, open it way up (as the HDHomeRun takes cable and give you actual m3u8's; this lets you decide where you view or record TV, and makes the device actually useful for commercial deployments as well (offices, restaurants, dorms, hotels, etc...). Pretty much: add features similar to Plex (i.e. combining my OTA/Cable recordings with my local media) + Plex's Live TV (Tivo already has the richest data and a sleeker guide) and combine the Tivo Edge CableCard and OTA in one device. This would appeal to many users, bring the hardware price down as it's one model, and provide them with both revenue streams like they are used to.

>> "Hotwire is sort of vanilla rails and it enables you to create very modern experiences with content live updating through web sockets and it is basically a one liner to setup."

My point was that web development isn't complex, but the core is simple; but modern web development is.

Your "Hotwire is sort of vanilla rails" statement is a perfect example.

What you claim to be simple, is a big list of tooling, web-sockets included, integrated together. The end result is using it might be a "one-liner", but that doesn't mean it's simple. And that's OKAY. Because simplicity should be the standard; and adding things, like sockets for live updates, should be something you explicitly enable (with modern web-apis, its definitely simpler than it used to be, but that doesn't mean its simple)

Tooling isn't the problem: The complexity is inherent to modern web development. You see similar "hidden" complexity in other frameworks like ASP.NET, and GUI desktop frameworks as well.

If you're using Rails as an API backend with React handling the frontend, it's almost a completely different application architecture than a traditional Rails monolith. So the list of tools (Vite, React, Prettier, etc..) is almost for a completely different problem (again, unless you use Rails for FE; if you want to use Rails for Frontend, use Rails for Frontend; not a fan of the mash-up at all.)

The real issue is learning methodology: A lot of developers today start their careers with frameworks (point 4) before learning the fundamentals of the web (points 1-3).

HTML for markup.

CSS for styling.

Learning server-side logic (e.g.: can POST and can return a completely different page at the same URL) and databases for dynamic content.

Then, JavaScript for interactivity.

Embrace the tools: Each tool on the list (Vite, Tailwind, etc.) exists for a reason, and they're all necessary for a modern web application. Saying there are "too many" is an amateur take on the reality of the ecosystem.