It never really went away for me. I still reach for it in every web app. Over time, I've stopped using some parts of it that used to be timesavers... e.g. shifting away from $.ajax calls to fetch, but it's a good base for rolling your own responsive frameworks if that's what you want to do. And it's what I want to do, because I dislike the paradigms for react and vue, and have no interest in relying on those projects.
It is absolutely not bait. Declarative programming for the web is certainly more pleasant, but direct DOM manipulation will always and forever have a performance upper hand over rendering frameworks that sit atop the DOM. Now this performance difference is usually negligible, but for projects like VSCode or this, there’s a very good reason they aren’t written using frameworks.
Controlling DOM updates yourself will always allow for best performance.
Virtual DOM still needs to reconcile and apply DOM updates, but since this is handled by your UI framework of choice you have limited ability to optimize these updates.
I would argue that if performance is your top concern you'd still be better off using a framework like SolidJS, but theoretically JavaScript and JQuery can be better optimized.
Are we seeing the same benchmark? On that site, both Vue and Svelte are extremely close/on-par with Vanilla JS on every benchmark except the transfer size and first paint (which shouldn't matter at all here). jQuery also has an overhead, and I wouldn't be surprised if it's larger on many benchmarks than, say, Svelte's.
Yes, modern frameworks are getting very good. This does not change the fact that abstractions around DOM updates (frameworks) limits your ability to maximally optimize performance. The output of frameworks is still vanilla js.
Depending on how you do rendering, vanilla JS can be extremely fast.
For most web apps, the initial layout and rendering take the biggest portion of the rendering budget. Subsequent changes are minimal and can be rendered very fast. If you can avoid re-rendering the whole page for every little change, the update can be fast.
React's advantage is to track the changes for you. That doesn't mean you can't track the changes yourself. And if you structure your rendering and refreshing pipelines correctly, vanilla JS would do just fine if not better.
We also do a desktop in a browser, but some core differences are you can launch real browsers in our environment and essentially load any web-based app you want collaboratively. It also does screen sharing and has A/V for meetings (we are not open source though, and have a paid product):
I believe the original reason was the founder wanted a way to have his guitar teacher share tabs and give A/V feedback on his guitar playing. It was originally a product for teaching with limited sharing features, then the founder realized it could be used for many other use-cases and expanded to be much more collaborative and became essentially a multi-room collaborative virtual desktop-like experience.
We use it daily for things like standups, sprint planning, all hands, operations dashboards, product roadmap discussions, dungeons and dragons sessions, watching videos together and more.
Sorry about that. It should hopefully be fixed once we change our A/V stack in a few months. I unfortunately do not have specific details on why the A/V stack only works with Chrome-based browsers.
I've tested Puter on Oculus, seems to work pretty well; however, I think very soon I'm going to do very specific optimizations for XR, it's a new, emerging form factor that deserves its own design.
“ - Why isn't Puter built with React, Angular, Vue, etc.?
For performance reasons, Puter is built with vanilla JavaScript and jQuery. Additionally, we'd like to avoid complex abstractions and to remain in control of the entire stack, as much as possible.
Also partly inspired by some of our favorite projects that are not built with frameworks: VSCode, Photopea, and OnlyOffice.
- Why jQuery?
Puter interacts directly with the DOM and jQuery provides an elegant yet powerful API to manipulate the DOM, handle events, and much more. It's also fast, mature, and battle-tested.”
This just tells me they don't understand why any of those things were created and how to actually use them. It won't get traction and it'll wallow and get stale since it'll be an unmaintainable project. Also, VSCode is built on Electron while Photopea and OnlyOffice are straight up painful to use.
That’s a lot of smack talk for someone who didn’t provide a link to their own, even more impressive project.
This kind of reaction reminds me of people who can’t fathom why anyone would use a database without an ORM. (And meanwhile I’m confused because nearly everything I do with a database would be twice as difficult and ten times slower with an ORM in the way.)
It’s only a prerequisite if you want to belittle people and accuse them of making ignorant technology choices. (If the discussion was ORMs, I’d be delighted to have an excuse to share and promote my public projects. But my earlier aside doesn’t constitute a change of topic for this thread.)
Wrong. It’s the rule, and has been thus for at least 270 years. Breaking it attracts a $500 fine and a gentle slap in the face with a pair of leather driving gloves.
That's not the point. The point is that it doesn't use a framework like React, Vue, etc., it instead directly creates and manipulates DOM elements, somewhat like Puter.
I got carried away for ages with this. I was installing extensions in VSCode and got confused when it wouldn't open a link to a repo in a little browserception, because by that point I was fully expecting it to.
Thank you! As a side note, we're open-sourcing the VSCode integration soon. Building an integration with VSCode takes quite a bit of work so hopefully the community will benefit.
I've been using this as a way of quickly putting a UI over an EC2 instance.
Could you advise on how you'd do the equivalent here? Eg., say I want to provide an EC2 machine with various packages installed (python, node,...) -- or, the equivalent docker image -- is there a way of using your UI to provide access to this?
Consider, eg., using an iPad with your UI in a browser. Could you advise a way that this could provide a complete development experience for datasci/seng? (As above, i'm using theia to do this in a quick-and-disposable way).
One of the things I find curious here is that there's no mobile story to speak of. Drag the window narrow, and all that happens is that the taskbar icons look squished.
Is there a mobile mode coming?
This would be dope af if I could get a mobile-esque UI on mobile-like devices, or opt into one on tablet-like devices.
In all honesty, this is perfect for people like me (who are rarely away from a keyboard) but less than ideal for people who live a more 21st century computing lifestyle.
If this thing had a mobile mode it would be revolutionary.
As it stands, it's still definitely revolution-friendly :)
- there are strong, empirically tested usability reasons why a desktop-style UI is the pits on a mobile device
- generally, the move to mobile devices inclines to a different UI paradigm -- something finger-friendly and un-windowed (think iOS, Android, etc.)
- if there was a way that Puter could look kind of like a phone with some of the de-facto standard UI motifs and paradigms when it's on a phone, you could do cool shit like replace the Android shell with Puter, and have a pure web UI for your phone that runs web apps
- next step would be to add e.g. the ability to run Puter apps when offline, when reception is going in and out, etc. Sort of like Google Apps used to be (in Chrome)
- now you've got a cross-platform one-UI-to-rule-them-all breakout industry moment.
As it stands, Puter is already really cool, but if it turned into something that behaved a bit less like MacOS and a bit more like iOS at narrow resolutions, you'd have something that would make a lot of people very upset (and this is a good thing, they deserve to be upset)
I was a little surprised to see that it doesn't have the few extra tweaks necessary to work as a PWA in fullscreen mode: a manifest, some tags in the <head>, and CSS to lock down the body to prevent unwanted pinch zooming, scrolling and other gestures (which would also benefit the in-browser use case as well).
A proper mobile UI is something we're looking towards adding. It's been coming up in conversation more frequently lately and we'll probably announce on Discord when we start developing that.
Be careful. If they're paying attention (and you just buried the needle on HN, so assume they are,) you're about to make some very powerful people very nervous. There will be offers, I predict. Not all of them wholesome.
Ah, Puter! That fascinating project surfaced on HN about a year ago, claiming the top spot for most of the day. I'm delighted to witness its transition to open source, allowing us to glean insights from the creator. Gracias for sharing!
The emergence of such front-end projects provides a profound glimpse into the maturation of front-end development and showcasing the incredible possibilities it offers today.
Another really cool project, somehow related, is DaedalOS [2].
Thanks for the mention for daedalOS! I agree that when done well these projects can help demonstrate the maturity of the web as a platform. For anyone interested in checking out mine, it's on my personal website @ https://dustinbrett.com/
This is insanely cool! Looks really slick too, even in a mobile screen.
jQuery?? I cannot imagine how difficult it is to not break this when you make the slightest change, hats off for managing with vanilla Javascript and jQuery! The best thing about React for me is to not have to worry about breaking the DOM or messing up with event handlers because some jQuery line, somewhere obscure is probably doing something funky that is really difficult to track down!
Oh, wow. When this came up before, I don't know if I looked at the DOM, because I assumed you would do this type of thing by drawing pixels on a Canvas. It's actually made of HTML elements? That's impressive.
I too think it's very impressive but wouldn't it be even more impressive if it was made using canvas? It would mean that you would need to implement your own rendering loop and layout engine. You'd need to reimplement a lot of elements such as input fields or buttons. You get all of this for free when building on top of HTML/CSS.
I think it would likely be more technically involved and complicated if it were made with `canvas`.
But large blobs drawing to `canvas` aren't anything new at this point. The part that impressed me is doing it the simple way, using what the browser already provides, and getting it to work this well.
It’s not performant if you’re using JavaScript APIs. But it’s also possible to write to a canvas with WebGL, which is hardware accelerated and is much faster than jQuery. I believe (although I can’t find a source for it now), that xterm.js used this strategy.
You can easily shoot yourself in the foot with jQuery (or direct DOM manipulation for that matter), but it's not that hard not to. It just requires some discipline, like most things. React is also far from foolproof and not worth the added complexity in most cases, IMO.
That and types. The only framework that's useful to JS is a better static type check system (and none of this lets-make-the-whole-damn-runtime-slow to support X feature, looking at you TypeScript).
Not enums. But you don't need a runtime or function mutation for that...
Particularly egregious was (is?) async/await. Upgrade your browser/runtime/don't use it you say? Sure, but first two weren't always possible, and the third isn't possible unless you thoroughly vet your dependencies (easier said than done).
"Compiling to javascript" is all well and good if you actually just compile to normal javascript, as soon as you have any code that simulates other features (classes/objects/what-have-you) you are no longer "compiling to javascript". I mean yeah sure as a sort of intermediary assembly language you are but the performance is not the same. You have a new language with a runtime overhead, that now requires you modify the "core" language to bring in new features, which results in the underlying execution engines (browsers/cpus) becoming more complicated, power hungry, etc....
The performance wins for typescript likely source from the ability of the runtime to pre-allocate and avoid type checking.
Providing the type checks without using any non-JS features (and possibly providing the runtime some heads up regarding checks to safely drop) is the ideal.
You can disable those fallback implementations if you don't want to use them. Just use the javascript version you have available as the basis for your typescript. The option to look into the future shouldn't be treated as a negative.
And I still don't see how they make "the whole damn runtime" slow. You don't pay the cost for code that isn't using it.
Also I'm pretty sure the class implementation doesn't slow things down. It's a very simple transformation.
> You have a new language with a runtime overhead, that now requires you modify the "core" language to bring in new features, which results in the underlying execution engines (browsers/cpus) becoming more complicated, power hungry, etc....
I think you have this backwards. Typescript doesn't implement new Javascript features until their addition to Javascript itself is imminent.
The only feature Typescript wants to push onto Javascript is a syntax for type annotations, because then you can remove the compilation step entirely. At which point there couldn't even be a runtime overhead.
> non-JS features
To first approximation, there aren't any. The main one is the old enum syntax, which is why I brought them up.
> Typescript doesn't implement new Javascript features until their addition to Javascript itself is imminent.
I guess we want different things from Type systems.
I want rock solid guarantees that code is correct, so that the only thing left to test as much as possible is the business logic. I don't care about the latest programming fads, and I want stable, performant code.
You seem to just want some boilerplate guarantees and backwards compatibility.
If I were writing/creating TypeScript, I would be not implementing new features before JS upgrades, but long after (possibly as support libraries). I understand the goal of "easing" the transition, but IMO those sorts of "upgrades" should be late, not early, in a tool whose primary goal is static type checking, not JS features.
The things you seem to be worried about are configurable in the tsconfig. You can stay as polyfill free as you would like by instructing the Typescript compiler to error out instead of making the glue for you. Aside from the inescapable quirks of runtime JavaScript, Typescript felt pretty intuitive to me when transitioning to a new job from C# previously. Typescript with ESLint is about as solid as you’re going to get with JavaScript. I know that ideally there’d be something better, but in the real world right now this is the best it gets. At some point reality and business constraints are going to slam into ideations and things are going to get a bit dirty.
Aside from that, no matter what you pick, standard Typescript configs are absolutely compiling to JavaScript, not any other step in the interpreting process. It doesn’t matter if it’s taking your async/await and polyfilling it to run on an older browser engine… it’s still producing 100% JavaScript.
It goes Typescript -> JavaScript during the build, and the JS is what gets distributed to clients.
The JavaScript produced by TS is sent to the browser which performs the same JavaScript -> abstract syntax tree -> byte code -> execution, as usual
"standard Typescript configs are absolutely compiling to JavaScript"
You are missing the point. I want zero cost abstractions (for some level of abstraction - I accept e.g. there is a CPU and a browser). I don't care what it is compiling to.
Typescript is not a zero cost abstraction. (Zero cost meaning, here, that any overhead is incurred compile time only).
"The things you seem to be worried about are configurable in the tsconfig"
That's terrible. I want the Z.C.A. to be by-default, not "configure the heck out of the language to make it so".
We use a lot of typescript with a very opinionated setup on coding style and conventions, but that only goes so far when you’re dealing directly with the dom.
Because the dom is notoriously hard to work with. The internet is full of blog posts and articles talking about how slow it is as an example, but in reality adding or removing a dom node is swapping a pointers which is extremely fast. What is slow is things like “layout”. When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen. The layout algorithm is quite complex and it's synchronous, which makes it stupidly easy to make thing slow.
This is why the virtual dom of react “won”. Not because you can’t fuck up with it, but because it’s much harder to do so.
> When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen. The layout algorithm is quite complex and it's synchronous, which makes it stupidly easy to make thing slow.
Wait, you're saying it's synchronous but what exactly is being blocked here (since you also said the JS hands back control to the browser first)?
Only if you yield to the layout engine (e.g. `await new Promise(resolve => setTimeout(resolve, 0))`) in between. Which, if you know you want to change two things, why would you?
I’m not quite sure what it is that you’re asking. When you want to show something in a browser, you go through this process: JavaScript -> style -> layout -> paint -> composite.
The browser will construct a render tree and then calculate the layout position of each element/node in a process where it’s extremely easy to run into performance issues. And since the rest of the render pipeline waits for this to conclude, it’ll lead to very poor performance. You can look into layout trashing if you’re curious.
My point is more along the lines of how you can ask a lot of frontend engineers what the render pipeline is and how it works and many won’t be able to answer. Which isn’t a huge issue, because almost everyone who does complicated frontends either use a virtual dom or exclusive hire people who do know. But for the most part, you won’t be fine with just JavaScript for massive UI projects as the person I was replying to suggested.
This is one of the cool elements of the Synology operating system. Would be neat to see this extended further into other areas, using this as a base.
I setup a TrueNAS box for my dad recently and he was yearning for some kind of very light desktop environment for simple maintenance tasks. In hindsight I should have gotten him a Synology device.
When I was young I dreamed on having a USB stick (not yet invented) I could take with me to different kiosks and have a standard OS load my specific instances thanks to my custom key. This approaches that functionality and I think it's pure brilliance that you've included such thorough a demo for us to enjoy that you spent so much time and enthusiastic effort into creating and making manifest. So, I applaud you there and thank you for making it open-source that's super cool, and might inspire someone to make a kiosk that, by default, loads your site.
Nearly 20 years ago when I was in IT, I had something like this using a tool called BartPE which allowed you to make a custom WinPE environment that could be booted from a USB drive. As someone who went on to make one of these "web desktops", maybe things like BartPE were a partial inspiration.
About 30 years ago when I was a programmer and support guy all in one, I had an MS-DOS boot disk and a 300 Megabyte Backpack portable hard drive. It was awesome. I had all of the source code, backups of the customer sites data and my programming environment with me no matter where I went.
I randomly watched a scene from it on YouTube based on this comment, and in the background was a poster I never saw before that said "Trust Your Technolust", and just like that, I have my new life motto LOL
These two posts have awoken old memories for me, because I used BartPE and I had a "magic" bootable MSDOS diskette.
I remember I also created a custom Windows NT build for a company I worked for around 1999. They had about 6 different models of Compaq workstation, and a dozen different departments. They had a disk imaging solution, rather than implement automated pxe builds. That's fine, except that nobody in the team had any "craft". Because NT isn't plug and play and each department had different software, we had about 20+ NT images, each with its own personality (ie major flaws, like hard-coded WINS servers, being already joined to a domain, old user profiles, broken software installations, old drivers). The day I joined the team, the phone rang constantly from 8am to closing time. If you walked around the building to do a desk visit, 20 people would shout at you, "hey IT guy, take a look at this PC, will you?". Coming from a hardware support background I had installed MS stuff thousands of times and got my MCSE, but Lotus Notes, Sunguard, Bloomberg and their awful VB6 apps (unpackaged collecting of dlls and instructions) had a short learning curve. After I figured that stuff out I created a single NT build with everything working perfectly. I cleaned up, defragged, ran sysprep. It used NT's hardware profiles to make the build work on any model of desktop (which just required imaging a new model, creating a profile for it and installing all the drivers. Rinse and repeat 6 times). Then I burned the highly compressed NT image along with ghost.exe onto a CD, and handed copies to the other 2 helpdesk guys. Anyone who called IT over the few weeks, regardless of their issue, got a rebuild. Result? Immediate reduction in workload. So we proactively worked through the whole company. Things were so tranquil afterwards, we could go around to department heads asking if there was any "real" IT work that needed to be done.
It's an Austrian LiveCD based on Debian; version 2024.02 was just released. It's not as slick as Knoppix, but it does come with lots of utilities and can start an X Windows desktop.
For some reason I'd assumed this was the kind of thing that the original Mac Mini would morph into, but of course I was wrong. Searching for "PC Stick" shows up some interesting options.
I would dearly love to find a use-case for this[0], which with a USB-HDMI might work almost as well
What I'd really love is a net boot image and remote storage that can be mounted on the fly on any computer. All I'd need is my yubikey or whatever secure identifier to connect all the pieces.l and plenty of internet.
I'm partially there with VDI tools like Parsec, but being able to leverage local hardware would also be neat.
Is Samsung Dex able to boot/load to a standard Linux environment? Initial look at it seems interesting, but I've never really heard/seen much about it.
It depends on what a standard Linux environment is and what you will need it for. I mean Android is some kind of Linux and with Termux you can get it a bit more Debian-like from a terminal perspective. But I haven't seen anybody start a KDE or Gnome with it.
My biggest issue with Dex is that it can manage only one large display. So if you have two, they are just being cloned. Otherwise, I like to use it sometimes when I don't want to start my PC.
This is such a neat idea, and you get the gist of it from just the screenshot. I wonder what kinds of 'integration' you could do (clipboard, opening links, drag-and-drop, etc). I could see this as an educational tool for doing development on a Chromebook, because of the (emulated) terminal + filesystem.
Indeed the modern Web API's can do all that and more. One of my favorites is dragging out of the browser onto the desktop. Another is ctrl+c'ing a file on the real desktop and then ctrl+v'ing it into the "fake" one. Some super powers sadly are locked away in the need for a PWA, but I think they could one day just be part of what any site can do.
Technically it's not developer mode , it's just a regular feature of the OS. "Developer Mode" on ChromeOS is when you remove boot verification for ChromeOS itself.
And this anuraOS[0] too! I haven't looked to closely at it (it showed up in my GH feed) but it looks like it uses v86[1] to emulate a *nix environment.
347 comments
[ 3.2 ms ] story [ 318 ms ] threadjQuery is overdue for a comeback.
https://krausest.github.io/js-framework-benchmark/current.ht...
Virtual DOM still needs to reconcile and apply DOM updates, but since this is handled by your UI framework of choice you have limited ability to optimize these updates.
See benchmarks: https://krausest.github.io/js-framework-benchmark/current.ht...
I would argue that if performance is your top concern you'd still be better off using a framework like SolidJS, but theoretically JavaScript and JQuery can be better optimized.
For most web apps, the initial layout and rendering take the biggest portion of the rendering budget. Subsequent changes are minimal and can be rendered very fast. If you can avoid re-rendering the whole page for every little change, the update can be fast.
React's advantage is to track the changes for you. That doesn't mean you can't track the changes yourself. And if you structure your rendering and refreshing pipelines correctly, vanilla JS would do just fine if not better.
How does it handle things like privilege escalation and sandboxing?
I'm assuming you mean remote access for a user account like a terminal server as opposed to server management.
Is that the case?
https://news.ycombinator.com/item?id=32233087
Seems like it might confuse normal folks though—a desktop in a browser. What do y'all think?
https://www.switchboard.app/
Knowing how difficult it is to build something like this, Puter definitely deserves praise.
We use it daily for things like standups, sprint planning, all hands, operations dashboards, product roadmap discussions, dungeons and dragons sessions, watching videos together and more.
This way you have the experience of sitting in front of your computer while wearing a VR headset anywhere in the world.
“ - Why isn't Puter built with React, Angular, Vue, etc.?
For performance reasons, Puter is built with vanilla JavaScript and jQuery. Additionally, we'd like to avoid complex abstractions and to remain in control of the entire stack, as much as possible.
Also partly inspired by some of our favorite projects that are not built with frameworks: VSCode, Photopea, and OnlyOffice.
- Why jQuery?
Puter interacts directly with the DOM and jQuery provides an elegant yet powerful API to manipulate the DOM, handle events, and much more. It's also fast, mature, and battle-tested.”
This kind of reaction reminds me of people who can’t fathom why anyone would use a database without an ORM. (And meanwhile I’m confused because nearly everything I do with a database would be twice as difficult and ten times slower with an ORM in the way.)
I used to hate ORMs like you. But auto generated types were the killer feature.
That's not the point. The point is that it doesn't use a framework like React, Vue, etc., it instead directly creates and manipulates DOM elements, somewhat like Puter.
OnlyOffice works better than LibreOffice, which is a native app.
Photopea works better than GIMP, which is a native app.
These devs clearly know what they're doing.
React and all the packages you champion were created to foster job security by introducing needless complexity and performance issues.
It would be a better world if we had more Photopeas and less Enriques
Like very nearly all FOSS, they were created to scratch their own developers' personal itches.
> ... and how to actually use them.
Their itches are not the same as everyone else's itches.
Really nicely done.
I've been using this as a way of quickly putting a UI over an EC2 instance.
Could you advise on how you'd do the equivalent here? Eg., say I want to provide an EC2 machine with various packages installed (python, node,...) -- or, the equivalent docker image -- is there a way of using your UI to provide access to this?
Consider, eg., using an iPad with your UI in a browser. Could you advise a way that this could provide a complete development experience for datasci/seng? (As above, i'm using theia to do this in a quick-and-disposable way).
Is there a mobile mode coming?
This would be dope af if I could get a mobile-esque UI on mobile-like devices, or opt into one on tablet-like devices.
In all honesty, this is perfect for people like me (who are rarely away from a keyboard) but less than ideal for people who live a more 21st century computing lifestyle.
If this thing had a mobile mode it would be revolutionary.
As it stands, it's still definitely revolution-friendly :)
What I mean is:
- there are strong, empirically tested usability reasons why a desktop-style UI is the pits on a mobile device
- generally, the move to mobile devices inclines to a different UI paradigm -- something finger-friendly and un-windowed (think iOS, Android, etc.)
- if there was a way that Puter could look kind of like a phone with some of the de-facto standard UI motifs and paradigms when it's on a phone, you could do cool shit like replace the Android shell with Puter, and have a pure web UI for your phone that runs web apps
- next step would be to add e.g. the ability to run Puter apps when offline, when reception is going in and out, etc. Sort of like Google Apps used to be (in Chrome)
- now you've got a cross-platform one-UI-to-rule-them-all breakout industry moment.
As it stands, Puter is already really cool, but if it turned into something that behaved a bit less like MacOS and a bit more like iOS at narrow resolutions, you'd have something that would make a lot of people very upset (and this is a good thing, they deserve to be upset)
Remember Windows CE? We've been down this road -- a windowing desktop on a phone is... hard to use, actually.
But still, really incredible work.
Be careful. If they're paying attention (and you just buried the needle on HN, so assume they are,) you're about to make some very powerful people very nervous. There will be offers, I predict. Not all of them wholesome.
The emergence of such front-end projects provides a profound glimpse into the maturation of front-end development and showcasing the incredible possibilities it offers today.
Another really cool project, somehow related, is DaedalOS [2].
Honorable mention, Windows 11 in Svelte [3]
1. https://news.ycombinator.com/item?id=33838179
2. https://news.ycombinator.com/item?id=38830132 & https://news.ycombinator.com/item?id=29779753
3.https://news.ycombinator.com/item?id=35896505
jQuery?? I cannot imagine how difficult it is to not break this when you make the slightest change, hats off for managing with vanilla Javascript and jQuery! The best thing about React for me is to not have to worry about breaking the DOM or messing up with event handlers because some jQuery line, somewhere obscure is probably doing something funky that is really difficult to track down!
But large blobs drawing to `canvas` aren't anything new at this point. The part that impressed me is doing it the simple way, using what the browser already provides, and getting it to work this well.
As a reference, here is a browser-adapted version of the https://cuis.st/ Smalltalk environment, which does its own rendering onto a canvas:
https://github.com/nmingotti/The-Cuis-CookBook/wiki/Run-Cuis...
Working within the confines of HTML is way more impressive to me.
That and types. The only framework that's useful to JS is a better static type check system (and none of this lets-make-the-whole-damn-runtime-slow to support X feature, looking at you TypeScript).
TypeScript runtime? I don't think the deprecated code that sets up enum objects affects anything else...
Particularly egregious was (is?) async/await. Upgrade your browser/runtime/don't use it you say? Sure, but first two weren't always possible, and the third isn't possible unless you thoroughly vet your dependencies (easier said than done).
"Compiling to javascript" is all well and good if you actually just compile to normal javascript, as soon as you have any code that simulates other features (classes/objects/what-have-you) you are no longer "compiling to javascript". I mean yeah sure as a sort of intermediary assembly language you are but the performance is not the same. You have a new language with a runtime overhead, that now requires you modify the "core" language to bring in new features, which results in the underlying execution engines (browsers/cpus) becoming more complicated, power hungry, etc....
Anyways, type caching is not all bad. While the TS overhead is likely responsible for the performance wins for javascript in the following chart: https://programming-language-benchmarks.vercel.app/typescrip...
The performance wins for typescript likely source from the ability of the runtime to pre-allocate and avoid type checking.
Providing the type checks without using any non-JS features (and possibly providing the runtime some heads up regarding checks to safely drop) is the ideal.
And I still don't see how they make "the whole damn runtime" slow. You don't pay the cost for code that isn't using it.
Also I'm pretty sure the class implementation doesn't slow things down. It's a very simple transformation.
> You have a new language with a runtime overhead, that now requires you modify the "core" language to bring in new features, which results in the underlying execution engines (browsers/cpus) becoming more complicated, power hungry, etc....
I think you have this backwards. Typescript doesn't implement new Javascript features until their addition to Javascript itself is imminent.
The only feature Typescript wants to push onto Javascript is a syntax for type annotations, because then you can remove the compilation step entirely. At which point there couldn't even be a runtime overhead.
> non-JS features
To first approximation, there aren't any. The main one is the old enum syntax, which is why I brought them up.
I guess we want different things from Type systems.
I want rock solid guarantees that code is correct, so that the only thing left to test as much as possible is the business logic. I don't care about the latest programming fads, and I want stable, performant code.
You seem to just want some boilerplate guarantees and backwards compatibility.
If I were writing/creating TypeScript, I would be not implementing new features before JS upgrades, but long after (possibly as support libraries). I understand the goal of "easing" the transition, but IMO those sorts of "upgrades" should be late, not early, in a tool whose primary goal is static type checking, not JS features.
Aside from that, no matter what you pick, standard Typescript configs are absolutely compiling to JavaScript, not any other step in the interpreting process. It doesn’t matter if it’s taking your async/await and polyfilling it to run on an older browser engine… it’s still producing 100% JavaScript.
It goes Typescript -> JavaScript during the build, and the JS is what gets distributed to clients.
The JavaScript produced by TS is sent to the browser which performs the same JavaScript -> abstract syntax tree -> byte code -> execution, as usual
You are missing the point. I want zero cost abstractions (for some level of abstraction - I accept e.g. there is a CPU and a browser). I don't care what it is compiling to.
Typescript is not a zero cost abstraction. (Zero cost meaning, here, that any overhead is incurred compile time only).
"The things you seem to be worried about are configurable in the tsconfig"
That's terrible. I want the Z.C.A. to be by-default, not "configure the heck out of the language to make it so".
Don't you just set target? Is there even a default for target?
TypeScript enums are deprecated now? I mean, yeah, they aren't great and should best be avoided but the deprecation would be news to me.
See also https://stackoverflow.com/questions/70661260/are-typescript-...
Because the dom is notoriously hard to work with. The internet is full of blog posts and articles talking about how slow it is as an example, but in reality adding or removing a dom node is swapping a pointers which is extremely fast. What is slow is things like “layout”. When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen. The layout algorithm is quite complex and it's synchronous, which makes it stupidly easy to make thing slow.
This is why the virtual dom of react “won”. Not because you can’t fuck up with it, but because it’s much harder to do so.
Wait, you're saying it's synchronous but what exactly is being blocked here (since you also said the JS hands back control to the browser first)?
(updating innerText sounds like an especially lethal trap https://source.chromium.org/chromium/chromium/src/+/main:thi... )
The browser will construct a render tree and then calculate the layout position of each element/node in a process where it’s extremely easy to run into performance issues. And since the rest of the render pipeline waits for this to conclude, it’ll lead to very poor performance. You can look into layout trashing if you’re curious.
My point is more along the lines of how you can ask a lot of frontend engineers what the render pipeline is and how it works and many won’t be able to answer. Which isn’t a huge issue, because almost everyone who does complicated frontends either use a virtual dom or exclusive hire people who do know. But for the most part, you won’t be fine with just JavaScript for massive UI projects as the person I was replying to suggested.
I setup a TrueNAS box for my dad recently and he was yearning for some kind of very light desktop environment for simple maintenance tasks. In hindsight I should have gotten him a Synology device.
Great stuff!
Just need to get the right color for your paper stock!
I remember I also created a custom Windows NT build for a company I worked for around 1999. They had about 6 different models of Compaq workstation, and a dozen different departments. They had a disk imaging solution, rather than implement automated pxe builds. That's fine, except that nobody in the team had any "craft". Because NT isn't plug and play and each department had different software, we had about 20+ NT images, each with its own personality (ie major flaws, like hard-coded WINS servers, being already joined to a domain, old user profiles, broken software installations, old drivers). The day I joined the team, the phone rang constantly from 8am to closing time. If you walked around the building to do a desk visit, 20 people would shout at you, "hey IT guy, take a look at this PC, will you?". Coming from a hardware support background I had installed MS stuff thousands of times and got my MCSE, but Lotus Notes, Sunguard, Bloomberg and their awful VB6 apps (unpackaged collecting of dlls and instructions) had a short learning curve. After I figured that stuff out I created a single NT build with everything working perfectly. I cleaned up, defragged, ran sysprep. It used NT's hardware profiles to make the build work on any model of desktop (which just required imaging a new model, creating a profile for it and installing all the drivers. Rinse and repeat 6 times). Then I burned the highly compressed NT image along with ghost.exe onto a CD, and handed copies to the other 2 helpdesk guys. Anyone who called IT over the few weeks, regardless of their issue, got a rebuild. Result? Immediate reduction in workload. So we proactively worked through the whole company. Things were so tranquil afterwards, we could go around to department heads asking if there was any "real" IT work that needed to be done.
That one disk, man.
[1] https://en.wikipedia.org/wiki/Micro_Solutions_Backpack
It's an Austrian LiveCD based on Debian; version 2024.02 was just released. It's not as slick as Knoppix, but it does come with lots of utilities and can start an X Windows desktop.
Data recovery... virus removal... diagnostic tools... the works.
I would dearly love to find a use-case for this[0], which with a USB-HDMI might work almost as well
0: https://store.planetcom.co.uk/collections/gemini-pda/product...
I'm partially there with VDI tools like Parsec, but being able to leverage local hardware would also be neat.
https://netboot.xyz/
https://github.com/netbootxyz/netboot.xyz
https://netboot.xyz/
https://github.com/netbootxyz/netboot.xyz
My biggest issue with Dex is that it can manage only one large display. So if you have two, they are just being cloned. Otherwise, I like to use it sometimes when I don't want to start my PC.
[1]: https://desktop.kerahq.com/
[2]: https://news.ycombinator.com/item?id=36260589
[0]: https://github.com/MercuryWorkshop/anuraOS [1]: https://copy.sh/v86/