> People are using Electron because they don't have the resources to make a Desktop app otherwise.
This may be true sometimes, but this just IS NOT true broadly and dismisses the notion that building desktop applications with Electron is *preferable* for nearly everybody.
Slack is one of the most well funded startups in San Francisco.
Microsoft is a publicly traded company with deep pockets and more "native" desktop experience than any company on the planet.
Electron is NOT being used due to a lack of resources, it's being *chosen* on merit.
The MS example is really useful here, since their penetration into the Linux + macOS dev space, by using Electron, has been unlike anything they've tried before. Really smart on their part.
It will be interesting to see what the Skype (and Slack) desktop teams ends up doing in the next few months. Threading model issues come to the fore with video/audio collaboration that requires low latency, synchronization, and reasonable battery life all at the same time.
Thank you, this has to be said. Electron-based VSCode and Electron-based Atom are beating out everyone else, including native, on their own merit: look n' feel, features, extensibility, release cadence…
Don’t ignore the security architecture problems. They are serious. My high level MS contacts were concerned enough to contemplate kicking Electron apps out of the Win10 store. I do not know where this stands, will hope to find out late this month.
Security issues should be fixed, no doubt, but what is clear is that developer prefer the experience of building and maintaining an Electron app over all the alternatives.
Not just “issues”, architecture problems. Turning off sandbox, mixing Node.js trusted code with potentially untrusted code, lack of defense in depth, lack of PoLA.
(I hope this isn't _tu quoque_!)
The architecture problems are specific to Electron. Native apps can have mundane bugs & arch problems too, but native app w/o unsandboxed chromium (or w/ sandboxed and no Node.js in the sandbox) has different & lower risk profile, all else equal.
Look nobody cares what the devs like to dabble in if a program literally takes gigabytes of ram and eats cpu just to display some text and some images. You know what could also display text an images? An Apple II. Slack is really a typical example of SV dev snowflakeism.
Slack doesn't even do its heavy processing on client side. No searching, no databases, no multi-party networking. It's literally just a screen for a remote process. And they have failed miserably at making it anywhere near acceptably performant because yeeeah 👍👍👍electron👍👍👍
It's literally just irc + images, formatting, and a few other small features. My c64 ran irc, with a hand soldered modem. A hobbyist wrote the client. And Slack with their millions and hordes of devs can't figure out how to make it run well on 3 GHz+4GB ram? Laughable. Sorry.
We've gone terribly wrong at some point. The whole graphical front end and internet technologies need a rethink from basics, and a rewrite. The sooner we get started, the better, but it must be done at some point.
That latency report cites hardware probs too.
Best redo ideas are symbiotic in jy experience. Wasm w/ GPU programming in small codebase, like what @rikarends has been working on. Hope to time AR headgear that doesn’t put smartphone on your face. Better if winning on all devices.
I disagree. Example: gui tool kits and DEs were made before UX and UI were figured out. If we got rid of current DEs and TKs and came up with something made to be light, easy to develop for, and with a pretty good, consistent feature set, we'd have a big win.
We seem to agree. Or my “jy” typo confused things? I am in favor of new s/w that skinnyhacks existing h/w fast paths & breaks compat. I mention wasm plus GPU to stay mem safe (but beware spectre) & downloadable.
Ah, i see, that's why you mentioned it! Yeah, i see what you mean. Though IMO wasm is a waste too - *very* little code needs turing completeness or low level memory access, and in fact, if those are removed, a compiler can optimize the heck out of it. Plus it's loads safer.
In fact, i've been looking into sub-tc langs for some time, and the more I look, the more I ask myself why we need tc in most places. Sure, there are some things that need it, but e.g. even in a server, or a gui, those are very localized, and yet tc leaks around everywhere.
I think if system languages were divided into sub tc (easy to use, good tooling) and tc (hard to use, alien syntax) we'd be pretty well off, because you'd have a good incentive to do things in a good way :)
I have concerned myself with looking at languages and figuring out what their sub-tc subsets would look like. This came from researching emergent complexity ("who would guess rule 110 is tc?") - surprisingly few think of it in programming, most info cones from AI and linguistics.
This in turn came from trying to figure out where bugs came from, and the simplest way to put my findings is "a bug happens when you thought something that wasn't". Emergent complexity is a broad category of causes for that happenstance, and TC is a narrow case of EC.
There are other reasons for EC outside of TC, such as code interacting in unforeseen ways (e.g. 10 levels into the call stack from where you are, something odd happens) or uncontrolled features (in some PLs you can write weight = eye_color * age and then the patient dies).
Then there's the fact that some code is simply better written in a representation, syntax, and semantics that's suited directly for what you want. Ex: J/APL for numerical code, awk for text processing, VimL for doc processing, SQL for filtering on predicates.
I can't say i *follow*. Most insights I have of this family of langs is still second hand - from talking to experts, heavy users, and huge fanboys alike - writing a large project in one of those is still on my todo list.
Good news: now we have techniques in compiler design that let you freely translate between each sub-tc language, at which point the syntax and semantics just become front ends.
Rethreading: Dhall is a total language for configuration and has seen massive uptake in my little corner of the programming world recently. For most other kinds of things you'd like to code, even if the code you write is usually not TC, the PL still is.
If I had the funding for that, all I would do is just sit around and implement this sort of world for programming - a stack of sub-tc and tc langs for most programming needs, from desktop through web front end to servers. But it seems no one wants to pay me to do that 🤷🏻♂
(There's a huge lot more to this: to minimize bugs and maximize security you need modern compiler and ide features, advanced tools to inspect a code base and executions of it, etc. There is a world of important stuff people developing "industry PLs" are ignoring)
It’s pretty well understood in type theory & proof assistants, too, e.g. why Coq’s Gallina language is sub-Turing, why @idrislang has a (necessarily conservative) totality checker, etc.
nobody gives a shit about your efficiency. Like literally only a small portion of software developers care. Nobody else does. The trade off of an inefficient Electron app is low barrier to entry for developers and faster shipping of products, and more products. Far more important
Then go run an Apple II and stfu. They are fantastic computers and I love 6502 ASM. In fact, in your world i’m sure we’d all still be coding ASM by hand (which I’ve done) because frameworks are a waste.
Well, for a guy who used C/C++, QT, Objectice-C and also .NET, one of the reasons I embrace electron were:
- speed of development
- easiest way of consistent development on multiple environments (macOS, Linux, Win32), even JAVA sucks at this
- shipping easily
- text rendering
I’ve been thinking about this a lot. Does Electron have security problems *beyond other native app platforms*?
I just take it for granted any native app is incredibly risky, and that I need to trust the creators—one reason among many why I prefer web apps most of the time
Native apps require high trust. Electron for building native apps. Electron requires high trust.
But there's more: Electron makes web content langs + Node.js in unsandboxed Cr the default. Doesn't mean attacker's web content, but latter flows too easily by accident & social eng.
Some Electron app vulns entailed injected app fns in same container as webby content, which could pwn via Function.prototype.apply override. This is just one of several exploit classes. Without PoLA and sandboxing, very hard to fix or _a priori_ rule out. Hence Win10 store ban.
Native apps need care, but C++ does not have eval and apply on downloaded code (not w/o extra runtime magic including a compiler + dynamic linker, which BTW are iOS App Store rules). Same for Swift, Obj-C, Android Dalvik.
JS app architectures need sandboxing + defense in depth.
Would it be accurate to say that Electron apps from honest sources are no worse than C++, .net, etc., but that malicious venders would have a much easier time doing harm with Electron?
That was the story they sold: “be careful” (“Safen up, Smitty!” - Homer as safety inspector, “The Germans”). How did it work out? Not well.
Murphy was an optimist. Specific: w/o sandboxing and defense in depth, the modern web world will put attacker code in high-trust JS engine.
Thanks — and on point, wasm won’t remove the attack surface, eval/apply genie is out of bottle. We can cope, with better trust labels + intercession facilities (twitter.com/brendaneich/st… [thread]).
“This unintended exposure of Facebook data to third parties is not due to a bug in Facebook’s Login feature. Rather, it is due to the lack of security boundaries between the first-party and third-party scripts in today’s web.”
I asked in 2012 “why not add boundaries?” It’s time.
Yep. Capabilities are where it’s at. There’s lots of good type theory stuff going on too, like session types and behavioral types. What would be really neat: dependently typed assembly language. Then build up easier to use / more accessible stuff from there.
Ah, nice. I’ve been working on some of this stuff at my company. Hard to fund such a big & long term project these days though. Something something good enough something something. You make me feel slightly less like an insane mad scientist :)
I learned much of what I know about the front-end web from “View Source.”
While I see benefits to WebAssembly I lament that it’s proliferation will make future techniques much harder to learn. :-(
That's not what I at least am referring to. A UI generated from JS isn't as readable as HTML was to a non-programmer... especially not starting from what's rendered. Certainly after 17 years I can use devtools and source maps. But back then? Woulda been unapproachable.
But, then, I didn't set out to be a programmer. I don't have the background I'd need to get a big buzz from the ideas that you should rely on a for profit platform or be a professional programmer to contribute to the web.
Those ideas would've excluded the 16 year old me that got excited about the web and prevented the journey that brought me to my career, so they don't sound appealing. Not a fan of the web's versions of enclosure laws.
Astute twitter followers know, I am not a fan of enclosure laws. Apart from JS itself (sorry; something like it was inevitable; at least it foiled VBScript), what enclosure movements do you see? Thanks.
That's a complicated topic I definitely can't tweet about right, but a short summary would have to touch on native mobile, JavaScript frameworks, social media, web publishing platforms, and tech companies that might be too big to fail.
Yep! Not that I'm against it as a hard rule. Good to explore ideas. I just hope to see those ideas evolve toward supporting non-experts the way the web did, rather than being satisfied with reinforcing dynamics the web upended.
Love where you are taking this thread. I have a long history in championing the idea of supporting the non-professional programmer. Just one such example from my old blog:
mikeschinkel.com/blog/amodestpr…
And a friend who feels the same. She is now PM for Visual Basic: @KathleenDollard.
Interesting! Since I moved to SF I've begun to feel naive. Maybe things I care for are objectively secondary to "profit" and "progress." Maybe it's incidental or a sign of inherent superiority that the benefits apply disproportionately. It's depressing, so that's good to hear.
System here (US, UK too; places under the "English ideology") a rigged game: usury + profiteering rackets, babble about progress as cover. If you point out absurd (e.g. CEO pay vs. worker) inequality, wages stagnant since '73, student debt bubble, they move goalposts. My 2 cents.
Maybe you should update that post and remove Mort :-) There is an enormous array of developers that want to get something done more than getting excited about coding - no name could cover them all. Happily both VB and C# have gotten easier since that post - still a long way to go
True. But there is nothing quite like being able to ask one’s self “I wonder how they did this?” and then be able to just “View Source”; no grasping for the right terms to Google required. :-)
That said, I was wrong; Turns out WebAssembly supports View Source.
Is this applicable with sandbox turned on (node integration disabled), but with a preload script that injects global functions that run privileged? You just made me realized that those global functions could expose security holes
We forked Muon from Electron to enable sandbox by default, make other relevant fixes. We are moving away from it now (expensive to keep up w/ chromium stable, other probs), but others still use Muon. See github.com/brave/muon/ & discord.gg/TcT5tX2 and pls join if you can.
Will join discord, but if you don't mind - how is F.p.apply special? I need to guard against all functions possibly being overwritten with injected code
Yes indeed, but apply is extra useful and used, & unless privileged code runs first, saves a ref to original value of F.p.apply, and uses it assiduously, bad times. Which actually happened. F.p.call, etc.
Consider the likelihood of using Node modules that did not get audited and fixed to use a safe ref to ur-apply or any other built-in. Now iterate under maintenance with npm growth.
I’ve indeed thought about these things (didn’t think about the preload privileged funcs vector) and am worried. I avoid dependencies in the backend privileged process, takes discipline
I've been trying to make a poor man's sandbox by overriding JS APIs and then freezing them so that a subsequent attacker can't mess with them but it's a rabit hole that runs deep, "require" is implemented with "fs" so if you can change fs you can eval anything...
Node has a built in sandbox API, right? Couldn't you leverage that? You'd have to somehow inject all the globals you need and eg provide your own require, but that's kind of what you get when you lock it down. What am I missing?
prettier has 846 npm dependencies, I'd like to find a way to make sure that if any one of them is compromised, it's not going to be able to trivially read any file on disk and send its content to a webpage... Creating a new js vm for every call is not really scalable...
Would you have to do it for every function invocation? Couldn't you make your sandbox require return safe versions of the modules that are limited to doing only things that you permit? E.g. require("fs") could return a safe version that only let's you read certain files...
Ofc, non core code could be compromised... Maybe you could find a way to only permit certain safe versions of 3rd party code to be used as well? I mean, it's a TON of work but it doesn't seem impossible.
My gut feeling is that we need to restructure the node apis to behave more like apps on app store where there's an explicit permission model and a proper sandbox. The current architecture has not been designed with that kind of security in mind...
Mm, I'm not too familiar with the app store security model. But I agree that good security is the kind of thing that needs to be there from the start. It's almost impossible to tack on later.
App store uses approval to impute security, all or none and at your effective UID. Not a good model for the Web IMHO. PoLA is better. Have you read erights.org/talks/thesis/i… yet? An OCap Node (OCapN? CapnNode?) would be cool. Cc: @DeanTribble in case he knows of one already going.
What I was referring to is a permission system. If I write an app that wants to access the camera, I have to ask the system which will ask the user and only grant me access if he accepts. I could see something like require('chalk', {readArguments: true}) to restrict permissions
yeah i'd be curious.. there is safe `eval` (empty env), but the power of node is the module system, and that is global all/nothing, so insecure by design. so in practice... OS-level containers (Lambda, ...).
This kind of talk is how you lose devs. "Let's force them into Electron because Slack has lots of VC money" LOL that one was funniest. Stop trying to constantly stifle dev innovation and work on something cool instead.
This is exactly what I started working one, when I realized when monkey patching fs that require() itself was using fs and then that most of the js-part of node implementation itself is accessible and monkey-patchable from any scripts you require. It's likely not going to be easy
If topic is Electron (it was ;-), then PWAs don't take it down without all those juicy unsafe Node modules that are part of the Electron package deal. PWAs are great, don't get me wrong. Still a big API gap from Web to native (developer.chrome.com/native-client/…).
The prob w/ Electron is not implementation language, to first order. Rust or Go would be safer due to memory safety enforcement in the bulk of the non-chromium code, but rewriting chromium in R or G would be a huge & thankless task. Meanwhile, the JS (Node + Web) mixing remains.
Proton isn’t rewriting chromium, though. Just provides an environment where JS bundle can run and bridge to native UI for rendering. Having an entire browser is a waste of resources (and common complaint of Electron is resource usage).
There’s room for both. I wish you’d give React Native proper consideration given your influence. It’s JavaScript powering apps at FB, Amazon, MSFT, AirBnB, many others. There’s merit there beyond the “not this shit again” reflex eye roll.
Electron demonstrates the huge demand for JS-powered cross-platform apps on the desktop, just as PhoneGap did for mobile. Both had limitations. React Native refined the experience on mobile. Proton could for desktop.
I feel like the popularity of electron is not that much because it is the web, more because it allows to write native apps in JS, leverage existing infra, npm ecosystem. A proper native renderer à la RN for desktop is much more appropriated than html.
Yes, the common thread was JS, from Web to Flash (AS) to RN. But Electron is popular for more than just JS. It lets Web devs do app front end w/o the big hit of dropping their hard fought CSS and HTML learnings.
We have converted over many of our web devs to RN with minimal effort at Infinite Red. Many speakers at @ChainReactConf are former or current web devs. React Native Web shows how interconnected the APIs are.
Ha - I made the name up. Turns out Proton already exists and is targeted at native desktop apps. Wow this ecosystem moves fast. I hope that project gets a ton of attention.
twitter.com/adamrackis/sta…
Wow my sincere apologies. I just made up “Proton” as a hypothetical name for a Go-based Electron—same idea but with a heavier standard lib (get it?)
I should have assumed there’d be a JS based project somewhere with that name already 😂
;) Thanks! It's sort of hard with time right now since school is coming to a close. But I'm looking for internships in the summer and I'll have time to really work on Proton Native alongside that (or maybe together if I'm really lucky) Yoga support is close just a few more things
Yup. My parents wanted me to finish college, until I started making software developer money. That shut them right up. I'd still recommend finishing high school though, even if you phone it in.
No, subsets. Full CSS + HTML needs something like chromium.
I am not raining on Proton’s parade but someone changed the subject. I was asked whether Go would help solve the Electron architecture probs cited upthread. Not w/o ditching Node & chromium. That is more than “use Go”.
Native apps require high trust. Electron for building native apps. Electron requires high trust.
But there's more: Electron makes web content langs + Node.js in unsandboxed Cr the default. Doesn't mean attacker's web content, but latter flows too easily by accident & social eng.
Ah I get it, yeah. The thing is, it’s much less easy/intuitive in React Native to run downloaded (untrusted) JS code. The JS bundles are largely static after you cut a build. Browsers, on the other hand, are optimized to do just that - run downloaded code.
Yeah. It's a set of attack vectors anyone who provides an open platform on web technologies has to contend with.
I'm building such a system, & intend to use oasisjs.io with it. IIRC, h/t @bascule
Two thoughts:
1. You could Babelize Node out of runtime in the Electron-with-chromium-sandbox renderer processes.
2. Your RN-like approach could still have issues with eval and apply as noted upthread.
There's no silver bullet, but compiling out dynamism + sandbox are winning.
Addressing security aspects is critical of course.
I think UI responsiveness and memory footprint is also really important for Electron apps, hence using built-in UI renderers approach like RN allows skipping shipping a renderer that has to support 25 years of web.
I actually though legacy made for a big part of browsers size / runtime perf / memory footprint. I’m curious why it isn’t better, a lot of very smart people work on browsers so there must be a good reason.
Code footprint is big because lots of content formats required on web. Legacy ones get removed over time (e.g., gopher, MNG). Corner cases in code cost some but are live code paths used by content.
Heap usage is big depending on content, isolation model, OS per process costs.
This focuses RN-like vs Web. Do you want SVG? Sorry, not supported. H.264? Depends on platform & may be buggy as Hades (various Android). Etc. Top teams work on attack surface (Project Zero!) as well as correctness/completeness. caniuse.com
Seems like the problem with using a browser for an app it that you get all or nothing. There would be benefits if chromium was modular and you could link only what you need when using it for an app. Doesn't fit well the current "standalone app" model.
I love the web, especially on desktop, but for some things standalone apps can be better. I would love if my text editor didn't have to support all the things in the html5 test list 😁
Agree re: editor. There are & will be more desktop apps but not the flood we see on mobile, which reflects first/fast-mover advantage to native from OS owner, understandable given age of Web vs relevant OS. Equilibrium b/t browser & apps favors browser on desktop, apps on mobile.
If my thesis is correct then equilibrium point on tablets should be in between (favor browser vs apps more than on smartphone) as device APIs matter less & screen size favors Web. Lost track of Vision Mobile (renamed) but they used to study stuff like this. Anyone have a link?
I use browser much more on tablets, install fewer apps, and still find apps there that do not customize rendering for tablets (instead throw up a sideways giant iPhone UX), supporting thesis.
The big reason to bet on PWAs + gap filling Web vs. native: zero-install. Getting me to download a new fat client is hard. Getting me to try a web app (site) is easy, with a patched-up and defensive/protective browser.
I agree, definitely the main problem with native. I'm still hesitant to bet on PWA for mobile since web standards are slow and native is fast moving still.
I'm actually really optimistic about WASM, opportunity for a fresh start for the web. Hopefully it ends up exposing low level APIs for frameworks to build on top and can avoid some bike-shedding to ship features fast since its not user facing (compile to).
I like to think as react-native as literally a platform that can render to anything. It could be used to render a PWA via rn-web for easy install reusing most of the same code as the native app, only disabling parts that require native APIs not available to PWAs.
Initial/exploratory experience is definitely more a web thing (I first used Slack on the web), but once committed, customers / users are still asking for apps, because they deliver a deeper, richer, more "sticky" experience. I think both have their place.
On desktop? Not much. On tablets? See earlier tweet. On smartphone I see a shift. New app install rate low, younger people use a few tall head social apps to try and dump other apps, so stickiness varies. Almost all apps on my iPhone are cold for many months.
Didn’t you already agree that Electron was not creating a second coming of fat desktop apps? twitter.com/brendaneich/st…
I have one installed (Slack) if you don’t count Brave, and we should discount it because the comparison was with browsers (also because Muon).
Nothing will bring back the former popularity of desktop apps. But they'll still be needed occasionally, and I hope something very close to Electron will be viable for making them.
You mean a PWA running on the desktop? I've never heard of such a thing, and doubt it would work even if it existed. Almost any real desktop app will need to access the file system, access a CLI, etc.
Very cool, but I doubt useful in practice. Only rarely will I want an app on my desktop, and those that I do will likely require disk access and other things a PWA won't be able to touch.
That sounds cool but also terrifying. A PWA having access to my file system? Obv it'd have to ask permission, and obv I'd click "no" unless I had a damn good reason. But surely that'll be a panacea for bad actors.
For sure - installing an app on your computer is always a big deal, limited to apps you trust.
But the idea of a PWA being one confirmation away from file system access seemed much worse. But from what you say it seems like that’s not how it would work.
Our plan for filesystem access is incremental: start with single file read-write (for open-with situations), then onetime directory picker, then persistence. All user-mediated; very much how Web Bluetooth works.
And, like all the rest of this stuff, we're breaking up capabilities from the concept of installation. Why does that one click grant so much privilege? That's a bug.
Installing a PWA on Android grants exactly two unique capabilities: the permission to launch without the URL bar and the ability to request durable storage. That's *it*. The web permission model is runtime-permissions, which means any tab can ask for things; we're unbundling apps
Most of this thread was based on *desktop* apps. I really love (mobile) PWA’s, I could see them replacing almost every mobile app I use, except maybe social media, music players and email clients. My reaction before was in response to a *desktop* PWA requesting file system access
To be clear my need for desktop apps is even lower than mobile, but inherently requiring a ton of trust and permissions: IDE, database explorer/manager, etc. I can’t imagine a PWA ever approaching that level.
I'm not sure why not, if the threat/trust model is the same. You download Slack (e.g.) and it can do anything under your user id, and phone home. Installed PWA differs how?
(Reading backward) from Alex's answers the PWA is more secure because you have to grant authority selectively and for bounded interactions or possibly periods of time. Could be usability suffers but it would be more secure than Slack rn.
Right - massive usability suffering. I don’t want VS Code or SQL Server Management Studio to constantly ask my permission to do stuff; I want it to just work.
Not sure I follow. Most users and developers don't need...this level of access? Absolutely - why, imo, installed apps will never go away, just become less popular (especially on desktop)
Most apps, most of the time, can work without exotic, non-origin-model-breaking capabilities. If decision load is low enough, runtime permission grants work well. Sticky issue is how to prove that high-trust apps have earned that trust.
The reason the web is as secure as it has been is because we are paranoid. The arguments browser vendors engage in are defined by *how* paranoid we are. No "developer code can do whatevs" browser has ever survived contact with the enemy.
The defining question of a web platform engineer: "is clicking on a link a safe and reasonable thing to do?"
If the answer is "yes" in the face of your feature, it'll be fine. If not, you're in ActiveX territory and the ecosystem risks can hardly be overstated.
"Installed" is overloaded.
Today, that means giving up everything to everyone all the time. We pay far too much for convenience today (on nearly all OSes).
He did stipulate that we give up what we give up for convenience. Slack not a good example though - the desktop web app is wayyyyy good enough for me. It takes a lot more to get me to install a desktop app
Asymmetric information (+ cognitive biases, which programmers are SUPER susceptible to, thanks to societal training that they're "special") gets you most of the way there:
No, of course not. There are huge gaps in capability. What I'm saying is that, as an industry, we have largely failed to mediate what remains in that gap responsibly.
...and a bug the web's security model goes some distance to fix. More to do -- we need better permissions UI and API, e.g. for time-limiting grants -- but none of this is magic; only hard. Requires will.
I don’t think it’s a “second coming”, not on the scale of mobile apps. But I think there’s still a need. On my macOS and Windows machines: Slack, Signal, Telegram, Atom, VS Code, Brave, Hyper, Discord, Google Play Music, and probably a few others I can’t recall.
I would use Twitter desktop if it was well maintained, as well as a better Gmail experience if @Streak supported it. I like desktop apps and I use a lot of iOS apps as well. Plenty like me out there!
Try @SuperhumanCo for faster-than-native JS-using-multicore email client. The big picture issue here is runtimes, not native shrink-wrapped binaries. The number of those likely to be installed apart from games is fingers and toes, at most.
Then you want Caja/SES or similar - no Node with npm full registry of apply-ful modules.
Rest and spread kill apply in long run, but we are all dead in long run.
I could see a mix of PWA and RN like frameworks replacing electron on desktop, a bit like it did on mobile for phonegap apps. Would be a good step forward imo.
We definitely need to move in this direction, but there's a lot of work to do on new APIs for accessing desktop resources like the filesystem and network at a lower level.
Wow my sincere apologies. I just made up “Proton” as a hypothetical name for a Go-based Electron—same idea but with a heavier standard lib (get it?)
I should have assumed there’d be a JS based project somewhere with that name already 😂
Coming from a web background with limited Native experience (through RubyMotion), React Native was a breeze, and a very shallow learning curve. The majority of my HTML & CSS knowledge still applied. Also, I'd argue the RN abstractions are cleaner.
It can, thanks to the React Native Windows project created and maintained by @EricRozell from @Microsoft. I built a video conferencing desktop app for/with a client on it and it performed extremely well.
And you can learn more about RN Windows by signing up for our advanced workshop, taught by Eric (and Kevin), at @ChainReactConf! I think there's only one ticket left though. 😉
Some flags apparently need setting in Chrome to try desktop PWA with install UX — Brave will support by cutover to chromium-fork from Muon, if not sooner.