You could scale "provisional employment" by making use of "past employment" as a weighting mechanic. Let other companies do the "is employable" and "works on a team" checks. I believe that is called "a resume" and "references". "Let's add stamps and maybe a star system for these references" sounds like just reinventing LinkedIn with a slightly more Uber-like UX. LinkedIn already exists? Resumes already exist?

It seems to me like a lot these problems start and end at "we don't trust resumes and past employment history" and "we highly prize 'cultural fit' but think there needs to be a technical component to 'cultural fit' interviews rather than just doing proper 'soft skills' interviews". Maybe we all should just straight up stop pretending like we are looking for anything more than soft skills and vibes?

I think the "anything computing was seen as state secrets thing" is also possibly easiest to see in any documentaries and books on the history of Tetris (including the 2023 movie on Apple TV+). It's weird to say that Tetris was one of the most innovative software programs in USSR history and that the USSR almost crushed it before it had a chance to soar in the minds and dreams of millions of players, but that's basically what it was.

Even accepting the counter-narrative that the story of Tetris was "evil" capitalists taking advantage of the USSR to "steal" Tetris from the people of the USSR and the output of their socialist labor, the USSR was never in the position to offer Tetris to every worker in the country as a gift for their hard work because it was a state secret and computing wasn't something everyone had access to.

It is interesting to ponder if the USSR had made different decisions on the usefulness of general computing for the masses rather than the military what would have happened to Tetris as one interesting microcosm of the USSR's relationship to computing.

On iOS Scheduled Summaries are really great. That's become my personal default on my phone. Scheduled Summaries roughly every 4 hours during waking hours and the default choice every time the question pops up for a new app is "In Scheduled Summary". I could see with some modest UX improvements Scheduled Summaries becoming the default for more people.

Heavy use of Scheduled Summaries does also lead to me wondering why there isn't a "default notifications to Ask/On/Scheduled Summaries/Off" global setting, though I would want that choice between Scheduled and Off at least.

I believe this is also a consequence of iOS gating background processing and scheduled timers allowed by an app based on whether or not notifications are enabled by the user. I believe Microsoft Authenticator also wants notifications enabled for the same reason most Banking apps on iOS want notifications enabled, so that it can register a ~10-minute background timer to run any backups, securely clear program memory, and safely "logout" from any active "session".

On the one hand it helps avoid "permissions fatigue" that the user just has the one permission to manage ("enable notifications"), but on the other hand it does lead to these questions about why an entire class of applications (banking apps and security apps) whose role should be mostly never to send notifications (because that can be a FUD/fear/fraud vector) need notifications enabled to work securely.

If you are making it native to the browser, why have a "virtual DOM" "definition language" middleman and not just jump straight to real DOM, the browser's existing bread and butter?

  let ele = <div id="some">Text</div> // ele is now HTMLDivElement

Doing that `element.append(ele)` just works with existing DOM APIs.

Instead of supporting classes and functions in browser-supported JSX with their own life cycle model, you can just require registered Web Components and reuse existing Web Component life cycles.

I think if Browser-native JSX support were to happen it should probably either be real DOM or remain a function tree so that at least some tree operations can be amortized by the function compiler.

Which is that most JSX is actually compiled to nested calls like:

    let elDef = jsx("div", {id:"some"}, "Text", jsx("div", {id: "inner"}, "Text2"), ...otherChildren)

The `jsx` function can potentially avoid some future tree walks/recursion by the nature of being unrolled by the compiler into nested calls instead. That's a useful property lost in trying to agree on a single virtual tree definition. It's also one maybe unnecessary if just relying on real DOM trees, because browsers have their own optimizations for DOM tree walking.

There's several frameworks that use JSX but don't act like React. I definitely have found myself in the "I love JSX but don't always love React" camp. I used Cycle.JS for a while, but came back to React for the ecosystem.

For what it is worth, I'm rather proud of my smaller reactive (RxJS-based) JSX alternative (Butterfloat), which is not a Virtual DOM like React or Cycle.JS (it is more "What if Knockout but TSX?"), and I am working on its second version now (among other things expanding its SSR/SSG powers, which already have a very different, I'd argue simpler, take on SSR/SSG than the Next.js/Nuxt.js/React Server Components world).

Just found the link to the project: https://github.com/WorldMaker/butterfloat

That's neat, will give it a spin in the future.

For what it is worth, I missed AngularJS/Angular 1 and managed to use Aurelia to avoid several versions of Angular 2+. When I did get eventually pressured into working on Angular it was a nightmare for several reasons. One of them was I got hugely burnt by Zone.js. Angular is finally doing something about Zone.js years after my warning. (Though it took Signals to push them to do it, which is another rant because Signals are just dumber Observables and Angular already has an RxJS dependency.)

> (whereas Angular uses HTML)

Angular has as complex a template language as any other major framework. The fact that it uses .html files is a convenient lie to make it seem like it is "just HTML". Its template compiler is a far more complex beast than JSX. (And it doesn't have anything like half the type safety of TSX.)

happy to see another fan of aurelia here.

i actually started with angular 1 before it became popular. i evaluated the alternatives at the time, knockout, ember and a few others, and angularjs just looked the best. finally when angular 1 was no longer maintained i discovered aurelia, in part because rob eisenberg had an interesting story about how he got invited to the angular team because of his ideas, and how he left again because he could not actually get his ideas implemented.

it's a bit disappointing that development of aurelia 2 is slow going, but in some ways i consider that a good thing, considering how fast vue and svelte are evolving away from what they were originally.

i need to look at solid.js though. the only promising newcomer in resent years if the state of js survey is any indication.

I was more of a fan of Durandal, which was Aurelia's predecessor. It was a SPA wrapper around out-of-the-box Knockout. It seemed cleanly focused and was useful in that you didn't need to learn a different view engine if you were already using Knockout.

Following Rob's blog because of Durandal was a part of how I landed on "try to avoid Angular" and it did give me Aurelia as a bit of arsenal to say "hey, this framework is enough like Angular that it should feel comfortable to work in" for a time.

I never did end up liking Aurelia more than Durandal, but I certainly liked it more than Angular.

makes sense. i was obviously coming from angular, and as i said before, i did look at knockout and i found angular was the better choice. so i guess aurelia's appeal then came naturally. but then i didn't know about durandal, so i can't say how much i would have liked it. but this tells me that angular had a stronger influence on aurelia than i was aware of. that's not surprising of course, but still interesting.

Deno always supported importmaps so dependency management was importmap management. If a script had its own dependencies it could depend directly on a URL or better yet it could use an importmap name and expect you to add it to your own importmap. Admittedly that was moving some of the work of a package manager to manual steps, though, so JSR is still an improvement over managing an importmap yourself for your entire dependency tree.

Also, URLs didn't have to mean "exact version". A script provider might use a URL scheme with exact versions in it such as `/packagex/2.18.3/main.js` or could do semver-floating symlinks like `/packagex/2.18/main.js` for latest patch and `/packagex/2/main.js` for latest minor. You could even have hosts that just used the classic top-level `/packagex.js` for whatever is the latest.

I think the real problem with URL dependencies wasn't so much "exact versions", it was the confusing flexibility that versioning schemes were dependent on the package host because URLs are orthogonal/agnostic to version numbering and different package hosts can do whatever they wanted. (Naming conventions you'd have to look up for each/every host versus semver-aware package management code.)

Yes, the article itself even points out that the C# default has always been to make the unsafe keyword a compile error by default and must be opted in at the project level to even use it. So most C# application code doesn't use unsafe.

The benefits here are mostly to specific types of libraries, often either deeply performance-focused libraries or complex native interop libraries (things that wrap C/C++/Rust/etc code as a .NET Library).

The article mostly also points out that like Span<T> many of the biggest benefits to application writers here are going to be making the runtime itself quietly better (faster and safer). The new compile errors will make Base Class Library code and runtime code more auditable for potential memory safety issues by bubbling up safety concerns higher into the code stack and making the boundaries between the unsafe and "safe" code much easier to find. It will provide additional incentive to narrow the number of things that need to be marked `unsafe` and provide extra incentive to the runtime to minimize `unsafe` dependencies. This includes adding additional weight furthering the push for rewrites from "performance" C++ code (under the hood of the runtime) to memory safe C# code with modern safety/performance tools like Span<T>, while also reducing some of the similar pressure to rewrite that C++ code as Rust for memory safety reasons rather than directly to C# (with less overhead of transitioning to/from "managed code" and "native code") by providing similar `unsafe` safety marker tools to what Rust has had since 2024.

(ETA: There may still be some possible breaking changes to today's application code when opting into the new safety checks though by adding possibly more uses of the unsafe keyword than were needed before as many APIs with unsafe in the name or documentation such as the Marshall.* family of functions will probably get new safety documentation. Most of those concerns are still in P/Invoke and native library interop spaces and would probably be refactored into libraries to re-isolate the unsafe code and have the application continue to not allow unsafe blocks, but that will be tech debt migrations that may show up when opting into the new behaviors.)

This change suggests that passing pointers is "generally safe", the unsafe boundaries are when they are de-referenced. It sounds like the Marshal methods are probably going to get a lot of surprising new safety warnings, but not all of them just because of the use of IntPtr. This change does open more opportunities to switch IntPtr to more explicit type-safe options like void* or byte* as the new compiler no longer needs unsafe {} blocks around just passing around pointers from one function to another.