Nothing is foolproof. But I have far more trust that the police in the Netherlands will make reasonable choices with private data than a US for-profit surveillance company. In a functioning democracy, the police are kept honest via voters. Flock is only beholden to their investors, and their bottom line.
Sure, but I don't think we can make the Netherlands police in charge of our largest surveillance network.
Flock is despicable but after all the documented abuses of the system (assuming you don't accept that the entire system is an abuse) were enacted by cops (read: public officials).
I don't think a law making only ICE/FBI/etc able to access the data will do much to slow the rapid expansion of the surveillance state
Believe me, I’m as opposed to this all as you, but playing steelman for a possible solution if it really is helpful to law enforcement and civil society to have these cameras…
What if you made the data only recorded for flagged license plates, for example? Where all information is discarded at the camera-level (not even sent to remote servers) unless it matches a specific target given by police with an expiration date, with an audit trail for every entry, and manual blind-solution human review to confirm any matches before an event is even recorded
Nah. Malloc’s return type is a pointer. The memory pointed to by a malloc call is untyped. But the return type isn’t void. It’s void*, aka a pointer to unknown.
I’m mostly happy with implicit casts from void* to int* or something. But in this code example, we see an implicit cast from void* to int, casting the pointer itself into a number that might not even fit the pointer. This is rarely what you want. I’d much rather explicit casts in this case.
My understanding is that C has a different understanding of the word warning than other languages. Such as in "stern warning" or "warning: the building will collapse if you take that brick out".
This is a philosophical problem. C has false positives to the question: "Is that a program", and some people find that to be idiotic (I don't, this is why I like C). But this becomes really logical, when you have in mind, that the point is that you do not want to have false negatives.
> React is a relatively well-designed library that isn't really that bloated.
I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior. But it leaves the question of why react is still so popular. I think the biggest reason is all the non-technical aspects of react:
- They have excellent documentation. And have, from day 1.
- They produced videos, sample projects, and all sorts of "getting started" documentation.
- They ran react conferences, teaching everyone who would listen about "1 way data flows" and pretending like they invented FP.
The amount of hype around it made it really feel like the next big thing. Between the very well funded react team and the outside developer community, there was real momentum. People learned it in droves. Taught students. Built websites with it. When react's poor design choices caused issues (and there were a lot of issues), then you were blamed for holding it wrong. (Component classes, state, CSS, hooks, webpack and babel taking ages, big bundle sizes, slow re-renders, and so on.)
By the time the next generation of JS frameworks broke onto the scene, there was a collective moan from the community. "Oh no, not again - we just relearned how to make websites." React was the wave, and in its wake we all had Framework fatigue.
Software doesn't get popular without a lot of work by dedicated people. I really admire the work standards bodies do. But they rarely bother to take the time to produce documentation, videos, tutorials, starter projects, blogs and podcasts and all the rest of that work.
More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary. The creator of React, Jordan Walke, was big into OCaml and one might even say he got some of the ideas of React through working in OCaml, so much so that he tried to bridge both by making ReasonML which is an alternative syntax for OCaml which has JSX and React bindings.
Yeah, there's a lot of people who have either forgotten or never knew that the context React came into was a world full of JQuery and AngularJS two-way bindings. I started my internet touching career having to work on that stuff, and boy, so much of it was a nightmare that just got endless workarounds heaped on top for basic performance issues, let alone other complications.
> More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary.
It doesn't seem all that different from doing your rendering in the WM_PAINT handler, which was already how things were done in the ancient Win32 API (although it's possible [0] to draw outside WM_PAINT).
The web root is a document platform. Every major GUI library have a “paint” or “draw” function you have to overload for custom widgets. And there is always mostly two kind of widgets: actual visible components and others that are responsible for layouts.
There really isn't anything in react that is inherently "bloated", most companies were indeed using it wrong, or at least in a naive way. Over-reliance on useEffects, re-render issues, non-memoized components etc. When used correctly, react 18 provides really fast web apps on whatever scale (small one pager app to massive enterprise apps).
React is very similar to PHP in this regard. PHP has (had?) several major design flaws, and yet it became the default for people with less experience.
I don't think that React is as problematic as PHP ever was, and also frameworks like Laravel have improved the PHP experience tremendously, so there is now a way for less experienced people to use it.
IMO: the problem here is pretending that everyone has an innate right to use React right when it's clearly a library that works better when people have a bit more experience than the average web dev.
We as an industry tell people "don't do your own crypto, it's hard to get it right". We don't blame crypto for being hard, or demand new frameworks. Same for things like assembly, C++, Rust, formal proofs, writing an OS, operating BGP infrastructure, etc.
But with React it has to be "kid gloves on", otherwise it's shit?
This is perhaps a bigger problem in our industry: lack of experience is not seem as an individual problem, and we blame-shift, blame marketing, blame Facebook, Dan Abramov, trends...
Perhaps we should be saying "React is not for beginners", same as "don't do crypto".
Web dev is special. The industry has spent the last 20 years sacrificing almost everything to make building web sites more beginner friendly. There is an expectation that the "full-stack" (everything between node and react) should be effortless, that is absent from other fields. "one click to deploy" in not a thing in crypto, in embedded or in kernel dev, for instance; whereas it's expected that a junior web dev is productive from day one. That's just normal industrialization, specializing jobs and then making them simpler, starting where the numbers are larger.
Ironically, piling up simplistic technologies have created quite complex houses of cards in places. HTTP itself being the most obvious example of a tech meant to be simple and quick to grasp that morphed into a super complex, ineficient and insecure gremlin of which nobody who is not a specialist (or an AI) has a full picture anymore.
Nobody I ever worked with ever said anything even remotely close to that first paragraph.
"Full stack should be effortless"? What? This is definitely not coming from anyone other than two groups: random HN people with an axe to grind, or people trying to diminish the value of the profession.
Hiring for web is difficult, salaries are historically good, people complain about complexities, including yourself: "quite complex", "super complex", "nobody has a full picture".
Nevertheless: React proves that it's not effortless. There are complexities in there and kicking and screaming saying "it was supposed to be easy!!!" won't change the situation.
"It should be simple" yeah Crypto should be simple as well, so there are no bugs. But it's not.
My management didn’t say it explicitly, but did so through their actions.
A self-service portal was created internally. Every infrastructure team was expected to make services available via this new portal. Timelines were tight, primary jobs were still expected to be done, and the chief architect on the project said creating the API only takes 10 minutes.
To onboard and use this self-service portal, these teams (many of which who didn’t have a single developer, but rather sys admins) were expected to leverage Flask, React, an internal component library (3 conflicting ones with poor documentation which tweaked inputs from 3rd party components and required spelunking into the code to find how to use them), and very strict rules around the Flask API… all in managed repos that required approvals for PRs from a non-responsive team.
This was supposed to be a little week-long side project for a bunch of non-developers, with no training, insufficient documentation, and little support by the person who built the portal.
Needless to say, the project is now dead, but it took about 3 years. During those 3 years, the ideas that “full-stack should be effortless” was the prevailing view, and that anyone off the street should be able to effortlessly plug into the framework that was created.
> Nobody I ever worked with ever said anything even remotely close to that first paragraph.
No, they’re correct. Many people in the web dev community spent a couple of decades there obsessed with being beginner friendly. For example, “Anyone can learn to code”. We pushed back against anything perceived as gate keeping. There was general assembly and other coding bootcamps, to teach beginners web dev. And a million beginner videos. Web dev events at the time were full of beginners. I remember a show of hands once at SydJS. 70% of people in the room had been programming for a year or less. I stopped going, because speakers started catering to the audience.
Other areas of programming aren’t like this. Nobody runs 12 week coding bootcamps to teach complete beginners to build operating systems. It’s accepted you shouldn’t roll your own crypto. And we tell beginners to use Postgres, not roll their own database.
I’m not saying it’s a good or a bad thing. But it was definitely a thing.
> We don't blame crypto for being hard, or demand new frameworks
This is not true. There are innumerable cryptography libraries whose primary reason for existence was to replace or offer an alternative to a library with the same affordances but with primitives that were too easy to use incorrectly. “Maybe we should redesign this knife so it’s hard to slice a finger off” is not unique to web dev
> If everyone is using react wrong, react has a design flaw.
You're asserting that everyone is using it wrong. It's your personal opinion, and a baseless one at that which is based on a personal belief that everyone around you is incompetent and incapable of critical reasoning. It's silly posturing.
In the meantime, React is by far the most popular web framework in production. Some surveys list React with a market share of between 60-75% of all web frontend projects. It's so popular that it even leaked into GUI programming with native GUI toolkits.
It's rather obvious that assertions such as yours are detached from reality. Naturally the dominant framework will also dominate the number of newbies taking their first steps as well as drive-bys. It's also natural that the dominant framework will be targeted by the "aktually" crowd, invested in contrarian self-promotioj comments instead of doing anything constructive.
But to assume everyone is incapable of using something... That takes a lot of self delusion.
> based on a personal belief that everyone around you is incompetent and incapable of critical reasoning.
This is all news to me. I don’t think any of that. Do you make a habit of writing fanfic about other people? You also seem upset that I used word “everyone”. I thought my exaggeration was obvious. How embarrassing for us both.
If you want to make any technical arguments in support of react, I’m all ears. The only argument I can find in your comment is that react is popular right now. But that doesn’t mean react can’t be improved upon. Jquery was once that popular. Then react displaced it, by being better. Soon react will be displaced in turn, by a library which addresses react’s flaws. I can’t wait.
> This is all news to me. I don’t think any of that. Do you make a habit of writing fanfic about other people?
Pointing out the absurdity of someone like you throwing blanket accusations of incompetence is something that's very specific and verifiable. If you have strong feelings about making broad accusations about whole communities, you should pause and pay attention to what you are saying.
> If you want to make any technical arguments in support of react, I’m all ears.
Would you listen? I mean, the main issue with your post is the way you throw absurd blanket statements about a technology, on how either everyone using it is incompetent or the framework is somehow broken.
I mean, does it even dawn upon you that maybe perhaps throughout the past decade there might be people using the dominant framework well, and happen to know what they are doing?
It seems not, by the way you opt to disregard it and tell yourself no, everyone is either incompetent or the tool is broken.
Do you understand the absurdity of this sort of claim? Because it isn't even about React, but the way you feel it's reasonable to throw such blanket accusations.
> But that doesn’t mean react can’t be improved upon.
But that's not the claim you made, was it? Do you need me to quote you back at you?
> If everyone is using react wrong, react has a design flaw. Other frameworks aren't slow by default.
The claim that react is frequently misused was from the parent comment, not me. If you read it, you’ll see I’m explicitly not blaming react devs. I’m blaming react. Vdom diffing makes websites slow by default. And it is totally unnecessary.
Most of your comment is a big ad hominem attack. To answer your explicit question, yes I would find a technical argument much more convincing than a list of made up character flaws. Especially from a stranger, based on a two sentence comment. What a waste of time.
For what it’s worth, I don’t go around thinking everyone around me is an idiot. But your comment does get me thinking.
"You're asserting that everyone is using it wrong. It's your personal opinion, and a baseless one at that"
Their comment does not assert that. They are responding to someone else's assertion, and turning it around to make a completely different point. It's a common form of argument - "if you're saying that the problem is everyone's getting it wrong, then I disagree and the problem must be something else."
Basically the exact same point that you are using to launch a stream of insults!
Saying that it is "silly", "detached from reality" and "delusional" for making assumptions about folk is the most incredible self-own.
If most people can’t use it properly perhaps the problem is in react itself and not most people. React is the only framework that will blame the user for its own mistakes.
I have to step in here to say that, at least documentation wise, this is revisionist history.
The original react documentation is fine, but focused almost entirely on class components. What was there on hooks was either outdated or outright harmful.
It's not until 2023, 4 years after react hooks launched, that the new react docs which focused on them were released.
Yes, the original documentation is what I’m talking about. That documentation was not outdated when it was written. It was excellent compared to the standard at the time. The react doc site raised the bar for what we expect from web framework documentation.
Hooks came much later, long after react was already popular.
> I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior.
I don't really think that React is necessarily the best possible library, but there is certainly more to a UI library than simply compiling out the need for diffing. For one thing, I find JSX to be a relatively unobtrusive addition to the language. It is implemented by a variety of things and is a pretty simple transform as far as things go; basically pure sugar, it's possible to avoid it if you want. It could be better designed than it is, but I think it's at least sufficiently general - it is feasible to say, use an alternate library with JSX, like Preact.
Svelte on the other hand by its nature just simply requires a more complicated compiler step to work and deliver on its promises. That's a trade-off. Whether you think it's worth it is up to you, but presenting it as an objectively technically superior design is disingenuous. Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?
> The amount of hype around it made it really feel like the next big thing.
We are a really long way away from the hype of React. I would argue that hype stopped carrying React a long time ago. Momentum? Sure, but if something was truly dramatically better, then I think it would have a fair shake at beating out React.
The problem is that the web isn't microbenchmarks and developer experience does matter to some degree, so the trade-offs that seem so good on paper don't always pan out.
I'm not a hater of Svelte. On paper, it is a very elegant idea. However, when I actually tried to use it, I genuinely came out feeling that it was simply not for me, and the benefits it has are not enticing enough for me to continue experimenting. My React apps are not particularly slow or bad at handling huge amounts of data. (One of my apps has no problem handling a file grid of over 1 million items, and in fact, I run into issues with browsers not being able to handle a large enough scroll area long before performance of my React code is a problem. That is good enough for me.)
I should probably be more balanced when criticising react. React moved the state of the art forward when it came out. Compared to the other options we had at the time, it was excellent. But it's not better now. At least not for technical reasons.
> Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?
Virtual dom diffing is pure overhead. It increases the JS bundle size (react is big). Vdom diffing is really slow. And it's simply not necessary.
I agree that if you make heavy use of comparator functions, react apps can feel ok to use. But most sites don't do that. Look at the new reddit site. Insanely slow and insanely inefficient. They've improved it a lot since the new design landed. But it's still 19mb of javascript or something, and much slower than it should be. Maybe reddit is only slow because they're holding react wrong. But if everyone holds react wrong, it's react's fault.
If you don't like the asthetics of svelte, check out SolidJS. Solid is aesthetically almost identical to react. Solid - like react - only needs compilation if you're using jsx. The difference between solid and react is that solid only executes component functions once. Reactivity is implemented via fine-grained signals. Solidjs apps perform better, because there's no vdom. The default way to use solid is already fast.
> if something was truly dramatically better, then I think it would have a fair shake at beating out React.
Eh. Lots of old technologies are still in use. Most software engineers don't enjoy learning new frameworks every few years. And react still works fine, even if there are other options today. I think solid and svelte are better, but they might not be better enough to displace react for the average web developer.
If you like react, give solidjs a try. It's essentially "react with signals", which I find to be a significant improvement. You get much smaller JS bundles, better performance and better state management. All while keeping a lot of the best parts of react's design philosophy. It's great.
React has an incredible ecosystem, it's almost synonymous with web development. The available render backends alone, namely React Native, are currently unbeaten.
As interested as I may be in the alternatives, they simply don't have this.
I don't think React pretended like they've invented FP, and I've always heard them be pretty open about FRP work existing in the past and them leaning on it.
I mean, prior to React the big Framework at the time was AngularJS 1 - a hellscape of two way data binding.
Talking about one-way data flows was an excellent way to speak to a lot of tortured souls at the time (who had just found out they were going to be forced to migrate their projects to something else anyway due to Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").
The first time my team uses AngularJS professionally, we spent a month to learn the framework, then the velocity and quality were good. The client reported a funny "bug" that the loading icon didn't show, it turned out the async request was too fast that they couldn't see to loading, a fresh experience for them at the time.
> Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").
Angular 2 came out in 2016, without the two way binding design issues of AngularJS. Google ended support for AngularJS on Dec 31 2021, so there was 5 years of overlap between the two. They even had migration paths that allowed AngularJS and Angular 2 application code to live together from the initial release of Angular 2.
I haven’t found a front end library I like more than React except maybe Astro.
I didn’t really like Svelte and I am pretty opposed to htmx. It is certainly better than Angular and Vue, though Vue 3 is tolerable. Maybe there are more popular options nowadays but tbh I am not really looking to move from React. I have zero complaints other than maybe the push towards server rendering and partnering with Next.js
React is simple and I like that it feels a bit like FP. I love that I can write just about my entire application in TypeScript with all of the benefits that incurs. It requires some knowledge/discipline e.g. around useEffect.
If you care to use native browser APIs and features you can have lightweight, performant applications that behave well in the browser.
Most devs don’t do this, even with vibe coding. It’s a very easy way to filter for those who care about what they are building.
Our software is already malleable in a bunch of ways: APIs, integrations, extensions, plugins and compatible formats (eg lots of programs can edit a .md file). But all of this stuff is special-cased. Every program that wants to read a .psd has to write its own - probably buggy - parser. I can't just take the data in application A as JSON - at least not without claude. And I can't connect applications A and B and have them bidirectionally sync except with hacky scripts which will break in lots of situations.
Yeah. Sites like GitHub pay a lot of money every month for servers. At scale, a bit of performance work can save you millions on your bills. And make your site run faster for users at the same time.
To be really clear, the performance of GitHub’s website has basically always been terrible. I don’t know why. It has bothered be forever. And it’s weird - GitHub doesn’t actually render much content. But it often takes seconds to load that tiny bit of content. I often clone entire repos locally rather than browse them on GitHub just so I don’t have to wait for their webpage.
To continue the comparison, cyberpunk can render night city in 16ms. Which makes me embarassed for GitHub that they can’t render a list of files and a static markdown readme in under a second.
I would push back on that. It used to be less terrible before they made it all SPA. Now there are all sorts of broken-caching tricks that try to do in-place reloads. I frequently see progress bars incrementing while it is attempt to do a request - while that original redraw is attempting to happen, I can frequently launch a new tab with the same link that will finish rendering before the original.
Hyperbolic to be sure, but I think it’s fairly common for people to get into programming for fun as a teenager, turn that into a well-paid job, realize that programming jobs are often entirely different from programming as a hobby, then feel trapped because all the experience they have is in programming, and finding an alternative starts to look like competing with recent college grads for entry-level office jobs (ask a 22 year old how that’s looking these days), an expensive degree, or something menial for $15/hour or less.
First world problems, perhaps, but also a microcosm of our broader societal divergence, where a reasonably comfortable middle is increasingly being replaced by growing working and upper-income classes, with very different lifestyles.
Programming jobs differ wildly though. Working as a solutions architect is different from working at a startup, or a big corporate, or a company making video games, or a big tech company like google.
If you love programming but hate working at your current programming job, the problem might be the company.
Sometimes you gotta do things that others don’t value highly. A long career needs you to act with good judgment. Even - sometimes - when the optics are bad.
Me too! Though I never learned how to use functions (subroutines) until I picked up C from a book later on. I still have dozens of programs I wrote back in the day in qbasic, largely based off the examples in the help system.
reply