Orb is a free and open source web desktop
gitlab.com
gitlab.com
https://gitlab.com/hsleisink/orb/-/blob/master/public/apps/e...
https://gitlab.com/hsleisink/orb/-/blob/master/public/apps/e...
I mean, let's be real; most of what people were using jQuery for was stuff like `querySelector`, `closest`, `classList`, etc... For those people, pure Javascript is JQuery now. If you don't want a framework and you don't want reactive/declarative interfaces, then you probably don't need a library.
I would say the same thing (maybe to a lesser degree) about "standard" libraries like Lodash. Native Javascript has a `reduce` function now, it's widely supported. And if you have to target any of the very few browsers that don't have it, then polyfilling is (usually) the better choice. See also Blueberry and promises; just use JS promises, they're fine.
I picked up jQuery because JS in browsers weren't cross-compatible for ages. I don't see a need to stop unless jQuery stops being cross-compatible.
So, it's not needed anymore. I also started using jQuery in order to get cross-browser support for handy stuff, but since that stuff is now cross-browser without using any 3rd party libraries at all, there is no need to use extra bandwidth and CPU cycles from your users to download something that basically already exists.
There are many reason not to use Jquery for greenfield projects now, but bandwith is not one of them.
The first is thankfully not needed anymore, the second hasn’t been matched in simplicity and power by the native one, unfortunately. Not by a long shot.
If you don’t believe me, check out one of the “You Might Not Need jQuery” sites. They read much like “you might not need firelighter, stones and sticks are all you need”.
EDIT: oh, I just realized that's exactly what you were saying!
I usually do something like:
const $ = function(selector) { };
at the start of every project, implement document.querySelectorAll, then return an object with a handful of functions like on(event, callback), off(event), one(event, callback), attr/data/prop(name[, value]).All of them are basically just tiny <10 LOC shims for a lot of built-in functionality. But that way I still get the niceness/terse-ity of jQuery, but not the bloat and overhead of it being able to still do:
$('.selector').one('submit', () => false)
is a lot nicer than document.querySelector('.selector).addEventListener('submit', () => false, {once:true}).You're not wrong about logos, but I find that webp will often squish that sort of thing down to 10-15k.
It's a reasonable argument to make that minimizing 3rd-party library use is premature optimization for most websites, but if you get to the point where you need that optimization then it is 30kb and it won't be cached (CDN caching is a myth, CDNs are only useful for minimizing server load/response-time they aren't shared between domains) and it will block your initial app logic.
I am sympathetic that worrying about 30kb is overkill for a lot of apps. But if you are in a position where you're really optimizing for speed to the point where even megabytes matter, then those 30kb are not cached and they block page logic from executing until they're downloaded. And that remains true even if there's another performance change that would be higher impact that you're not allowed to make.
If anything, being not allowed to reduce asset size for your website would make efficient JS bundling matter more, since it's one of the few resource bundles you'd be allowed to do something about and it would be pulling double-duty to try and slightly cover for the inefficient fetches that you can't change.
Would it only depends on my own preferences, I would use only letters and dash for any identifier in code bases I work with.
The fact that you have to distinguish between literal strings and interpolated values
String formatting functions use special strings themselves.
You mean fashionable?
> Perhaps we have sunk too deep into the SPA/API rabbit hole that we can no longer appreciate simplicity
I’m certain of it.
For large organisations it's easier to manage a team of workers with narrow specialisations than a single, but almost equally productive developer like here.
It's particularly visible in banking applications, where modules are almost completely independent and built by non-overlapping teams, so they take forever to load due to the limitation on concurrent requests in browsers.
Most of them are classic multi-page PHP apps. It's terrible. I can't stand how it always reloads each time I click on something. I remember it didn't bother me much in the past when everything was like that, but today we have much better options.
I went for a SaaS built as a SPA. When I click on something, for example to create a new entity, I get a modal/side-panel immediately. When I want details, I get them much quicker and can return back to the listing immediately.
> It's particularly visible in banking applications, where modules are almost completely independent and built by non-overlapping teams, so they take forever to load due to the limitation on concurrent requests in browsers.
They just can't code SPAs well. It's perfectly possible to have both quick loading times and very separate modules.
They're visibly snappier than server-rendered frontends, or even frontends with JS sprinkled on top when done correctly, but large organisations generally don't do them correctly.
And yet here you are, using HackerNews just about every day, which works exactly the same way. No SPA. No 'forever loading', just a classic, fast SSR webapp that treats individual pieces of content as documents, just like how the web was designed to work.
It also doesn't bother me much on here because HN is much faster than these systems - no wonder, since it's just a forum. But try updating the details of 50 employees, each separated into 5 subpages, when you need to wait 750ms to have each page load. And you need to load that page multiple times - first to get into the detail, then to put it into "edit" mode, then to save it - and then you can switch to a different subpage of the detail.
Wait, what? If it's taking most of a second for a page to load, then that's the problem, not that it isn't a SPA.
Using the phone that's very annoying. I have to long press on the entry's link on the header, open in a new tab, recheck the message trail, and go back to the first tab to end writing.
So simoly as that, I could think of lots of times where a SPA-style dropdown editor box inserted in the conversation view, would be more useful than the current HN's reply page.
If the reply page contained the whole discussion, though, the problem would be equally solved too. So I'm not saying that an SPA would be 100% better, just mentioning an example that occurred to me.
Considered by whom?
No one is forcing people to use React, Svelte, Vue, etc. The sentiment of wishing for a simpler time has never felt right to me, cause no one is policing what people use. If you feel like people are forcing you into frameworks, I’m sorry, and I feel like I have a piece of advice.
If you truly believe a framework isn’t worth it, tell your team why. You might be right, and you might be wrong.
I’ve worked at large and small companies; discussions about what technologies to use have always been welcome. I’ve advocated for and won when making a case for “simpler solutions,” when it makes sense.
All that said if you think using a framework framework === complexity for the sake of complexity, you’re wrong. OP I’m not saying you think this, but I have to imagine that it’s the sentiment of at least part of the folks who made this the top comment.
This is definitely a taste thing
It was called MDI: <https://en.wikipedia.org/w/index.php?title=Multiple-document...>
Without their desktop thing, this would just be "open link in new tab" for the apps you want open at the same time.
Spatial file navigation & manipulation might be the one reasonable reason for the fake desktop.
What sucks is, you need a whole browser for it. What sucks is, I think that's the only way to do it. A full on VM to make it real.
I would use this if the browser stack had more promise of not changing for 50 years and not owned by Google. Unfortunately our last place of freedom is native execution.
BTW, I've been out of touch with PHP for years. How are its performance and security these days?
[1] https://gitlab.com/hsleisink/orb/-/blob/master/screenshot.jp...
As in basically any web app development... mostly independently of the chosen implementation language. PHP hast lost its insecure beginnings (like injecting variables using GET arguments...) since long.
Note to developer: you may want to add an `onbeforeunload` handler
I'm talking about something made purely in HTML + CSS + JS. Something like this: https://macos-web.app/
If only these could support native Linux apps somehow (through a WM).
Exactly what I was stating to GP (or implying, now that I read it over) — pretty sure Flutter is OpenGL or <canvas> or etc, and not outputting to HTML or some DOM like React et. al. are doing.
The OS is also designed to run on mobile devices, so there's some cross-platform consistency between the system on desktop and mobile devices.
It's currently designed to run web apps, but the hope is to also include support for typical Linux GTK and Qt apps (or any app that uses Xwindows) soon to aid daily driveability.
The current release can't do much yet, but we'll be releasing our next Alpha version in about a week or two which include a few more useful features on top of what's already available on our site!
We currently release all Alpha versions onto our site at https://liveg.tech/os/get, so there's no need to 'wait' as such to try out the system in its current state! As for being notified as to when we'll release the next version, we normally let everyone know through Mastodon, as well as on other social networks such as YouTube and even (dare I say it) Twitter — sorry, I mean X.
But it might be worth us setting up some sort of email-based notifier to let people know when new releases are available, so I'll take your advice onboard!
One idea I am playing with is the idea of "thunking" behaviours on a graphical user interface by chaining together operations, like a typed runqueue. You can interact immediately with what is on the screen but you are presented with options as if the operation was successful and then you can queue up the next thing based on the result of doing that.
EDIT: The idea is that we decouple updates of the GUI with execution and the types of the return values of previous operation. In other words, the types of every operation are known by the system in advance, so you know what data is available at any given point in time.
A desktop which is like a real time strategy game.
I realize there's a demo, but what if I'm on mobile and I'm just curious as to what the project looks like; or what if I just want to see what it looks like before I try it out?
Is it a nerd thing, where we're just kind of wrapped up so far in our own projects that we forget such a basic thing? Why does this happen so often? Genuinely asking.
Shouldn't this have put Citrix et al out of business?
You are right that citrix should be able to dumb down what they have to basically a glorified web application that accesses their servers. Which apparently is a thing for obvious reasons (as in they thought of that too, many years ago).
Despite having VNC in its name, it isn't fully compliant with the VNC protocol and doesn't support regular VNC clients. Instead, it exposes a web client that you can access to connect to the machine. It also felt surprisingly snappy and nice to use compared to my previous experiences with regular VNC.
Unfortunate, because this looks nice.
Demo site: https://desktop.leisink.net/
That being said, quite nice and responsive. Not sure yet what the general purpose desktop metaphor solves in-browser, but nice nonetheless.
No screenshots or docs of any kind linked to, just a demo, becuase "The demo account has temporarily been closed due to abuse. Come back soon."
This is one reason why screenshots and docs are good!