Yeah, there was a years long debate that effectively ended with: “We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.”
> We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.
I think that’s an exceptionally uncharitable description of what happened. This is a decision the WebKit team has been repeatedly publicly asking people to participate in for over 18 months.
> Help us invent CSS Grid Level 3, aka “Masonry” layout
> P.S. About the name
> It’s likely masonry is not the best name for this new value. […] The CSSWG is debating this name in [this issue]. If you have ideas or preferences for a name, please join that discussion.
> Help us choose the final syntax for Masonry in CSS
> We also believe that the value masonry should be renamed.
> As described in our previous article, “masonry” is not an ideal name, since it represents a metaphor, and not a direct description of its purpose. It’s also not a universally used name for this kind of layout. Many developers call it “waterfall layout” instead, which is also a metaphor.
> Many of you have made suggestions for a better name. Two have stood out, collapse and pack as in — grid-template-rows: collapse or grid-template-rows: pack. Which do you like better? Or do you have another suggestion? Comment on [this issue] specifically about a new value name (for the Just Use grid option).
The debates went on for years and following it closely became a poor use of time. Even the subgrid conversation seemed completely stalled. I think a lot of people tuned out long before any vote was discussed. I did.
But if you were the one who tuned out, then isn’t it uncharitable to describe it as their failing to make you aware of the vote? Isn’t it on you to stay in the loop?
Surely they can’t start just pinging everyone who might have cared at some point during the time to get involved.
Masonry was never “in”, no? Mozilla proposed it and were the only ones to implement it, behind a feature flag. Then WebKit proposed an alternative that was discussed at length:
People have been dragging their feet on subgrid, masonry, etc for almost a decade. I followed it pretty closely for years but stopped when it started turning into a Christopher Guest mockumentary.
Masonry or grid-lanes, who cares? I’m just glad masonry (the feature, Baseline 20XX) and subgrid (Baseline 2023) are finally here.
The article is muddled, I wish he'd split it into two. One for UUID4 and another for UUID7.
I was using 64-bit snowflake pks (timestamp+sequence+random+datacenter+node) previously and made the switch to UUID7 for sortable, user-facing, pks. I'm more than fine letting the DB handle a 128-bit int vs over a 64-bit int if it means not having make sure that the latest version of my snowflake function has made it to every db or that my snowflake server never hiccups, ever.
Most of the data that's going to be keyed with a uuid7 is getting served straight out of Redis anyway.
I've been tracking tracking my work down to the minute for the past seven years. (timer and log book.)
I started out trying to get to five "hands on keyboard" coding hours a day, five days a week, and realized that it was unrealistic after the first few years.
Four hours of coding time, five days a week works for me. If I'm a little under I work Saturdays, if I'm a little over I take off early on Friday. Unless I'm sick I put in 20 hours of coding a week. You would not believe how nice this way of working is.
I lost a month to Bazel a few years ago. The documentation had so many holes and what was there was either out of date or wildly inaccurate. You could not produce an Angular build using the tutorials as written. Everything was wrong. I'm sure Bazel great if you have a team of people to write bespoke libraries on top of it for each of your targets. I ended up using turbo for frontend and uv workspaces on the backend.
It’s easier/more complicated than that. Use 6 digit codes, tied to a specific reset session, with only 3 attempts allowed per-session, and sessions lasting only 5 minutes.
I spent a few hours trying to debug some fixed position issues with my JS/CSS code recently.Found out that iOS Safari fundamentally broke fixed positioning. How do you break `position: fixed`?
Apple devs are constantly attacking people on Twitter for complaining about Safari bugs but the front-end workflow is a waterfall because of Safari. You get your code working in every other browser and then rewrite it to work around all of the Safari issues.
Year 1: A small but vocal subset of the Python/Django community pops up in every thread: "It's not actually a problem." or "It's not an issue that my project would ever encounter so limited resources shouldn't be expended on it."
Year 2: People are choosing other solutions because Python/Django isn't addressing the problem.
Year 3: We'll form a committee. The committee doesn't think it's a problem.
Year 4: The community has a problem. Fine. Why doesn't the community write a Python Enhancement Proposal/Django Enhancement Proposal (PEP/DEP)?
Years 5-10: PEP/DEP ignored.
Year 11: The community has a problem. PEP/DEP implemented and released.
Year 12-22: Major packages refuse to support the change.
Year 23: Last version not supporting the change deprecated.
Year 23+1 day: Fork of last deprecated version Python not supporting change created and released.
I have 15 years of code in Python still running but spend a little more than 50% of my time in other stacks. I don't notice as many people arguing against basic features, like a REST API package in Django, in non-Python/Django communities. The precursor to a Django REST API package, content negotiation, has been a draft DEP since early 2014 (https://github.com/django/deps/blob/main/draft/content-negot...). That's going on 12 years of stalled progress for a feature that needed to be released in 2010.
With Python/Django you learn not to wait because nothing is going to change.
And yes, Python/Django are open source. And yes agin, I donate over $1,000/year to support F/OSS projects that I depend on.
My uninformed impression of the Python steering committee has always been like the C/C++ one. Ponderously bureaucratic, trying to find solutions that work for every competing interest, by the time they get to an agreement the real world has already moved on and solved things in their own way, which makes fragmentation and intercompatibility worse.
I know that Guido isn’t around any more, but this is what a BDFL is useful for. To have the final say when, inevitably, the squabbling parties are unable to find a compromise.
It's not a rant. It's a man with several burned fingers and a drifter beard muttering warnings from a corner.
How was the Python 2 to Python 3 migration for you? How many Python libraries are you responsible for packaging? Has that been fun for the past 15-20 years? How heavily do you rely on async?
Almost a decade for Django+major libraries to support Python 3. More than a decade for Django async support. I'm not ungrateful. And, I wish that I believed that throwing money at the problem would solve it.
Python has a large and diverse user base. That brings unique challenges that I don't see in other stacks.
Around 2018 I was struggling with Python builds and worked out most of the theory for something like uv, except I was going to write it in Python which introduced a terrible bootstrapping problem because if some Python dev corrupts the environment that it depends on then it is game over.
It was really clear to me at that time that the resolution algorithm used by pip wasn't sound and that it worked most of the time if your systems were simple but if you added enough stuff the failure rate of your build would start creeping up.
When I started talking to people on forums I found there was little awareness that pip was broken or that it was worth doing anything about, so because of that disinterest I decided not to do anything.
As I've mentioned to you before, it isn't difficult for the tool to exist in its own environment and install cross-environment. I have proof of concept for this and my own tool will work this way, compatible back to 3.6 (pathlib and f-strings are just too nice to avoid, and then there's the SSL support issue) and using things that have existed even longer.
Pip did fundamentally change its resolution algorithm in IIRC 2020 but yes it was bad before that. This is the hard part (I've been looking around for libraries that aren't as arcane as the `resolvelib` that was extracted from pip's internal logic) so the first announced release of PAPER will be focused on the other stuff.
I had a sense back then that pip was not great, but I had very little idea of what was wrong with it or why. My ire was more focused on Setuptools because of bootstrapping problems with setup.py and the general idea of using arbitrary code for building even just to specify metadata. So I largely ignored pip, and I regret that. What I'm making now I could have done years ago with that knowledge. (And even then I'm struggling just to make myself put in the work, since everyone will just use uv anyway.)
It’s not difficult in theory to have a clean Python somewhere but when I was trying to get some data scientists to do the right thing I found they had an uncanny ability to screw things up. Same for ordinary devs, if you have a clean environment somewhere some of them will find it, activate it and pip install into it or mess with the files or mess with the environment variables, etc. That job taught me to be incredibly [1] paranoid.
Poetry would try to run out of a clean Python but I found my poetry environment would get somehow corrupted every few weeks back when I used Poetry.
In contrast if you want to mess up uv it is just one file and a frickin’ binary, patching it purposely would be a challenge, messing with the source means installing a rust toolchain, maybe if you worked that hard to screw it up you know what you’re doing.
Maybe we are all just ranting into the void when posting on HN. Are you ranting into the void as well? Where should we demark this classification's borders.
I felt the post you replied to was valuable, as it provided a general (but not grounded strictly in the facts of a specific example) outline of how these work.
I will corroborate the details. I learned Django 15 years ago, still use it, and use about 30% of its functionality. I don't think I do anything with it now I couldn't have in the earlier versions.
Traefik's F/OSS projects are useless to me. Every single feature that I need to use is locked away in a closed source product.
Close to the same issue with Varnish Enterprise. Why would I pay for Varnish Enterprise if I can't even review or extend the source? Know what I have to do with Varnish's source once a quarter? I have to look at it. Because the documentation is non-existent. The closed source version is going to make my life objectively worse.
Aside from NGINX, Postgres, and memcached, I've had to patch every major piece of software in my stack at one point or another. I refuse to use any product that I can't fix myself.
It's current year, why are JWTs only supported in the closed source/enterprise versions of Varnish, NGINX, and Traefik?
I happily give $1,000/year to Django and lesser amounts to other projects that I depend on. Do you know how much I spend on projects that put features behind a closed source product? Zero. I will never pay for that.
I don’t think this is representative of the majority of traefik’s users. Most of us use it as an HTTP entrypoint for a container stack (docker compose, in my case) or for local development, and the FOSS version works great for that, with better dev tooling than anything else i’ve seen.
> I disagree. If you're a heavy Traefik user you're eventually going to need a feature that has been carefully omitted from the F/OSS projects.
Ok, I use it at home as part of my K8s cluster. I haven't once come close to needing a feature I don't have because it largely does what I need as a proxy and gets out of the way.
What features do you feel a more average of the target audience is likely to need or want to pay for eventually?
> > What features do you feel a more average of the target audience
>
> Auth and middleware packages that are essential for a production site.
>
> > I use it at home as part of my K8s cluster.
>
> That's not heavy use.
Didn't claim it was heavy use, I explicitly stated the context of the use and why I might not have run into the same issues being alluded to.
The question stands, with something like keycloak why would someone pay for an auth layer?
Sure, it's a choice but I think it's more that don't pretend you are open source when your carefully hide things behind closed sourced paid licenses. Be like Microsoft, we have eval version but if you want to use our Windows Server, you will be paying up. Cool, I can make a decision about your software with that in mind.
Do they not provide source under commercial license to enterprise users? It makes sense to not use in production if you need source to make sense of features.
By contrast, Kong Enterprise gave us source access to commercial offering plugins we needed. Not to all things but the things we needed yes.
...shouldn't you be paying then? Expecting developers to work for free to provide you with a product you use heavily is acting pretty entitled.
Just to give a contrasting account, I have been using Traefik to manage my public server (a $4 Digital Ocean VPS running a web server and a Bluesky PDS) and my local home server (running dozens of services with all kinds of weird configurations) flawlessly for more than 5 years now.
No. That is emphatically NOT entitled -- if the Traefik people have made heavy use of "open source," either practically or in marketing.
If you tout "open source" ideas in the work you do, then you can reasonably be held to the social contract that the ideas of open source originate in.
Lately (by lately I mean maybe the last 20 years or so) there's the idea of "because the open source ish company needs to pay the bills, they can completely abandon the ideas of open source."
Nah. You took from the commons, the commons has at least SOME right to ask for something back.
> If you're a heavy Traefik user you're eventually going to need a feature that has been carefully omitted from the F/OSS projects
That's literally the point of open core software. It's free and open source at the core, but "enterprise" / "scale" features are behind a license.
Enterprises/Scaled users that can pay, have to, to get the features they need. Everyone else can enjoy and profit off fully free and open source piece of software.
Win-Win-Win.
It's probably the only software business model that allows for a company to actually make money while also giving out most of their products for free as open source. Just selling support/services does not work and does not scale. Cf. literally everyone, the only orgs that somewhat pull it off are foundations/volunteer based projects like Django, Debian, etc but they are not commercial for-profit entities (there is nothing wrong with that, but most people want to be paid well). And your $1k/year, while decent towards a volunteer organisation, would be probably worse than nothing for a commercial company that has costs associated with each contract (legal, administrative, support, etc). For a fun story on the topic, check out HashiCorp's first commercial deal with Apple for a Vagrant plugin, that resulted in HashiCorp losing money on the deal due to the amount of money spent on lawyers reviewing Apple's terms and time spent supporting them afterwards. The only existing somewhat exception is Red Hat, but even they have moved more and more into open core with Ansible Automation Platform and OpenShift, which are their money makers, and have scrapped CentOS as a RHEL compatible free OS.
Same. At this point I've spent more time in devops moving away from shit that does this, and then doing it again, just to keep things as they are in a way that can be trusted. It fuckin sucks
I’ve deployed Traefik in-front of Kubernetes on some moderately large traffic sites with and without enterprise licensing. Recently I switched to using Caddy though. I know the stigma is that Caddy is not “production” ready and battle tested but I haven’t encountered any issues with it in terms of performance. It just works. Let’s Encrypt with CloudFlare DNS verification is super easy to setup and the configuration is very intuitive.
> It's current year, why are JWTs only supported in the closed source/enterprise versions of Varnish, NGINX, and Traefik?
I've found auth at the proxy to be a major antipattern. It adds a semblance of your backend being secure without adding the real user authentication and authorization it should have directly.
VPN is the better tool if you want to keep certain projects hidden from the general public and your application should be handling the JWT (hopefully in current year we're talking OIDC or some additional open standard on top of JWT) itself in order to properly enforce access controls.
With JWTs I don't do anything at the proxy beyond "This is a protected route. Is there a JWT? Is it valid? No to either? 403." This is one of the primary use cases for JWTs and it takes a majority of the load off of my application servers.
The route is open to the public for authenticated and authorized users. You wouldn't use a VPN here.
That's really just added work, IMO, and likely room for security misconfiguration between backend and proxy. You should still be validating and everything on the application server to inspect identity and possibly attributes like roles, so in the cases where you have invalid tokens you do the work once, just in the proxy instead of the backend, and with valid tokens you will do the signature validation work twice.
Have you used JWTs in production? Better to bounce a bad JWT with a server written in C/C++/Rust/Go at the edge than to pass it back and have it tie up a Python or Node process.
Even in Python the time to validate a small JWT is negligible. At the edge it's nearly imperceptible.
The problem is that you would be one of the 1% doing that, the rest of the companies would just not bother with that and it will end like many open source problems that constantly have to come up with ways to get funding.
Sadly, me too. We must share the fun-hating gene, or somesuch.
It's not a bad website either, the layout is really well done and it sells the branding. I just don't trust it to be accessible, as I only ever click through sites to find text content. Something about it feels like putting a Christmas tree in your bathroom for the sake of branding.
Ok, but if they have a bog-standard site like everyone else then they're not going to look any different than everyone else, which would cause users to leave.
I think the opposite is true. Sure, it's technically impressive, but users have been trained for decades at this point to understand how a basic marketing page should look and this isn't it. These kinds of sites are best left as portfolio pages for designers to show off their skills, not for B2B SaaS landing pages.
It stopped being memorable when it became a trend. I see 1-2 portfolio sites like this every week.
It’s slow. It’s janky. It’s buggy (random x/y overflow issues on mobile, reader view came up blank a few times.) It takes an enormous effort to maintain and update. Too clever.
https://m.youtube.com/watch?v=yikbSQ6tvlE
reply