Why is an article from Jan 2025 being recirculated on HN now?
It's not Europol's role to push for this, and the European commission has suffered setbacks with ChatControl and other measures already since that time with excellent politicians such as Patrick Breyer doing an outstanding job of informing about and advocating for privacy.
Can you say more about (the|your perceived) relationship between SQL and htmx? When looking up HTMX[1] I was surprised to see what looks like a relatively young project with no direct relation obvious to SQL.
htmx is a hypermedia-oriented library (like hotwire, unpoly, etc.) and so when you use htmx you exchange HTML with the server, rather than JSON. This means that HTML construction takes place on the server side, where SQL is available.
This is in contrast with traditional SPA libraries such as React, which typically access data via JSON APIs and construct a user interface on the client side. You can't make SQL generally available on the client side due to the obvious security issues, but projects like GraphQL have attempted to make the client side more flexible. Unfortunately I believe there is an inherent trade off with client-side data access that I outline here: https://intercoolerjs.org/2016/02/17/api-churn-vs-security.h...
So, as developers rediscover hypermedia & hypermedia oriented libraries, they will suddenly have access to SQL again.
And, as I mention above, new technologies like React Server Components, by putting evaluation on the server, also make SQL more easily accessible for developers.
Why do people even reinvent this wheel every few months? Does the <1KB size even matter with modern caches and HTTP2? Does the amount of written lines of code matter when there's modern linters and tooling?
Anyone can build a "reactive" type framework by following tutorials online now, they're super in vogue.
Is my cynicism here warranted, or am I just jaded from 20 years of watching pendulums swing left and right and watching the wheel be reinvented over and over?
You're jaded. Look at this as someone completing the exercise to understand reactive frameworks by implementing a toy implementation. Like when someone implements yet another lisp. Maybe you disagree with it getting to front page, but then don't upvote & move on. There'll always be some amount of front page content someone considers crap & it's best if we don't collectively fill every comment thread disparaging about it
For privacy reasons, resources are no longer cached across origins, so the size does matter (though arguably 1KB more or less makes absolutely no difference on any webpage that has a medium-sized image, especially if you have SSR for the first paint).
But the better reason why these projects exist is for experimentation and iteration. It's not like everyone who uses React will switch to this over the holidays, but maybe in five years some of the ideas in here will become more mainstream, and a future version of React (or a different framework) may adopt them.
Because it's a different threat model: Separating caches per-origin prevents a site A from seeing what resources you requested on site B.
But something like Decentraleyes prevents site A from seeing what resources you requested on site A.
(Or rather, whichever CDN provider site A is using.)
You could have both at the same time, but they are orthogonal. As for why it's not in browsers, assuming good intent, I'd think it's because it requires you to bundle a whole lot of libraries with the browser for it to be useful as a local CDN. If browser vendors decided which JS frameworks are bundled with the download and which ones are not, I'm not sure if that would help decentralisation!
I think your cynicism is warranted for you. Like if you're not looking for a new framework and you are interested in the new, shiny JS refactor, don't bother. I live a happy life, using the same framework and never looking at all the other stuff.
But at one point our big contenders were also shiny and new, and I am glad someone less cynical than me was willing to put them to the test.
The amount of code matters when the lowest-performing Androids on the market have an order of magnitude less single core performance than a modern iOS device. V8 parse times have got much better over the last few years (they used to be a big bottleneck) but you’ve still got major execution cost leading to bad user experience.
The code size is a poor proxy for performance though. React likely has some areas which are much more performant just because of development efforts, even if it's larger. If we want performance, that's the metric that should be public and clear.
>Does the amount of written lines of code matter when there's modern linters and tooling?
So long as JavaScript is interpreted it matters a whole lot on mobile devices.
The amount of code delivered and executed on the device has a huge bearing on performance on lower end devices. Unless you're on some $1000+ phone and arguing from a place of privilege.
Let them reinvent it. You are not required to learn it right now. If it really manages to become widely used you can learn it then. If not well the guy is spending his own time on doing something he likes.
Except... the huge amount is photos and fonts and whatnot. As you can see on the vanjs size, the biggest framework Angular weights 85 kB and it will be cached.
Compared to what Angular also brings in functionality, i don't see size of the framework as an argument anymore.
Consider Hackernews:
hn.js comes with 21,4 kB.
The Y logo on the upper left is a 46,32 kB SVG!
What should i care about 1kB minimal framework or 85kB all-included framework?
Skillset, maintenance burden, compatibility matter.
People feel unsolved problem for them and want a better solution for them individually. As you said “anyone can” so “anyone will”. Just ignore posts like this ;). After 20 years of experience just pay attention to v1 of anything :)
The problem is not size. The problem is installation, configuration, dependencies, transpilation, IDE setup, etc. And here you have the plain old notepad with browser - nothing else...
I haven't seen the documentary, but my anecdotal experience visiting SF annually since 2016 for work is that it's utterly dire.
I live in northern europe, in Germany, so our bar is high, quality of life is good, but i'm no snowflake prude, around Market Street in San Francisco is simply disgraceful.
I witnessed on every trip passers by being harassed sexually by mentally unstable, or drug abusing people. I was offered to buy a stolen gun in broad daylight a block over from the Twitter building. I saw a gang of people storm a hair salon on Market St. and attack the occupants, spilling out into a 10 person brawl on the street. I've seen people jumping turnstyles and being assaulted by police/security personnel.
I cannot speak about SF as I have no experience there; but as an American with a lot of recent experience in Netherlands and recent but less lengthy experience in Germany, I have been surprised by how bad the homeless/mentally-ill/drugged-out situation is around train stations in Germany compared to the Netherlands.
It would be expected to encounter such people in the biggest city (Berlin), but I also saw it in half a dozen other cities I spent some time in. It was very confronting and very uncomfortable as I would have compassion on mentally ill or otherwise "hard luck" people, but in some cases there was real risk of aggression. At the very least, I couldn't wait (for a train) outside a station because of the very loud yelling (at invisible enemies) that some of the people would do.
I asked a couple of Germans about this situation, and they said that while there are social services and mental health services available, the state seems to have a problem keeping up with the mentally unstable people. The people will get some time in help but then scatter to the wind, revert to their drug use, and turn up outside a station somewhere (where they will remain, day after day, for some period of time).
I wonder why this seems to be much more of a problem in Germany compared to NL. Perhaps it's just a matter of population scale? General way of life and social services aren't so different between the neighboring countries.
Note that market street around the Twitter building has never been a great area of SF. I think part of the hope was that it would re-vitalize that part a bit. Moving around SF is weird because the difference from street to street can be huge.
I didn't live in SF, but I flew there several times a year for over a decade. Market Street definitely saw a huge decline over that period. By the end, coworkers were refusing to walk it anymore for safety reasons.
> I live in northern europe, in Germany, so our bar is high,
I think seeing western European countries, and more specifically northern ones, should make the Americans ask themselves if something is wrong here. And probably these should be deeper than "how is it possible this happens in the richest country in the world" that I have heard so many times.
Income inequality typically tracks with crime. Of course, policing and criminal penalties are a factor as well, but income inequality is likely primary driver of crime. If so, then it's no surprise the US is worse than Germany.
People generally do not behave as criminals when they have reasonable opportunities to spend their energy in return for a livable wage and relatively comfortable, safe housing. And there are many, many examples of zones in the US where there is effectively no economic opportunity nor safe housing opportunities.
That said, lack of police presence and especially lack of penalties does seem to encourage bad behavior (amongst people who find bad behavior as their best economic activity). The laws and policing have to keep up with the times and situation. Obviously SF cannot solve California's (or the US's) income disparity problem. So even if it were to up the police presence and make stiffer penalties, it wouldn't have the infrastructure to process and imprison the large numbers of people (coming from other cities) who are committing crimes there.
Therefore, it takes a more holistic approach and a number of years to reverse these negative trends. And given the state of US polities, I don't see any real chance for progress for some times (at least until a whole generation of voters die off).
Meanwhile, if you look closely at Europe, you'll notice that politics is shifting and income inequality is increasing. Basically many European states are gradually following the US model. We know where that will lead them.
So even if it were to up the police presence and make stiffer penalties, it wouldn't have the infrastructure to process and imprison the large numbers of people
Rubber hoses and a free ride to the city limits don’t require infrastructure and were an effective solution for decades before progressives took power.
Over the last decade, income disparity has increased dramatically (and correspondingly, cost of living and housing). The poorest 10% barely saw an increase in income, before considering the negative impact of inflation. The top 10% saw their income almost double during the same period. And since much of this had to do with high tech companies setting up shop in an already-full region, cost of housing went up dramatically.
One might ask why all these companies moved into SF, especially into areas known to have more "progressive" leadership, but that's a different topic.
As for rubber hoses, that would be met by large numbers of angry people - many of whom would arm themselves in some way (including guns). Would you then propose just firing live ammunition into crowds as a solution? These types of solutions are like cutting off a limb because of a skin rash; usually that's not the right answer. If you think street drug people are bad for business, just imagine frequent street gun battles.
And driving the people to the city limits and dumping them? We already have evidence that the more organized property criminals are driving in from outside the city. Obviously they can't afford to live in the city anyway.
What technology did you use for the animations? I've a bunch of itches I'd like to scratch that would be improved by having some canvas animated explainers or UI but I never clicked with anything. D3 back in the day.
A rudimentary look in the source code showed a <traffic-simulation/> element but I'm not up to date enough with web standards to guess where to look for that in your JS bundle to guess at the framework!
I've been thinking about creating a separate repo to house the source code of posts I've finished so people can see it. I don't like all the bundling and minification but sadly it serves a very real purpose to the end user experience (faster load speeds on slow connections).
Until then feel free to email me (you'll find my address at the bottom of my site) and I'd be happy to share a zip of this post with you.
Postman, since they raised money have really lost their way in my opinion. The tool gets harder to use, with a more cluttered UI in every release. Seemingly random UI decisions make it awful to use.
Glad to see competition in the space, but I doubt that Kreya can claim to be a "postman alternative" unless it has 75% feature parity with Postman, simply because the range of ways people use Postman is so broad, that it's an unverifiable claim.
Unless Kreya can do teams, testing, scripting, sharing, reviews, forking, publishing secret-link API docs, generating example API code out of the docs in Ruby/Python/etc, it certainly isn't an _alternative_ to Postman for my team's use-cases.
As part of a team of maintainers of a popular (declining) gem, shame they don't make a mention of the extremely valid "gem is owned by a team, and anyone may push" model. I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar.
seems like the post you're replying to had already answered your question, in its second sentence:
> I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar.
"> I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar."
Emphasis mine. How does "the extremely valid "gem is owned by a team, and anyone may push" model" impact this in any way? Why would the MFA tokens need to be shared via 1Password if they are specific to an individual account?
Unless you're sharing the username/password for a master account between everyone with push access to the gem (which, I checked, Capistrano thankfully doesn't appear to be doing), there's no reason whatsover to share the MFA token, so it could happily exist on a separate device. And if you are sharing one username/password between everybody – don't do that. You don't need to do that to accomplish "the extremely valid "gem is owned by a team, and anyone may push" model". That's just a really stupid way to do anything.
GP seems to be thinking that everyone with push rights needs to share the same token, but that's simply incorrect.
As others have mentioned, such gems should have shared maintainership across multiple accounts (each with their own creds and MFA) as opposed to shared creds and MFA.
I'm having trouble parsing your post. You can add multiple owners to a gem. You can also disable 2FA for API access on a per-account basis (though it isn't recommended) for a CI runner--which, tbh, is how a popular gem should be being published. What's the objection here?
Had you taken the time to open the link, the 2nd paragraph states their capabilities succinctly:
> Parcel CSS has significantly better performance than existing tools, while also improving minification quality. In addition to minification, Parcel CSS handles compiling CSS modules, tree shaking, automatically adding and removing vendor prefixes for your browser targets, and transpiling modern CSS features like nesting, logical properties, level 4 color syntax, and much more.
I've obviously read that. Most of those features are what we used to call CSS pre-processors, but I'll happily call that compilation if that's a thing now.
>Much like Notion and other block editing methods, site content is represented in a JSON format. Each block has a type, for example, a block of Paragraph would have the type "Paragraph" and would be represented by {"type":"paragraph", "text": "Hello World"}, and an image would have the type "Image" represented by {"type":"image", "url":"http://placekitten.com/200/300"}. A page consists of an array of blocks representing the blocks in the page. A page that consists of a Heading, a Paragraph, and an Image would be represented by an array of maps with types “heading”, “paragraph”, and “image” respectively. A block can also have children. For example, a block of type “Container” may have 3 children of “Paragraph” blocks. It’s very similar to the DOM structure.
Why not make a DOM Editor then with virtual components? The JSON<>React serialization doesn't seem to offer much value, unless it's purely mechanical.
I don't mean to detract from the praise your product is getting here, but I'm really curious about those motivations if you have time to answer my query in amongst the other more excited threads, I'd be glad to understand what the trade-off buys you?
I'm not sure I can visualize what you mean by a DOM Editor, would love it if you can expand on that.
The JSON format allows us to only specify the main type/value of each block, while giving full flexibility on how to render them. I think there are several approaches to rich text editing out there, we picked this one because it seemed to be the most flexible and portable, as we need to invent our own types of standard "blocks", like columns, containers, etc.
Not sure if this answers your question though, happy to go deeper if you have more thoughts on it.
Is this a joke? Ask any mobile or desktop app developer (people who program UIs in a non-broken platform) how they think about having state inside the views.
Only on the web there exist people who hack around for so long they actually believe the hack is the right way.
His point, stated with a bit too much ad hominem, is that with such a serialization you can scaffold entire dynamic web apps which can include form submission where the form dynamically updates based on rules & current state, uses a configurable method, and more, whereas DOM is inherently a "view" and has no concept of state
> It’s no secret that the Ethereum login will soon become a user standard and passwords will no longer be needed.
That's some serious kool-aid that the author has been drinking.
Nothing worthwhile in the article, users will be asked in a popup to sign a message they don't understand and will click-through anyway, and this hyperbole is applicable anyway only to dApps on Ethereum.
The best alternative to JWTs looked like it was going to be https://tools.ietf.org/id/draft-paragon-paseto-rfc-00.html but the reference implementation and RFC have gone quiet, and these days JWTs are basically OK, the security problems are largely solved by more sensible defaults in most of the common language implementations.
It's not Europol's role to push for this, and the European commission has suffered setbacks with ChatControl and other measures already since that time with excellent politicians such as Patrick Breyer doing an outstanding job of informing about and advocating for privacy.
- https://www.patrick-breyer.de/en/chat-control-eu-ombudsman-c... [Feb 2025 criticism of the "revolving door" and more context about how this is received] - an excellent resource overall curated by Mr. Breyer about Chat Control, it's advocates, sponsors, the due-process, alternatives and more https://www.patrick-breyer.de/en/posts/chat-control/