11,983 karma · joined August 4, 2011
And in most functional systems the one-time setup function would return the render function so the render function can close over state.
Which is pretty much what a class with fields, a constructor, and a render method give you.
React's "functional" components are simply poor approximations of classes. Instead of easy to read and reason about class fields, you put state in useState() function classes that are effectively named by their appearance order in source and who's current state you can't introspect with dev tools!
The component function mixes one-time setup (which should be a class constructor) with repeated render calls (which should be a method), so those of course have to be separated by putting the one-time work inside of a closure inside of the repeated should-have-been-a-callback function. Event listeners and other callbacks are another huge mess. Don't forget useMemo() or useCallback() (but which?).
It's actually quite mad.
And the differences between classical and prototypal inheritance basically don't even pop up under normal class usage in JS: just use class fields, don't mess with the prototype chain, and don't dynamically add or delete properties - all things that are how classical inheritance works - and things just work like you expect.
Most WordPress sites could just be static, but WordPress has a nice editor interface, so they're not - unless you use a SSG plugin. Building that into the core workflow (which I believe Astro supports) and giving users a nice hosted editor that produces a static site would be welcome innovation.
Some fonts are close enough that I don't know if I'd choose one over the other consistently, and I'd be curious to see a percentage score of how much I like a particular font.
Two more OS-level windowing features I'd like to see in browsers:
- OS X like Expose that shows a preview of all tabs for a window. That would help me find a tab visually.
- A command to override the meaning of fullscreen to take over the whole tab, rather than be truly fullscreen. That would let me use other window management features with maximum video size within the window.
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.
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.
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.
So I've been thinking of updating my site and habits to center around running my own ATProto PDS and publishing my blog posts there, with my blog just being my web front end to my PDS. Then I could use that same PDS for Bluesky, photos, etc. and self-host a wide variety of things with an interoperable social layer.
This new company chose a very confusing name that has been used by the Open UI W3C Community Group for over 5 years.
Open UI is the standards group responsible for HTML having popovers, customizable select, invoker commands, and accordions. They're doing great work.
It doesn't make JS faster than Java, it makes it almost as fast in some cases.
But JS has another problem: there's no way to force a number to be unboxed (no primitive vs boxed types), so the array of doubles might very well be an array of pointers to numbers[1].
But with hidden class optimizations an object might be able to store a float directly in a field, so the array of objects will have one box per (x,y,z), while an array of "numbers" might have one box per number, so 3x as many. My guess is, without benchmarking, is that JS is much worse than Java then, because the "optimization" will end up being worse.
[1]: Most JS engines have an optimization for small ints, called SMIs, that use pointer tagging to support either an int or a references, but I don't think they typically do this optimization for floats.
The String.format() problem is most immediately a bad compiler and bad implementation, IMO. It's not difficult to special-case literal strings as the first argument, do parsing at compile time, and pass in a structured representation. The method could also do runtime caching. Even a very small LRU cache would fix a lot of common cases. At the very least they should let you make a formatter from a specific format string and reuse it, like you can with regexes, to explicitly opt into better performance.
But ultimately the string templates proposal should come back and fix this at the language level. Better syntax and guaranteed compile-time construction of the template. The language should help the developer do the fast thing.
String concatenation is a little trickier. In a JIT'ed language you have a lot of options for making a hierarchy of string implementations that optimize different usage patterns, and still be fast - and what you really want for concatenation is a RopeString, like JS VMs have, that simply references the other strings. The issue is that you don't want virtual calls for hot-path string method calls.
Java chose a single final class so all calls are direct. But they should have been able to have a very small sealed class hierarchy where most methods are final and directly callable, and the virtual methods for accessing storage are devirtualized in optimized methods that only ever see one or two classes through a call site.
To me, that's a small complexity cost to make common string patterns fast, instead of requiring StringBuilder.
The only big issue here is the interest, which we force ourselves to pay by requiring the issuing of bonds in the first place, and is a big transfer of tax payer money to the large bond-holders.
Isn’t it Time to Stop Calling it “The National Debt”? - https://evonomics.com/isnt-time-stop-calling-national-debt/
I wonder if the edge here is not going to come down to which model you choose, but which sources of information you give it. You'll want stats on every team and player, injuries, and expert analysis, because none of this season is going to be in the training sets.
The persons words fit the definition of genocide.
> Don't do it again
Who are you?
If it's genocide when Israel does it to others, it must be genocide if done to Israel.
I'm building a new Wasm GC-based language and I'm trying to make as small as binaries as possible to target use cases like a module-per-UI-component, and strings are the biggest hinderance to that. Both for the code size and the slow JS interop.
There are many citizens, like me, begging for red light cameras so something can be done about the rash of crashes and killings from willfully reckless drivers.
Maybe they just stop running red lights?