The predictions from Gary Bernhardt seem to really be true, in the future everything will be javascript.
I wonder if somebody actually tried to make an OS that only has a browser, that's what Chrome OS actually is, after all.
https://videohubapp.com/ & https://github.com/whyboris/Video-Hub-App
As a single developer, I was able to get an app out in a few months and have been improving it for 4 years now. I love it (enough to create a Renamer app too: https://yboris.dev/renamer/ ).
For an example. I'm writing a FOSS app mainly for myself, but i am publishing it for everyone of course. I want to support Browsers, but also "Apps" in OSs. I'm on Linux, MacOS, Windows and iOS every day.
I do not, by a large margin, have the time to write my application in 3 or 4 different native UI toolkits. Furthermore, my application has a lot of text editing and rendering functionality, one i'd have to then reinvent in various UI toolkits, unless i used something that crossed all OSs above perfectly. Finally, my app has WASM plugins, similar to Obsidian.md, to allow the user to easily extend the application.
All together i will not, by a large margin, use anything Native. I barely have enough time _(don't, honestly lol)_ to write the app once - let alone supporting all the above platforms.
I'm targeting the web.
As an aside, i'm writing this in 100% Rust lol. No JS, because i prefer Rust.
DX directly drives engagement and retention, and good developers are hard to find (and keep!).
And like it or not, there are more and more developers entering the industry with web-only training, so we have products that reflect the stack and tooling those developers are most proficient with.
- language: ES / Typescript are quite established
- CSS: also quite established
- Frameworks: there is still a lot of innovation here, but also React / Vue / Angular are quite established.
on that latter part I prefer the innovation. Let's just imagine for a while what UI would look like if we only had Swing (Java) or QT (C++)
I can easily imagine that, because that's more or less what we had before Electron. And it was much better, because apps (mostly) looked consistent across the OS, rather than each and every one coming up with its own custom UI theme.
As for the stability of the front-end ecosystem, it doesn't exist. The many articles that were posted on HN over the years complaining about the endless quagmire of front-end frameworks, libraries and technologies explain this better than I could.
yes, Telegram looks so bad right ?
https://github.com/electron/electron/blob/main/LICENSE
So everyone can use it without the need to expose his IP.
See for instance one of the most core Blink data structures: https://chromium.googlesource.com/chromium/blink/+/refs/head...
That is the exact same license than Qt, you do not need to expose your IP when using it (Tesla used LGPL Qt for their car dashboards and you don't see that IP floating around on the internet)
> more and more developers entering the industry with web-only training
aren't these very different things? Is Electron popular because web-skill are so common, or because the dev experience is better - I sceptical of the latter, as I find JS very dependant on framework/ecosystems for compatibility.
Electron improves DX for all the usually stated reasons (build once for many platforms, etc) but I do think there is a connection to the fact that a lot of developers out there are learning web tooling, and if a company wants to put out a desktop app in 2022, it's an easier (and therefore better for DX) path to use something like Electron or Tauri - where devs can use the skills they already have - than try to either upskill or hire a team that can build native apps on all your desired platforms.
Not working on iOS
This is what happens when you keep lowering the bar, and more and more developers can do less and less.
There simply aren't enough developers over the entire range, and certainly not enough with decades of experience, for all the work that can be done.
Renting additional servers, etc is cheap and easy compared to hiring additional developers. So we all optimize for that.
There are just two of us building this product.
[1] To help provide more context: https://supernotes.app/
I wonder if someone can quantify the carbon impact of Electron just from Slack.
And yet, to the people who do use their app on the desktop, this is obviously a preferable situation to not using the app – which would probably be the case had the developers decided against Electron.
Writing native apps (or a Qt app) would well be in reach of Slack. In fact, they already have native apps. E.g. Slack for iOS/iPadOS is native [3], just allowing M1 Mac users to use the iPadOS version would most likely be a large net improvement in resource use for those who'd choose to install the iPadOS version. Unfortunately, they disallow iPadOS installs on macOS to force people to use the terrible Electron version.
[1] https://cancel.fm/ripcord/
[3] https://twitter.com/slackhq/status/931599784137363459?lang=e...
Because I can honestly understand going cross-platform by a small startup that can’t finance n*numOfPlatforms devs, but for Slack and the like it makes zero sense to me.
It makes perfect business sense to use electron. It opens paths which otherwise would be very costly and hence infeasible.
I would rather have one team developing a cross-platform application in a language that isn't Javascript.
Perhaps Unity? But that's more tailored for 3d scenes, rather than UI widgets.
Genuinely looking for suggestions on what is the best choice to pick there.
So, use one of the many languages that compile to JS. Starting with TypeScript. Or (alphabetically) ClojureScript, Elm, PureScript, or Rescript.
Should I not use anything that uses ML if I dislike python?
Would that work?
I am not a front end kind of developer, I am a "plumber". So it is a genuine question.
No-one wants 'three teams building one product' which is why it almost always is far better to have one team with android, iOS, web and desktop mixed. Obviously if their mixed erpertises are around one codebase, that is even better.
In many cases, it should also make perfect business sense to use PWAs. I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps.
This is true. We managed to wrap a very large portion of the desktop code base into a “portable” library (with some customization at the point the library hits the OS, e.g., file IO.) This library is compiled specifically for the OS it’s going to run on (iOS, Web) to give us the best performance we can muster.
The UI for each implementation is bespoke. This lets us build native interactions on the platforms we ship to, giving the end user the best look-and-feel for the platform they’re on. The flip side to this is development cost and time. In the long run, we believe it is worth it.
Rewriting Photoshop in Electron would have been infeasible and the performance hit a non-starter. The path we’ve taken has some trade offs to it, but is the right one given the legacy tech we have and what we want to do with it.
Windows 10, pulling in part of an engineering drawing from a PDF (so many thousands of objects).
To wit: I’m known on the team for sussing out information from corrupted PSDs, and get called on about once a quarter to look into a bad file that’s come in. That wouldn’t happen as frequently without the community site.
(1) Branding. Businesses want their app to be thoroughly branded, so they'd rather have a canvas where they can invent their own buttons than use something cross-platform native like Qt.
(2) Hiring. Existing developer base trained on webtech. Qt is a C++ thing - there's a far greater hiring pool for webdevs than C++ devs.
(3) Ignorance. Some developers don't really know that Qt exists, or want to go through the trouble of learning it.
None of these reasons benefit the user - but Electron isn't chosen by those who want to benefit the user in the first place.
Web development tools have become fantastic UI debugging tools. You can inspect live running UI and tweak it in real time without a rebuild.
CSS is very powerful, and it's relatively easy to build complex layouts with animations. People joke how it's impossible to center things, but CSS has matured beyond that (IE is dead).
That said, I've mentioned WPF mostly because that's what I'm personally familiar with. The same inspector-type tooling is available for newer XAML-based frameworks, as well:
https://docs.microsoft.com/en-us/visualstudio/xaml-tools/ins...
Web tech (HTML, JS & CSS) are widely understood with millions of tutorial reference. On top of that, you get a cross OS build that looks the same everywhere.
If all you are paying are just CPU and RAM, then that is a great tradeoff.
What do you mean then, how does the hypothetical OS differ from ChromeOS?
I've had direct experience with this myself - with no prior Qt or webdev experience (although knowledge of how JS the language works), it took me only around an hour to figure out how to write a Qt application - but after 5 hours (and counting) of struggling with Angular, I wasn't able to figure out how to use it.
That's a different penalty. Qt doesn't really compare with what can be done with a good UX/UI dev on the team, and in much less time. And there are far more front-end devs than Qt experts.
Those are orthogonal. UI/UX is platform-agnostic - if you're only developing Electron UIs, you're not actually good at UI/UX.
> in much less time
Are you telling me that an Electron developer will be able to implement a system significantly faster than an equally-experienced Qt developer?
> there are far more front-end devs than Qt experts
You don't need to be an "expert" to use Qt - it has a relatively simple API for simple use-cases - it's not rocket science or distributed computing.
Yes. Hands down.
I'm actually saying two things: there are far fewer Qt developers, and the learning curve is much steeper. This has huge impact on maintaining and improving the code. We started with Qt and abandoned it because it is way easier to bring someone new in and get them started than having someone climb the curve to learn Qt and C++. Plus spinning up new features in Qt is laughably slow compared to how quickly a frontend dev can do the same in Electron: the former takes days, the latter is practically interactive.
It was such a clear choice to abandon Qt.
I was primarily worried Electron wouldn't last long, but we wrote our first app with it 6 years ago and it has remained completely stable. The biggest dev hits have been in Node peripheral support as they get better, like BLE and serial port interfaces.
To what extent is Electron's popularity due to getting cross-platform availability without writing your code 3x?
The advantages of a native app have to be worth the costs... and I'm seeing plenty of Electron apps so there's a lot of people making that cost-benefit tradeoff.
I share the dislike for bloated apps... but every time my stuff takes 10 seconds to start up I think more about keeping it running the whole day than submitting a PR to remove cruft.