dschuessler (u/dschuessler)

dschuessler commented on Traps to Developers qouteall.fun/qouteall-blo... · Posted by u/qouteall

Well, (like C++) new css attributes are constantly added. This means you constantly have to choose between the old way or the new way: either is fine, but “pick old or new at random on a per pull request basis” isn’t.

dschuessler · 15 days ago

You seem to assume that old CSS properties can be substituted for new ones. But as I said, to my knowledge this isn’t possible in most cases. Can you give an example of two CSS properties where 'either is fine, but only one should be used'?

Or do you mean something else altogether by 'CSS attributes'?

dschuessler commented on Traps to Developers qouteall.fun/qouteall-blo... · Posted by u/qouteall

QuadmasterXLII · 15 days ago

CSS and C++ both have the “pick a subset and enforce that, or suffer” nature. On my to-do list: make a github action that requires manual override to merge any pull request with a css attribute not already present

dschuessler · 15 days ago

I am unsure how this is supposed to work for CSS. To my knowledge, most CSS properties cannot be substituted for each other. If the subset to be enforced is "CSS properties already present", what is a developer supposed to do if their CSS property is not already present? Change the design?

dschuessler commented on Debian 13 “Trixie” debian.org/News/2025/2025... · Posted by u/ducktective

krylon · 22 days ago

As an owner of two i386 systems (both netbooks built around Intel's Atom N270), that run Debian, I am a little sad. I understand the reasoning, and I won't deny it is a very niche platform by now. But I had hoped Debian, with a history of supporting a wide range of platforms, would keep i386 going for a while longer.

Fortunately, bookworm will continue to receive updates for almost 3 years, so I am not in a hurry to look for a new OS for these relics. OpenBSD looks like the natural successor, but I am not sure if the wifi chips are supported. (And who knows how long these netbooks will continue to work, they were built in 2008 and 2009, so they've had a long life already.)

EDIT: Hooray, thanks to everyone who made this possible, is what I meant to say.

dschuessler · 22 days ago

Out of curiosity, what do you use these netbooks for?

dschuessler commented on Astro is a return to the fundamentals of the web websmith.studio/blog/astr... · Posted by u/pumbaa

teekoiv · 2 months ago

It's baffling to me why more SSR frameworks, Astro and NextJS namely, can't adopt static pages with dynamic paths like SvelteKit. So for example, if you have a page /todos/[todoId] you can't serve those in your static bundle and NextJS straight-out refuse building your app statically.

Whereas with SvelteKit, it builds happily and does this beautiful catch-all mechanism where a default response page, say 404.html in Cloudflare, fetches the correct page and from user-perspective works flawlessly. Even though behind the scenes the response was 404 (since that dynamic page was never really compiled). Really nice especially when bundling your app as a webview for mobile.

dschuessler · 2 months ago

Maybe I am misunderstanding you, but isn't this what Astro's `getStaticPaths`[0] function is for?

[0]: `https://docs.astro.build/en/guides/routing/#static-ssg-mode

dschuessler commented on Astro is a return to the fundamentals of the web websmith.studio/blog/astr... · Posted by u/pumbaa

rckt · 2 months ago

> I've found Astro perfect for marketing sites, blogs, e-commerce catalogues, and portfolio sites

Basically, not suitable for anything complex.

dschuessler · 2 months ago

I find it sad that Astro advertises itself this way, because I think that it is perfectly capable of building web projects of any complexity, simply by means of the component libraries you can plug in.

What makes it so great is not that it serves a particular niche (like "content-driven websites") but that it provides a developer experience that makes it incredibly easy to scale from a static website to something very complex and interaction-heavy without compromising UX.

dschuessler commented on Astro is a return to the fundamentals of the web websmith.studio/blog/astr... · Posted by u/pumbaa

sublinear · 2 months ago

> When I say Astro sites are fast, I mean properly fast. We're talking 40% faster load times compared to traditional React frameworks.

That's a really low bar. Why not static pages? Why even use a framework at all if you're thinking of using Astro?

dschuessler · 2 months ago

Per default, Astro generates static pages. So it makes sense to compare it to an approach that doesn't.

Using a framework has upsides over writing static pages manually. Most notably, you can decompose your website into reusable components which makes your implementation more DRY. Also, you can fluently upgrade to a very interaction-heavy website without ever changing tech or architecture. But that's just what I value. I whole-heartedly recommend trying it out.

dschuessler commented on Ask HN: Would you use a platform that deploys Docker Compose apps? · Posted by u/jsbroks

rmdes · 3 months ago

I would be interested, would even help testing and contribute but the next problem that arise if users had such easy way to deploy apps is, how do you handle backups, migration to new versions, single sign on, there are projects similar to this idea that already go very far, such as https://cloudron.io but they are "limited" in the amounts of apps they can provide with support and quality path for upgrades.

Inevitably, if I had all the apps I want to spin at hands, I would need a very neat way to make sure path to upgrades are smooth, don't break things already in place and potentially used in "production" by either friends of family..

dschuessler · 3 months ago

I don't think Cloudron is a good comparison for what the OP is suggesting.

They suggest a platform where "you upload any docker-compose.yml". Consequently, this makes SSO, updates, etc. the user's responsibility.

dschuessler commented on Ask HN: Would you use a platform that deploys Docker Compose apps? · Posted by u/jsbroks

verdverm · 3 months ago

Kubernetes is the standard now, why would I want to use something else?

I've not seen or used a docker-compose that was designed for production settings, it's primarily a dev time tool. Would we not have to maintain a second dc file with different settings?

dschuessler · 3 months ago

For one, to use the same tool in local development and in production. For another, because docker-compose is simpler than Kubernetes.

dschuessler commented on Ask HN: Would you use a platform that deploys Docker Compose apps? · Posted by u/jsbroks

dschuessler · 3 months ago

For reference, services trying this (or having tried this):

- https://kvmpods.com/

- https://dockerdeploy.cloud/

dschuessler commented on Show HN: SuperUtilsPlus – A Modern Alternative to Lodash github.com/dhaxor/super-u... · Posted by u/dhax_or

7bit · 3 months ago

> Like isObject([]) returning true - arrays aren't objects in my mental model.

Correct me if I am wrong, but Array factually are JS objects and "[] instanceof Object" is true.

Fair enough if that does not fit your mental model, but I would not use any library that treats facts like opinions.

dschuessler · 3 months ago

> any library that treats facts like opinions

The word 'object' has different meanings. One includes arrays and the other does not. They prefer the latter. You prefer the former. I don't think this has much to do with 'facts' and 'opinions', but rather with the practicality of choosing a certain way to speak.

I’d liken it to the word 'sorting'. JavaScript libraries sort in a certain way that is simple to implement. However, this is so different from what we typically mean by 'sorting' that people came up with natural sorting algorithms. Are these people treating facts like opinions on how to sort? I’d rather say, they acknowledge the relevance of a certain way to speak.