I think the Spacecraft Interfaces section (starting page 84) is the bit that might interest HN readers. It describes (to potential customers) the dimensions of the payload bay, electrical and comms interfaces available, conditions the payload must be able to tolerate (vibration, temperature etc).
I assume you consider this a bad solution because the free market would always converge on the right solution(s), including reparable machines.
However, if all participants (in this case manufacturers) in a market conclude that:
(1) product B has a lower profit margin than product A, and
(2) product B is superior enough to eventually become the dominant variant and
(3) the market size is fairly static and
(4) the first mover on product B is unlikely to maintain a lead for very long,
then all participants would choose to suppess product B, even without having to resort to collusion.
Not only that, if the manufacturers consider regulation to be a market in its own right, i.e. it is available for purchase (which it de facto is in countries where lobbying is legal), then market forces will also drive regulation away from product B.
To me, this explains why some products peak in build quality sometime after innovation plateaus, and the continue to diminish over time (usually measured in decades). Some household appliances have already reached this stage. For Apple products, this phenomenon may still be in the future.
I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That introduced state management. It was all downhill from there (starting with two way data binding, Flux architecture, Redux, state vs. props, sagas, prop drilling, hooks, context API, stateful components vs. stateless components, immutability, shallow copy vs. deep copy, so on and so forth).
Absolutely. Look at facebook today. Back in 2010, everything had just the right amount of interactivity. Because, separation of concerns existed at the language level - HTML for structure and CSS for presentation, JS for everything else.
Then some bunch of geniuses decided it would be awesome to put everything together in the name of components. Today, you open facebook, the creators of React - normal drop-down with just a list of barely 5-6 items is a fucking component that makes 10 different requests. I would even argue this unnecessary forced interactivity is what perhaps annoyed users the most as everything always has to "load" with a spinner to the point of the platform being unusable.
Same goes for instagram. It's not just that, React is a hot ball of mess. It's not opinionated, so anyone can use anything to do anything. This means if you work with multiple teams, each one uses their own code organisation, state management library and general coding paradigm. Eventually the engineers leave and the new guy decides to do things his own way. I've honestly never seen a company with a great product run over React. Everything always is being re-written, migrated every 3 weeks or straight up is buggy or doesn't work.
React is the worst thing to happen to the Javascript ecosystem. The idea is good, but the execution is just piss poor. I mean look at Vue and Svelte, they managed to do it right.
If the html+css+js trifecta was any good for creating UI beyond simple forms, we would not have witnessed the cambrian explosion of ways to do it differently. Reactivity itself was an answer to the pain of using MVC and similar approaches in older GUI toolkits not made for the web. The pain did not stop entirely, of course, because GUI is a complicated and ill defined problem - but I don’t look back fondly to programming without it.
React got popular not because of its amazing time-tested ideas (everyone knows they re-engineer everything once every couple years!), but, strictly speaking, because at the time it was released there wasn't any kind of serious SPA or partially-SPA framework for the web and also because JavaScript sucked a lot more at the time (no classes!). Qite is perfectly suitable for complex UIs thanks to its state functionality, you can build pretty complex functionality and UI and not sacrifice user's CPU in the process.
What makes React fundamentally worse than Vue or Svelte? In my experience, there are also plenty of crappy Vue-based sites and applications and I'm sure the same is true for Svelte.
> Today, you open facebook, the creators of React - normal drop-down with just a list of barely 5-6 items is a fucking component that makes 10 different requests. I would even argue this unnecessary forced interactivity is what perhaps annoyed users the most as everything always has to "load" with a spinner to the point of the platform being unusable.
That's a design decision, though. Sure, your point is basically that React is not opinionated enough and allows you to do anything. But in the same way you could criticize JavaScript or Python because they allow you to do "anything" and some people write shitty code.
> React is the worst thing to happen to the Javascript ecosystem. The idea is good, but the execution is just piss poor. I mean look at Vue and Svelte, they managed to do it right.
As a previously big React dev I agree 100%. If anyone feels this way please spend some time on doing Sveltekit project (e.g. rewrite a personal React project).
I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forward: the game has state. The master Render() function draws all of the graphics according to the current state, called at framerate times per second. Nothing in Render() can change the state of the program. The program can be run headlessly with Render() pre-processed out completely. The mental model is so easy to work with. There is a sleep-management routine to save on CPU usage when idle, and dirty logic to avoid re-drawing static content constantly. I feel like the world would save 90% of its GUI development time if it didn't do whatever the fuck reactive UIs are doing.
That is immediate-mode graphics. Fine when you are already power-budgeted for 60 frames each second. UIs typically use retained-mode graphics, with persisting regions.
Games do not sync data, they literally say what should be drawn on the screen, from scratch, 60+ times per second. They are in control of the entire process. They do not need to deal with DOM manipulation overhead because there is no DOM.
Yes, in web to always draw from scratch, it would be slow, therefore exists reactive UI, so people can program like drawing from scratch but less slow.
Well, in React specifically, you're describing the Flux architecture, which I've implemented manually back in the day. Its modern-day successor is Redux, which does exactly what you describe, but we found that it introduced more complexity rather than remove it.
I don't know about the other UIs, but on the web, some things impinge on the model you (and Redux) are proposing.
One thing is: you, in the gamedev world, have the luxury of having a frame buffer to write to. You fully control what gets rendered. Unfortunately, React and its cousins all have to deal with the idiosyncracies of the legacy browser environment. You have CSS, which applies and cascades styles to elements and their children in often non-obvious ways, and is a monster to deal with on any given day.
In addition to CSS, you have multiple potential sources of state. Every HTML slider, dropdown, input field, accordion, radio button, checkbox has its own browser-native state. You have to control for that.
On top of all of this, the browser application is usually just a frontend client that has to interact with a backend server, with asynchronous calls that require wait-state and failure-state management.
One thing that's in common with all of the above problems is: they're localized. All of these things I'm describing are specific to the rendering layer and therefore the component layer; they are not related to central state. A central state trying to capture all of these problems will fail, because component state has to be wrangled locally near where the HTML is; CSS also is component-level; and the network states are often very closely related to each component. If we maintain a central "game state", the data complexity just proliferates endlessly for each instance of the component.
So, the default these days is to keep state very close to each component, including network state, and often business logic also gets sucked into the mix. I try to avoid putting business logic in components, but people do it all the time unfortunately. But it does add to the complexity.
In other words, there is -real- complexity here, stemming from the fact that the web was never built to be a distribution+execution layer for rich applications, but evolved to become exactly that. It's not just bad application architecture or bad decisions by React maintainers.
Maybe I'm wrong, since I'm not a game developer and don't see what you're seeing on your side.
I'm sympathetic to "it's the browser's fault", to some degree. I understand that the browser locks you into certain constraints, and I understand that I don't understand much about those constraints, because most of the extent of my experience with web development is using a canvas and a couple of fundamental APIs to render my games via WASM as web is one of my build targets (and I do know that approach is undesirable for regular web pages). I can see how there might be unavoidable complexity there.
What I still don't understand is why the browser is that way in the first place, and why all of the native, not-browser GUI frameworks that people use are also that way. People opt into using React Native, even! But the regular run-of-the-mill frameworks that are widely used for native applications are also annoyingly complex to work with, so much so that I've repurposed my engine for when I want to create native applications and have been working on building a desktop UI framework within it that follows the same model I use for games (albeit nowhere near production-grade, just covering "the cases I need").
> the browser application is usually just a frontend client that has to interact with a backend server
I will note that this is a constraint that is shared with gamedev. Most multiplayer and even many singleplayer games these days are server-based.
This was the case back in the days of the Amiga and 68000 Macs. Rendering everything every frame was impossible, the only way to make it work at all was to draw only what was absolutely necessary to depict changes.
Then computers got faster, much much faster. It became possible to redraw the whole UI from state every frame without it being a significant cost.
At the same time retained user interfaces managed to become more and more costly to do just about anything. I don't think for any particular reason other than computers were fast and they didn't need to do much better.
I find it really odd that there are user interfaces that take longer to rearrange their items than it takes for the same CPU to RayTrace a scene covering the same amount of screen area.
Games can afford the luxury to re-render everyting on every frame. The DOM? Not so much.
This bottleneck could be alleviated if browsers shipped native dom morphing or even some kind of native vdom but we're stuck with userland js solutions.
This made me immediately think of the Elm architecture.
To an extent this is how react works internally. There is a function which takes state and produces UI. In order not to have to re-render the whole UI if only a small part of the state changes, there is a diffing algorithm and "virtual dom" that is diffed against. Maybe it doesn't work exactly like that anymore but that's the gist of it.
Indeed, I genuinely do not. Rather than passive-aggressively insulting my intelligence, why not explain it for me? As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI, so it seems like web developers do in fact want to build immediate-mode UIs, and in fact are constantly complaining about the nightmarish complexity of the status quo.
[1] I loathe this term, by the way. It's one of those terms that, I think, belong to a discipline of developers who love to obfuscate everything, even simple concepts, with unnecessarily opaque terminology until nobody can understand what the hell anyone is talking about anymore.
>As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI
the problem is that the typical modern web page is considered as a combination of immediate-mode and retained-mode.
therefore, as it is wasteful to update all the page when only a few components on the page change, people want to only update parts of the page immediately when changes happen.
furthermore the typical modern web page only makes sense in the context of the modern web site, so some pages are almost everything on the page needs to update all the time, some pages are nothing here needs to update until the user does anything, some pages are nothing here needs to update at all, and other pages are just a couple components need to update all the time based on various things.
This context of what a web site is like is very much determined by the type of the site, where many e-commerce sites are affected by all sorts of data that occur outside of whatever page the user is on and need to update all sorts of different components on a page, many governmental sites are almost just static, with all sorts of variations in between.
I was just responding to the usage that the parent commenter had which was
>As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI
which I interpreted as the only possible meaning, in relation to React, being UI components that must rerender as close to immediately as possible vs. UI components that do not need immediate rerendering when the underlying data has changed.
I realize that is not a particularly correct use of the phrases, but then that is what happens when you use a concept from one type of development metaphorically in another type of development, memetic slippage as it were.
> In immediate mode, the scene (complete object model of the rendering primitives) is retained in the memory space of the client, instead of the graphics library. This implies that in an immediate mode application, the lists of graphical objects to be rendered are kept by the client and are not saved by the graphics library API. The application must re-issue all drawing commands required to describe the entire scene each time a new frame is required, regardless of actual changes.
React is simulating immediate mode by having the developer describe the full rendered result from the current data state. The developer / app code doesn't need to keep track of what changes need to be done to get the browser from its current state to the desired state, React does that for you.
Retained mode is where the developer / app does have to concern itself with the current browser state and issue the desired updates themselves, like how everything was done in the jquery era and earlier.
I am no web developer but whenever I built the UIs, re-rendering a page by doing some big DOM change through JS as always led to stutter. So maybe its just inefficient and can't be optimised.
No horse in this race, but your phrasing seems a bit weird, honestly... If reduced, your comments read as:
"You don't know about X? Well, at least I know about X and Y..." Doesn't seemed like a good faith comment to me either?
And then you say "You misunderstood my intentions so I'm going to disengage". For what it's worth, I didn't interpret your argument as insulting someone, but also it wasn't a useful or productive comment either.
What did you hope to achieve with your comments? Was it simply to state how you know something the other person doesn't? What purpose do you think that serves here?
I guess I misinterpreted your comment? I do apologise if that's the case. I certainly didn't intend to "jump down your throat", I was asking you to explain your comment further because I don't understand what you're getting at.
To be perfectly fair, you accused me of insulting you and said you "loathe" a word which I thought was a fairly inert term of art. Would you believe I didn't actually notice that you wanted me to say more? :) More than happy to give the benefit of the doubt though, the shoe's been on the other foot for me more than once.
For my part, I also loathe the insensate writhing mass of frameworks, patterns and dependencies that is "modern" frontend development. Where you and I differ is I recognize a handful of extremely good ideas hidden in the morass. But I am perfectly happy dismissing the majority of it; if nothing else, you shouldn't come away thinking of me as a React fanboy.
Writing is a lossy medium for thought, and programming is no exception. I'd say at a minimum that you and I are on the side of programmers whose code is a medium for their own thought.
All of these choices really just comes down to cognitive bandwidth, context, domain, taste, any number of things, really. Which is what was behind my first (admittedly terse, slightly salty) comment.
What I condemn is someone who opts out of making choices for themselves in their software. Web dev just happens to have an unfortunately high concentration of this sort of thoughtlessness.
> The master Render() function draws all of the graphics according to the current state
What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source".
React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.
This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.
>components should be simple and not store data in themselves.
That is a ”controlled component” model which is bad for interactivity, especially text inputs.
If every keypress triggers a state change and rerender, the UI will be slow and things like focus management become complex issues.
Without a rerender, it must now use a reactive binding to update the field value.
If you don’t want to update state on every keypress, your component must be uncontrolled, store its state internally (in the DOM) and update it to a parent store e.g. when the user stops typing (debounced) or moves focus out of the field. These are not trivial things either, and as a result, components get more boilerplate to handle the UX complexity. And of course, there are now UX pitfalls.
Indeed, these are reasons why reactive patterns exist. Now, if they just managed to abstract away the tedium.
I don't know what people generally recommend now, but for a long time the best practices with organizing React components had them connected to the store midway down the tree or higher, which definitely would have contributed to the UI slowness since it would rerender everything below that on each update. Push the store access down as far into the leaves as possible and you won't get anything noticeable, even though it is still doing more work than just accessing the DOM state as needed.
Also, focus management isn't really a thing in React, the vdom diffing means DOM nodes are updated instead of replaced so focus isn't lost or changed unexpectedly. There used to be a demo on the React homepage showing this, since the idea was very new to most people at the time - everything popular before it was just rendering template fragments to replace nodes and did have this problem.
> React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.
"just" is doing a lot of heavy lifting here. Where do you store "pure" GUI state (button state, is expandable expanded, …)? Do you really want to setup Redux for this? (And no, the DOM is not an option in non-trivial cases.)
Might be naive, but this has always been a concern of the view-model for me. Every GUI change results in a VM change via event/command. The VM becomes gospel for UI state which means reducers are much simpler, and my actual model doesn't care if it is indeed a button, expando, radio button or whatever else.
Yes but it is easy to abuse/misuse IME, in that I think it requires one to maintain your own sense of discipline for the principle separation rather than the library/framework guide you into it. The threshold between UI and state management is comically easy to confuse.
Not dismissing it, mind, that inherent guidance is not something that is easy to achieve and I much prefer working with the likes of React than without.
I'm not defending this model anywhere. I'm just stating that React can do what applfanboysbgon suggested: "As a game developer working in my own engine, UI is unbelievably straight-forward: [...]"
I'd argue that it was all downhill after we moved away from using HTML as the state representation.
Moving state out of HTML and into JS means we now have to walk this ridiculous tightrope walk trying to force state changes back into the DOM and our styles to keep everything in sync.
Given that problem, reactivity isn't the worst solution in my opinion. It tries to automate that syncing problem with tooling and convention, usually declaratively.
If I had to do it all again though, DOM would still be the source of truth and any custom components in JS would always be working with DOM directly. Custom elements are a great fit for that approach if you stick to using them for basic lifecycle hooks, events, and attribute getters/setters.
Wasn’t that the Lit framework? It was okay. Like a slightly more irritating version of React.
I recall the property passing model being a nasty abstraction breaker. HTML attributes are all strings, so if you wanted to pass objects or functions to children you had to do that via “props” instead of “attributes.”
I also recall the tag names of web components being a pain. Always need a dash, always need to be registered.
None of these problems broke it; they just made it irritating by comparison. There wasn’t really much upside either. No real performance gain or superior feature, and you got fewer features and a smaller ecosystem.
The point of Lit is not to compete with React itself, but to build interoperable web components. If your app (Hi Beaker!) is only using one library/framework, and will only ever one one in eternity, then interoperability might not be a big concern. But if you're building components for multiple teams, mixing components from multiple teams, or ever deal with migrations, then interoperability might be hugely important.
Even so, Lit is widely used to build very complex apps (Beaker, as you know, Photoshop, Reddit, Home Assistant, Microsoft App Store, SpaceX things, ...).
Property bindings are just as ergonomic as attributes with the .foo= syntax, and tag name declaration has rarely come up as a big friction point, especially with the declarative @customElement() decorator. The rest is indeed like a faster less proprietary React in many ways.
Kind of? Lit does add some of the types of patterns I'm talking about but they add a lot more as well. I always avoided it due to the heavy use of typescript decorators required to get a decent DX, the framework is pretty opinionated on your build system in my experience.
I also didn't often see Lit being used in a way that stuck to the idea that the DOM should be your state. That could very well be because most web devs are coming to it with a background in react or similar, but when I did see Lit used it often involved a heavy use of in-memory state tracked inside of components and never making it into the DOM.
Lit is not opinionated about your build system You can write Lit components in plain JS, going back to ES2015.
Our decorators aren't required - you can use the static properties block. If you think the DX is better with decorators... that's why we support them!
And we support TypeScript's "experimental" decorators and standard TC39 decorators, which are supported in TypeScript, Babel, esbuild, and recently SWC and probably more.
Regarding state: Lit makes it easier to write web components. How you architect those web components and where they store their state is up to you. You can stick to attributes and DOM if that's what you want. Some component sets out there make heavy use of data-only elements: something of a DSL in the DOM, like XML.
It just turns out that most developer and most apps have an easier time of presenting state in JS, since JS has much richer facilities for that.
Dont get me wrong, I'm a pretty big believer in interop, but in practice I've rarely run into a situation where I need to mix components from multiple frameworks. Especially because React is so dominant.
HTML simply can't represent the complex state of real apps. Moving state to HTML actually means keeping the state on the server and not representing it very well on the client.
That's an ok choice in some cases, but the web clearly moved on from that to be able to have richer interaction, and in a lot of cases, much easier development.
I'm sure you could find examples to prove me wrong here so I'm definitely not saying this is a hard line, but I've always found that if app state is too complex to represent in the UI or isn't needed in the UI at all, that's state that belongs on the back end rather than the frontend.
My usual go-to rule is that business logic belongs where the state lives - almost always on the back end for state of any real complexity.
With true web apps like Figma I consider those entirely different use cases. They're really building what amounts to a native app that leverage the web as a distribution platform, it has nothing to do with HTML at all really.
It's a bit more nuanced than that. State in Qite is held both in HTML and in JS Component. The html serialization is sort of consequence of changing a field (like when you want to update textarea content, for example). You can completely ignore it or you can also use it for CSS, for example. Another usecase is when user interacts with the pages, changes text in said textarea and it also automatically updates the JS Component field. Finally, there are also flags, which aren't stored in DOM. I'd like to point out this architecture isn't random, it came from building apps and realizing how everything interacts.
If the state can't, or shouldn't, be serialized in the client I question whether that state belongs in the client at all.
I'm sure you could find counterexamples so that isn't a hard line I'm proposing, but it is my opinion that nearly all website or web app built today over uses client state.
I use Preact without reactivity. That way we can have familiar components that look like React (including strong typing, Typescript / TSX), server-side rendering and still have explicit render calls using an MVC pattern.
View triggers an event -> Controller receives event, updating the model as it sees fit -> Controller calls render to update views
Model knows nothing about controller or views, so they're independently testable. Models and views are composed of a tree of entities (model) and components (views). Controller is the glue. Also, API calls are done by the controller.
So it is more of an Entity-Boundary-Control pattern.
From what I can tell, they do full page reloads when visiting a different page, and use Preact for building UIs using components. Those components and pages then get rendered on the server as typical template engines.
I still believe immediate rendering is the only way for easy-to-reason-about UI building. And I believe this is why early React took off - a set of simple functions that take state and output page layout. Too bad DOM architecture is not compatible with direct immediate rendering. Shadow DOM or tree diffing shenanigans under the hood are needed.
Yes! I think there's a lot of armchair web developers in these comments who think they know better: they don't.
Meanwhile, those of us that were building web apps with JQuery and other tools prior to React know just how painful "web development without reactivity" actually was.
Indeed.. Mostly-static pages with sprinkled-in interactivity were fine (like a table where you could sort the columns), but a full app? I dread having to touch the one page we have that uses Backbonejs+Mustachejs.
Also, things like unidrectional data flow are generally considered normal now, but back in that era it was rare. Two-way binding was much more popular, with constant bugs as the app grew. Around 2013 or so I was trying to switch a new page we were building to a very simple form of unidirectional data flow to deal with constant issues (ours issues were mostly losing state, we were all ad-hoc and not using two-way binding) and the other devs just did not at all understand it, constantly sidestepping it without even thinking because jquery made it so easy to touch everything.
Give me state management vs. event bus management any day of the week. The former is fully testable and verifiable. You can even formally define your UI as a state machine. With events you are constantly chasing down race conditions and edge cases, and if your data lives seperately in components there is no clean way to share it horizontally.
Reactivity isn’t the problem. Reactivity is one of the few things that helps reduce the complexity of state management. GUI state is just a complex thing. Frontend development doesn’t get enough cred for how deeply difficult it is.
In my view, the problem isn't specifically reactivity but the fact that reactivity isn't actually native of the UI toolkit.
Instead of HTML, think about GTK or Swing.
To add React-style "reactivity" to it, instead of just making a dialog to change the "title" of a document and committing the change when you press OK, you'd need a top-level "App" class that holds all the state, a class for state properties with IDs accessible at runtime which probably would be a variant (accepts any primitive type), a binding class to bind the toolkit's textbox to the App's state "title" property (because you'll probably want to bind a lot of textboxes, so it's easier to separate the code into classes), and then every time the user types something into the textbox, instead of using the toolkit's code that is already written for you which updates the textbox' state directly, you block the state change in an event handler, send the state change to the App class, let the App class figure out the differences between the current state and the new state, and then it calls some callback in the binding class that is responsible for actually changing the text in the textbox to reflect the new App state. You'll probably run into a ton of issues (selections resetting, assistive technologies bugging, etc.) that you'll have to deal with externally somehow. All just to make it do exactly the same thing it would have done anyway.
It's like you have a fully autonomous robot and you want to add marionette strings to make it move.
I believe every UI developer that has used frameworks like Swing has reached a point where specific user interfaces, even those that look trivial, become too complex primarily due to things like event handlers. Trying to figure out a simple thing like why a radio box is enabled and is marked dirty may require long debugging sessions where one event handler for component A triggers another event handler for component B, which triggers another event handler, etc. And before you know it, 50 events were triggered just during the initial mounting of the UI. Making sense of it all is maddening.
And then said developer does what they think feels right: "I have my state and I simply want all the fields to reflect my state". So they try and rewrite the component into some sort of mini immediate-mode style component. All of the event handlers get wired up a single "layoutComponent" method that tries to call all the UI component setters based on the current state with all the problems you alluded to. I know I've done this type of things numerous times before going back all the way to my first internship, well before React was even a thing.
I think modern frameworks solve the reactivity issue this well enough, that it really doesn't matter if the underlying framework is not natively reactive. I will say though that I've primarily used Vue.js where most state is relatively local and we don't try to re-render the world on every input. I think part of the problem with modern dev is likely that React has become the default instead of a simpler framework like Vue.
That's true. Events are the WORST thing about GUI programming. They're so convenient and so undebuggable it almost feels like a trap.
Ironically, in most cases events are only used by one object, but you always want to consider the possibility that two objects will want to observe the same event, so now you need an entire event dispatching class, and then you'll want observable properties, and the nail on the coffin is going to be observable lists. When you reach that point, one event triggers another, which changes a property, triggering another event, and so on and so on. You are 5 layers deep into event callbacks. The call tree just has the same "callCallbacks()" method over and over again.
Bugs start happening because of the order in which callbacks are called becomes important, so now you need a way to give some callbacks priority over others, or make them happen after all normal callbacks were called. One callback destroys an object which has callback on the event that destroyed it, so you're going to need a wrapper around your callbacks that gets notified when callback's object is destroyed to change its reference to null in order to avoid executing code on the destroyed object if this happens while iterating the callbacks in the event dispatcher. Sometimes calling callbacks in wrong order is a performance hit, when it doesn't just get stuck into an infinite loop and you run out of stack.
I wonder if there is GUI programming paradigm that solves all of this or that you can call the "best" one. Maybe it's reactivity, maybe not. Who knows.
I’ve written about how Svelte, Vue, and Solid are all reactive and share common pitfalls due to their reactive solutions. My theory is that they all cause worse bugs than they prevent.
Manual refresh(). This is something Crank does, and other frameworks like the new Remix one is picking it up as well. Being explicit has its advantages.
Why do you list all of these design patterns as though you have to hold them all in your head at the same time? As though each one made the ecosystem successively worse?
UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events)
That's not so much a lack of statefulness as it is making zero effort to lift your application's data model out of platform-specific UI concerns.
The original sin wasn't reactivity. It was putting state in the wrong place. Making the client state heavy. It's been downhill since then. Now you need to duplicate state handling between your frontend language and your backend language. Which leads to "isomorphic" backends seeming like a good idea.
Yep. It's one of those great on paper, tough in reality models. Used sparingly and wisely, it can make great UX fairly trivial. But sadly, state is more often abused and loaded with tons of data and complexity it shouldn't be holding. Something, something just because you can, doesn't mean you should.
It's much simpler. Reactive UIs and declarative UIs let you built things more more easily. You can almost entirely ignore an entire class of issues (state mismatch for instance).
That of course led to developers building much more complex UIs. Which offset the gains from reactivity. Hence the mess and we're basically where we started.
FLTK is great at being fast and light, that’s about it. It’s kind of cumbersome to use but honestly does what it says on the tin. Highly recommend for smaller use cases but can’t imagine using on a large project. I used the rust bindings which are well maintained.
I heard somewhere that there is some sort of evangelical Christian sect in Korea that believes the current US president was sent by God. Not as a positive force, but as a force to end the global status quo (which I suppose they consider unjust). I find this fascinating because the US president's actions so far have: exposed decade-old myths about the rule-based international order, caused the EU to seek more self-reliance, caused former enemies in Asia to consider alliances and now accelerate the end to fossil fuel dependence. One could argue that the results of his actions are indistinguishable from that of a double agent's.
And then there's the theory that the man is also the biblical antichrist which I think fits the prophecy reasonably well. Revelations has some pretty specific details that match up which I find quite entertaining.
I still think Trump has been a net good upon the world.
Trump's actions have actually jumpstarted economic reforms in several countries. For example, just last year Canada made serious moves towards "One Canadian Economy"[1] to rationalize interprovincial trade among other things.
The developed world, but especially NATO countries, need to wean off America's teat for their own good.
There's a reason you separate military and the police. One fights the enemies of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people. - William Adama
indeed, and this is unironically cited by the "shall not be infringed" crowd as a reason that they should be allowed to bring guns anywhere and everywhere, potentially turning any movie theater disagreement or minor road annoyance (or traffic stop, to bring this back to the police) into a violent life ending incident. to quote jwz out of context, "now you have two problems".
I thought this was interesting, so I checked your sources
> Insane take truly. First, CCW carriers are statistically the least likely to be involved in any kind of "violent life ending incident".
Sure, you could argue this, with the exception of suicide, found guns (usually by kids in the home), and stolen guns. It's not just the person certified, it's everyone around them who can obtain access to the gun they now own
>The number of non self-defense homicides caused by them is approximately 0 per year.
Only because there's no public data on this particular statistic. A nonprofit produced a database based on news headlines and limited state data, though, and found 1700 suicides and 600 convicted murders by CCW carriers between 2007 and 2025: https://vpc.org/concealed-carry-killers/
A better way to phrase it would be that the number of homicides are far less than the violence that a lack of CCW would enable, though that on its own is statistically shaky.
> Second, to suggest that people should allow themselves to be victims to violent crime because it's safer for the whole is some sort of collectivist trotskyite nonsense we will never agree on. Under no circumstance should an innocent person forfeit life or property for a violent criminal.
You're right, we (the USA) probably won't ever agree on it, due to the intense financial incentives behind firearms manufacturing and ownership and the subsequent lobbying and influence over public influence that those companies fund, but every other country apart from the US is a sweeping counterexample to this. We lose 45,000 people per year to guns (~60% by suicide). It's the #1 cause of death for children since 2020. https://www.cdc.gov/firearm-violence/data-research/facts-sta...https://www.gunviolencearchive.org/
It's reductive to suggest that the only thing having more guns around does is "prevent victimization" when the guns themselves enable violence to so many nearby parties, including to the owner themselves.
> Its astonishing to me people can look at FBI statistics, total gun deaths trending down for the last 30 years, and then suggest people who are statistically the most safe with guns shouldn't be able to carry them.
The figure you're quoting appears to be the graph from page 1 of https://bjs.ojp.gov/document/tpfv9323.pdf, which is nonfatal victimization, which hasn't trended down--it's hovered between 1 and 2 per 1000 since 2003, and appears to be more of a reflection of improved medical skill than anything about guns.
Anyway, you were quoting gun deaths--that's page 13. That chart has stayed roughly the same since 1999: 4-5 per 100k persons (except for the spike during covid)
>The qualifications for CCW are harder than police qualifications in most states. But you wouldn't know this because Everytown, MSNBC, CNN, and others have spent the last 12 or so years lying through statistics so that the government has the monopoly on violence.
No permit required for CCW in 27 states. You also have states like Utah that will mail you a permit that's valid in 30 different states and doesn't require proof of live-fire training.
But yes, in CA, for example, it's a 16 hour course, background check, fingerprints, clean record, (sometimes) psych evals, and even then there are restrictions.
This isn't an indicator that CCW is difficult to obtain, though, since this is a reasonable barrier--it's an indicator that police qualifications are laughable. (While we're on that topic, by the way, law enforcement officers (both active and inactive) are allowed to concealed carry in all 50 states)
Unfortunately, the police in Adama’s world are different from our own:
> the other serves and protects the people
The only time this was actually true was at the advent of organized policing in the United States - there were two purposes for cops. In the north, they were meant to ensure the protection of property, particularly commercial.
In the south, it was the same except that usually meant slaves, so in the worst kind of technically correct sense, they did at one point protect people…kind of. Well, kept them “safe” from freedom and such.
Isn't this also in line with recent proclamations by at least two venture capitalists that they do not reflect / introspect / dwell on consequences in any way?
No because you don't understand what Andreessen means by reflection / introspection.
He obviously thinks you should learn from your mistakes and that you must be an avid and quick learner.
But learning skills is not what introspection / dwelling is.
It's spending times on thoughts like "what should I be doing with my life". "I can't believe how much of a victim of the system I am".
And he specifically contrasted it against doing stuff.
Writing code >>> walks in the woods.
Obviously reflection is necessary to recognize mistakes of the past. What Andreessen was talking about that you should spent majority of your time acting not reflecting. Not that you should spent 0 time reflecting.
Did we not understand when he said introspection was something made up in the past few hundred years? I was aghast when he said it right in front of my copy of Meditations given how much these guys also obsess over the Roman Empire
There are those who would argue doing anything is better than doing nothing while you try to figure out what to do. I'm in a position where I know what my passions are and am sufficiently constrained by resources that I can't afford major mistakes; but if I were sufficiently wealthy and indifferent, throwing darts at a board with a couple of ideas on it and just doing whatever has a certain romance to it.
Don't do nothing while figuring out what to do. But you should still spend time thinking about what to do.
If you're wealthy time and personal energy are the most valuable, irreplaceable resources you now possess. Why squander them on fruitless, random pursuits if you could think strategically and do something that really matters?
Why can't we handle this the same way we handle knives, guns and chainsaws: require adults to secure the device before letting minors near them? All the devices need is the ability to create limited access profiles. A human adult performs age verification by only providing the minor with creditals to a limited profile. Trying to perform that verification so far away from the minor, after they have got to the last gate, seems like the worst way to do it.
I want my kids to grow up in a world where they can install linux themselves. I don't want them to grow up in a world where they can't walk to a neighborhood park without me.
Not sure I see the crossover between activities performed at home and problems of car centric street design and the resulting poor pedestrian traffic safety?
If I have to watch my kids 100% of the time they can't walk to the park.
Nothing to do with street design - most suburbs have a park a safe walk near any house. That kids are not walking there is nothing to do with street design.
(c) "Neglect" does not include:
[...]
(iv) permitting a child, whose basic needs are met and who is of sufficient age and maturity to avoid harm or unreasonable risk of harm, to engage in independent activities, including:
[...]
(B) traveling to and from nearby commercial or recreational facilities;
A handful of other states have followed suit. This page shows a map of states with similar laws: https://letgrow.org/states/
Remember the first post that started this "require adults to secure the device before letting minors near them?" - if I have to secure all devices that means I can't let my kids out of my reach since they might find a device someplace. Raspberry pi's are cheap, you can dumpster dive old, but working devices. There is free wifi all over.
In short the original post was subtly but very opposed to those very laws you are looking at.
Mind you there is nothing about OS level age verification that stops any of the above - which is why I'm against it.
Right, my comment wasn't intended to be an argument against your points; quite the opposite, I was pointing out that many people see the value in letting kids be independent. Really, the context was that I had assumed the pull quote to be referring to over-protective parents and their ilk (the "this" in the first sentence) and I just wanted to show that some people have more sense, though I can see how it's not clear what I was getting at. Disallowing your kids from going outside for fear of potential danger is logically equivalent to disallowing them from using the internet for the same fear.
But now I wonder: I doubt the law would actually consider that you let your kids outside and thereby gave them access to the unsecured device they found in a dumpster. From what I understand of the CA law, you would not be the "operating system provider" in that context, because you do not develop, license, nor control the operating system. I think, at that point, a prosecutor would probably be looking at neglect (if they really want to go after the parent) as the most viable charge, which would be protected by the independent kid laws.
Still, to your point, that doesn't mean the OS law in question will be effective at what it's meant to do, so I similarly do not see a reason to support it. (One could assume "what it's meant to do" is remove liability from social media service providers, but that's not the ostensible reason even if it is the likely reason; regardless, I also wouldn't necessarily see that as a reason to support it.)
I have - he is making huge logic errors. There is good stuff there, but some conclusions don't follow. Others are correct for one area but don't generalize. He isn't as bad as strongtowns but still you need to use care when following him.
I am empathetic to 99% of this woman's case and the article.
However, the ending though, really feels like they're one step away from anti-vax, anti-education, and pro-hate pro-bigotry.
This case really feels like an over-reach. But to condemn the entire system because they have an interest in making sure the country functions and sets minimum standards of life and care is not a "bad thing". The government represents the collective decision-making of millions, hundreds-of-millions of people.
Don't throw the baby out with the bath water because one cop (in rural Georgia of all places) over-reacted.
I'm pretty sure most kids older than 12 do have access to kitchen knives. And actively use them too.
I generally agree with your point. But at the same time access to the internet resouces and to gun or a chaisaw is not the same.
I have no problem securing a few items if my home, but I have no control over whatever is available on the net.
Sure, I can write some firewall rules or create "kid's account" on a streaming platform, but I can do this for every single known service, chat, IM group etc.
Even if you did, you just lower the chances. I've created Netflix kids account specifically for mine. On its own it suggests also various documentaries on top of cartoons. We took the first one it suggested, and IIRC in second episode there was a very gruesome and detailed part with polar bear eating baby seals, one chew at a time.
One way to traumatize 4-year old, I'd say an effective one.
It’s a content issue mostly. Content providers do not want to properly tag and silo their content. And add parental control to kids account. They want to shift that burden to everyone but themselves.
The knife and the knife maker doesn't have intentions to pump propaganda and porn into the childs mind. The internet is not neutral like knife. The internet has an actor on the other end (human or algorithm) that has certain intentions. Thus a child can be intentionally influence via the internet. A knife does not act on its own to influence the child's mind. So, apples and oranges. I'd argue the internet is significantly more dangerous to a child vs a knife. The internet wasn't built for children, it was never child friendly to begin with and we shouldn't mutate the internet to cater to children. Its best to treat the internet like a hostile force for a child's mind and keep children completely off it to begin with. Make it illegal for children to use a device connected to the internet, it is the parents responsibility. Same as guns. Its not the gun smith or gun sellers responsibility to keep the child safe from guns - its the parent's.
For some of these, we fully disallow company to child transactions or interactions. Wouldn't applying the same logic require the adult to fetch any internet content and give it to the child on a case by case basis?
In this case, it is the data from the website, not the electronic device itself, that is seen as the item being transacted and regulated by age gates, no? The attempts to actually regulate it do feed back into changes on the electronic device, but the real cause of concern (per the protect the kids argument, if that is the real reason is debatable) is a company providing data directly to a child that parents find objectionable. That transaction doesn't have a parent directly involved currently.
Controlling the device itself and saying free game if a parent has allowed them access is a bit like saying that if a parent has allowed a kid to get to the store, there should be no further restrictions on what they can buy, including any of the above three items.
I don't know why you think this will stop page verification requirements. For almost all items where a parent/guardian is responsible for a child's access to the item, third parties are also required to not sell or transfer the item to a child. That gets us right back needing to age verify people.
That is kinda the idea behind the california law that was on the front page a few weeks ago. The parent set up a local account with a age bracket, and the OS verifies that in the app store and maybe webpages if they fit the age bracket.
> Why can't we handle this the same way we handle knives, guns and chainsaws: require adults to secure the device before letting minors near them?
Is this a thing?
My 10yo has used all three of those things. If there were some legislation requiring they be "secured" before my son could be in my presence, obviously I'd oppose it, along with every other reasonable parent.
Not really. It's the difference between a mandatory field and an optional field. And in practice, and its effects on the internet, that difference is huge.
It looks like the system is picking up anything in the URL parameter as the target output language. Always interesting to see how these edge cases play out in production! #TechInsights #SoftwareDevelopment #Localization
I used have a netbook as a second personal device around 2013 and loved it. Very easy to carry around and work on the go, and it could do everything except development work (web browsing, Word, Excel). I actually miss the form factor.
reply