I grew quite an appreciation of color TV recently when I made a software-defined SECAM decoder. It's mind-boggling that they were able to do this with 60s technology, to be honest. But then what do I know, analog electronics is witchcraft to me :D
edit: I watched the video. It only took them until the 13th minute of a 15-minute video to show something resembling a real video waveform, lol. That's, uh, not how you explain how TV works.
SECAM was pretty crazy because it required a delay line: a memory that would hold the previous scanline so it can be combined with the current one.
Without digital circuits, the delay line was a piece of glass. You’d convert the video signal to a sound wave, send it through the glass, and (hopefully) get it back exactly 64 us later so it aligns with the next scanline.
Yes I did read about these while doing my research. Also fascinating. Most (or maybe all?) PAL TVs also have a delay line to correct for phase errors. That ability is what differentiates PAL from NTSC, apart from timing.
Smithereen, my fediverse server software, replicates the old VKontakte desktop layout as faithfully as possible. Most functionality works without JS. Almost everything is rendered server-side. It does require a somewhat modern browser though. https://friends.grishka.me/grishka
We never pushed back on it when we could, because we thought WinAmp was sooooo cool, and now every application you run on your machine has a different look and feel and does not respect your desktop themes or customizations.
> The only developers I know who write Java full time work in systems that take pictures of things from far away.
Huh??? Google, the search engine part, is written in Java as far as I know. Yandex uses Java extensively. Odnoklassniki, once second most popular Russian social network, is written in Java. Banks like Java. Android apps are written in Java (and Kotlin, which I consider an abstraction over Java).
And that's only what I can remember right away. A sizable chunk of the world runs on Java.
Android does a lot less stuff in the background than it used to.
Initially there were no limitations at all, your app could just do whatever, you ask to start a service, the system runs it for you no questions asked, only kills it if a foreground app needs memory, and then restarts it whenever possible.
Modern Android is very strict about this sort of thing in comparison. You only run something in the background if you have a good reason to, and you better display a notification while it's running. Background processes that try to do stuff in the background without telling the system are killed and throttled aggressively.
I think he was referring to things the OS does, rather than apps running in the background. My computer is under nearly full load when I start MS Windows and let it be "idle". (I run 10 IoT Enterprise so there is less bloat than typically, I also already tried to disable stuff I could find.) When I start my GNU/Linux OS it is truly idle and I can do video processing or compile stuff with hundreds of translation units in parallel.
> Scraping static content from a website at near-zero marginal cost to its server
It's not possible to know in advance what is static and what is not. I have some rather stubborn bots make several requests per second to my server, completely ignoring robots.txt and rel="nofollow", using residential IPs and browser user-agents. It's just a mild annoyance for me, although I did try to block them, but I can imagine it might be a real problem for some people.
I'm not against my website getting scraped, I believe being able to do that is an important part what the web is, but please have some decency.
AI did not enable anything in this project. According to the readme, it was only used a tiny bit. It would've been possible 100% without AI.
In fact, I had this exact idea on my list of potential future projects for a while so I could teach myself more low-level programming. I avoid AI like the plague in everything I work on, and I still very much considered it doable.
Yes, of course the tiny packages cause some of the bloat. As mainly a Java developer being pretty paranoid about my dependency tree (I'm responsible for every byte of code I ship to my users, whether I wrote it or not), I'm always blown away by JS dependency trees. Why would you reach for a library for this three-line function? Just write it yourself, ffs.
But the real cause of JS bloat is the so-called "front-end frameworks". Especially React.
First of all, why would you want to abstract away the only platform your app runs on? What for? That just changes the shape of your code but it ends up doing the same thing as if you were calling browser APIs directly, just less efficiently.
Second of all, what's this deal with mutating some model object, discarding the exact change that was made, and then making the "framework" diff the old object with the new one, call your code to render the "virtual DOM", then diff that, and only then update the real DOM tree? This is such an utterly bonkers idea to me. Like, you could just modify your real DOM straight from your networking code, you know?
Seriously, I don't understand modern web development. Neither does this guy who spent an hour and some to try to figure out React from the first principles using much the same approach I myself apply to new technologies: https://www.youtube.com/watch?v=XAGCULPO_DE
You imply that you somehow get a visibly different end result if you touch DOM directly. Except to me, using React instead of a simple assignment to e.g. update the text on a button feels like taking several long flights that complete a lap around the world just to get from LA to SF, instead of the 1-hour direct flight.
React is a paradigm change (from imperative to functional) that makes sense in a large UI project. React itself is fairly small in terms of deps.
The main issue is the tooling. JSX is nice enough (not required though) to want a transpiler that will also bundle you app. It’s from that point things get crazy. They want the transpiler to also be a bundler so that it manages their css as well. They also want it to do minification and dead code elimination. They want it to support npm dependencies,etc…
It's a case of Chesterton's fence. Having built complex apps pre-react, I wouldn't be in a hurry to go back to that approach because I have first hand experience of running into the problems it solves.
That's like asking "why would you use Swing when you can use Graphics2D". Sometimes you want something higher level. The DOM is great and very powerful, but when you're building a highly interactive web app you don't want to be manually mutating the DOM every time state changes.
I am a core maintainer of Astro, which is largely based around the idea that you don't need to always reach for something like React and can mostly use the web platform. However even I will use something like React (or Solid or Svelte or Vue etc) if I need interactivity that goes beyond attaching some event listeners. I don't agree with all of its design decisions, but I can still see its value.
> Second of all, what's this deal with mutating some model object, discarding the exact change that was made, and then making the "framework" diff the old object with the new one, call your code to render the "virtual DOM", then diff that, and only then update the real DOM tree? This is such an utterly bonkers idea to me. Like, you could just modify your real DOM straight from your networking code, you know?
Yes, I don't understand "declarative" approach at all, it seems too wasteful and roundabout to me. You want to change something? You go and change it. That simple. I hate it when callbacks are abstracted away from me. Abstractions over callbacks always feel like they're getting in the way, not helping me.
> Also, why do you use SQL and databases? Couldn’t you just modify files on the filesystem?
Anyone can read a MySQL data file. IIRC the format is pretty straightforward. The whole point of doing it through the real MySQL server is to make use of indexes, the query optimizer, and proper handling of concurrency, at least. Sure you can reimplement those things, but at this point congrats, you've just reimplemented the very database system you were trying to avoid, just worse.
Yea, honestly you probably just don't understand. FE frameworks solve a specific problem and they don't make sense unless you understand that problem. That TSoding video is a prime example of that - it chooses a trivial instance of that problem and then acts like the whole problem space is trivial.
To be fair, React is especially wasteful way to solve that problem. If you want to look at the state od the art, something like Solid makes a lot more sense.
It's much easier to appreciate that problem if you actually try to build complex interactive UI with vanilla JS (or something like jQuery). Once you have complex state dependency graph and DOM state to preserve between rerenders, it becomes pretty clear.
One of my projects does have a complex UI and is built with zero runtime dependencies on the front end. It doesn't require JS at all for most of its functionality.
I just render as much as possible on the server and return commands like "hide the element with that ID" or "insert this HTML after element with that ID" in response to some ajax requests. Outside of some very specific interactive components, I avoid client-side rendering.
I agree with you. It’s baffling to see websites (not web apps) refusing to show anything if you disable JS. And a lot of such web apps don’t need to be SPA (GitHub,…)
SPA was mean for UI that relies on the client state mostly, not on the server data (figma and other kind of online editors).
reply