I find this handy in Chrome occasionally. Just confirms that BeOS had the right windowing features all along.
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.
I could've sworn firefox had an "all tabs" preview button that looked like 4 blocks in a grid, before the Australis era. Can't find any pictures/video footage of it in action however.
> Just confirms that BeOS had the right windowing features all along.
Which windowing features are you referring to? I recall with BeOS (and I assume Haiku) you could shift-click on the "yellow window tab" to move it along the top of windows, so you could have multiple windows stacked, but with their tabs visible on the top, but I don't recall a split-view.
I did something a lot simpler than this to have some more control: I gave a Twilio number to the building manager for the door box, then had an app where I could give out codes to people. Valid codes responded with a "9" DTMF signal which opened the door, a "1" forwarded the call to my phone.
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.
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.
I do this with long blog posts, but not short tweet-like things. That feels ok some of the times as most of the micro-posts are throw-away, but sometimes I do make some posts I refer back to and would like to keep better ownership of.
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.
Hidden class optimizations just make JavaScript objects behave a little more like Java class instances, where the VM knows where to find each field, rather than having to look it up like a map.
It doesn't make JS faster than Java, it makes it almost as fast in some cases.
I can only say what I observed in testing, and that's that having millions of instances of a class like Point3D{x, y, z} in JS uses significantly less memory than in Java (this was tested on Android, not sure if relevant). It was quite some time ago so I don't remember the details.
Well, Android is not running Java, it runs Android runtime (dalvik) byte code. In general, depending on when it was, that runtime is much much simpler and does a lot more at compile time at the expense of less JIT optimization.
It's also many versions behind the Java API (depending on when it happened).
So your data point is basically completely irrelevant.
JavaScript has the exact same issue - objects are on the heap and require allocation and pointer dereferencing. For huge collections of numbers, arrays might be better.
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.
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.
reply