mikebelanger

I've been using Linux on/off since the late 90s. And now, both my mini-PC and my laptop are running Fedora, and I swear by them.

So as much as I want to believe that others share my taste, I'm not sure how to interpret the two statistics in this article.

Sadly, I'd lean towards this article's attribution:

"Cloudflare’s unfiltered figures may include automated requests unless human traffic is classified. This is especially relevant to Linux, widely used for servers, automation, development environments, and headless browser workloads"

I suspect many people are running AI agents on cloud servers, which are most likely running Linux, and many of those agents are browsing the web. That's more likely what is driving this adoption. That, and as the article points out, more accurate OS classification on the part of StatCounter (from unknown to "Linux"), especially if its over the span of 1 month.

Yeah, that was my first reaction to that headline too. Given a second thought, he probably means the opposite of "replace", so in this context, "maintain people." maybe? I know marketing headlines shouldn't be interpreted literally, but it tripped me up at first.

Cool stuff!

If I may ask, what do you use to host now?

podman-compose is "mostly" compatible. I "plain" podman at work, but there we just have a bunch of shell scripts that spin up/down/build containers. For regular dev work, it's fine.

For personal stuff, I've been experimenting with podman's Kubernetes files: https://docs.podman.io/en/latest/markdown/podman-kube.1.html. Which, IMO, "feel" like docker-compose the most. You can run services via "podman kube play ..." and install them via quadlet install too.

podman-compose has gotten much better. I used it for a work project a few months ago, and it ran fine. That said, I know there are some random little things podman-compose doesn't support, so be careful.

What I'm experimenting with right now is defining stuff with a Kubernetes yaml, which podman also supports: https://docs.podman.io/en/latest/markdown/podman-kube.1.html.

It's slightly more verbose than docker-compose, but podman supports it natively and you can actually wrap your app containers into a single "pod" for easier management.

Interesting that ports can be written so quickly with AI. But that aside, I have to ask...why? You want a super performant bundler/runtime/package manager written in rust with TS support, Deno has this already.

Amazing!

Cool! Thanks for the response, I'll give it a shot again sometime

I lean towards vanilla javascript and webcomponents myself, and eschew large frameworks in favor of lighter, or in some cases, no framework at all.

That said, this and many other webcomponent articles mischaracterize usage cases of webcomponents:

1. Being "Framework-free"

Frameworks can mean anything from something massive like NextJS, all the way to something very lightweight like enhance.dev or something more UI-focused like shoelace. To suggest being completely free of any kind of framework might give some benefits, depending on what kind of framework you're free of. But there's still some main benefits of frameworks, such as enforcing consistent conventions and patterns across a codebase. To be fair, the article does mention frameworks have a place further down the article, and gets close to articulating one of the main benefits of frameworks:

"If you’re building something that will be maintained by developers who expect framework patterns, web components might create friction."

In a team, any pattern is better than no pattern. Frameworks are a great way of enforcing a pattern. An absence of a pattern with or without webcomponents will create friction, or just general spaghetti code.

2. Webcomponents and the shadow DOM go together

For whatever reason, most webcomponent tutorials start with rendering things in their shadow DOM, not the main DOM. While the idea of encapsulating styles sounds safer, it does mean parts of your page render after your main page, which can lead to DOM elements "flashing" unstyled content. To me, this janky UX negates any benefit of being able to encapsulate styles. Besides, if you're at a point where styles are leaking onto eachother, your project has other issues to solve. The Shadow DOM does have its use, but IMO it's overstated:

https://enhance.dev/blog/posts/2023-11-10-head-toward-the-li...

Neat, and neat to see the burn framework getting used. I tried this on latest Chromium, but my system froze until my OS killed Chromium. My VPN connection died right after downloading the model too. (it doesn't have a bandwidth cap either, so I'm not sure what's happening)

Yeah that'd be really something. If you could just pay the cost up-front, rather than worry about how much every newer request cost, that really changes the game. There's still many other issues to worry about, like security. But as the author points out, we might be much closer than we think.

Artifactory works fairly well. Although admittedly, when a user grabs a new dependency, they're downloading from the npmjs registry like anyone else.

Really, the killer combo would be to have some kind of LLM-based tool that would scan someone's artifactory. Something smart enough to notice that code changed, and there's code for accessing a crypto-wallet, etc. This would be too expensive for npmjs to host for free, but I could see this happen to hosted artifactory dependencies.

Bringing it back to the site, the author does describe implementations of context providers and signals:

https://plainvanillaweb.com/blog/articles/2024-10-07-needs-m... https://plainvanillaweb.com/blog/articles/2024-08-30-poor-ma...

I haven't tried signals yet, but I couldn't see why you could pass in an object with multiple values.

I really wish web components weren't promoted as a "framework alternative" and more of a standardization of custom display components. Frameworks like enhance.dev and lit.dev are good examples of this.

So this isn't even a question about web workers, it's a question about how to prop-drill non-string/number data through multiple layers of web-components.

Tbh, I'm not sure there's a way for that. But why not just define a method in your target child component and pass the worker in there?

>just adding a method to a class. OOP 101.

You're right, it is just a method call from a class. Nothing interesting or new. And that's exactly why I like it! I like me FE code as boring, unimpressive and as simple as possible.

Great resource! I particularly like the fact that their web component section doesn't use the shadow DOM. It's really too bad custom elements got associated with shadow DOM, as they're so useful beyond the more niche usage cases of the shadow DOM.

You can invoke custom methods and pass in any kind of data into them. As in

``` class SomeElement extends HTMLElement { constructor() { super(); }

  someMethod(x) {
    this.innerHTML = `<h1>${x}</h1>`;
  }

}

// ignore registry stuff

const customElement = document.getElementById('custom-element-id');

customElement.someMethod(42); ```

But you won't learn that from most mainstream custom element tutorials though, for whatever reason.

>Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.

I feel the same way. React and Angular (well an earlier version of Angular) were made prior to ES2015 being mainstream, so I do think they made sense to use when they were initially created. Since then, I've become burned out from the constant churn of new frontend frameworks to learn. Even within the world of React, there's different ways of writing components, and different state managers.

The nice thing about the plain "vanilla" approach is it can be used to enhance a more traditional SSR-rendered site. And it doesn't need a complete rewrite in React or whatever.

The author of this article blog is describing some more advanced SPA-like scenarios, but those are completely optional

> It’s doesn’t have to be especially onerous discipline if you embrace it, but it becomes considerably more onerous as it becomes more social: if some members of a team/contributors to a project embrace it more/less than others, that difference in commitment becomes a constant source of friction.

That's one of the stronger arguments for opinionated pre-processors/frameworks/libraries like Typescript/TSX/JSX/React in general. Because it abstract away those things that only some team members would embrace, you effectively make everyone embrace them. That leads to less friction.

But this reduced friction comes at a cost: more complex abstractions and incidental bugs related to that complexity. And as far as the procedural vs declarative: after a certain degree of complexity, I find myself introducing procedural codes within useEffects, useMemos anyways

I've been using Zed for a few months now. One thing I really like about Zed is its relatively discrete advertising of new features, like this edit prediction one. Its just a banner shown in the upper-left, and it doesn't block me from doing other stuff, or force me to click "Got it" before using the application more.

This definitely counters the trend of putting speech balloons/modals/other nonsense that force a user to confirm a new feature. Good job, Zed team!

> It seemed slightly more trouble to do modifications than a cinder block wall, but the quality and strength was much higher. I went with low expectations but I was impressed.

So the electricians and plumbers would all come in after the wall was printed, and saw through it all? Sawing, adding and then filling it back in sounds like lots of work to me. With stick-frame, wiring and plumbing are still a significant cost, but the actual hole-making part would be a small proportion of it.

How would plumbing and wiring work? The article states that the wall is a semi-hollow, corduroy pattern, so do the printers leave openings in the walls so pipes/wiring get shoved into them after?

> But I think that complex architectures are going to win out over the "just scale up with more data and more compute" approach.

I'm not sure about AGI, but for specialized jobs/tasks (ie having a marketing agent that's familiar with your products and knows how to copywrite for your products) will win over "just add more compute/data" mass-market LLMs. This article does encourage us to keep that architecture simple, which is refreshing to hear. Kind of the AI version of rule of least power.

Admittedly, I have a degree in Cognitive Science, which tended to focus on good 'ol fashioned AI, so I have my biases.

Neat stuff! I'm guessing the "Programmable Spaces" piece here: https://spatialpixel.com/programmable-spaces/ is using the same IDE as the one demonstrated here: https://spatialpixel.com/natural-language-ide/, only with some kind of AR? If so, are the p5 sketches generated realtime? That would be seriously impressive.

Does anyone else think this article was written by some kind of LLM? A very poorly prompted one?

Maybe there will be forks that remove all the collaboration stuff. I can't imagine it'd be that hard.

I'm sorry to hear you had such a bad experience, but this is typical treatment from Air Canada. As a Canadian who often flies, I suggest going with Porter or WestJet instead. They're both leagues ahead of Air Canada.