Convopage
See the entire conversation
> 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.
302 replies and sub-replies as of May 08 2018
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.
Btw what your prev tweet did was pay lip service to security :-(.
It's not as though native desktop apps are immune to these problems either. Are we comparing the security situation to web apps or other native apps?
(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.
Don’t get me started...
On system latency trend: danluu.com/input-lag/
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 can think of a few, but what languages have you looked at? Thx.
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.
Did you follow APL family from J to K to Kerf?
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.
If you wanted to view code in a light more natural to it, you *could* just select a function and compile to another PL.
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.
Was thinking of such but to convince in this thread, need at least a couple of app implementation language examples!
Maybe @GabrielG439 can tell you more about useful sub-tc langs, since he made Dhall.
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)
The other example I'm aware of is SQL
Also theoretically spreadsheets, but @Felienne showed us otherwise.
Just out of curiosity, what is your corner of the programming world?
For my day job Haskell :-)
Tbh best is default total, but a keyword to embed tc computations
How would you do that? Show me an example program (doesn't need to compile). Pastebin is ok, or multiple tweets.
-- provably total structural recursion
len :: [a] -> Int
len (x:xs) = 1 + len xs
-- non-terminating computation
lazy foo :: a -> b
foo a = foo a
Also cool is a general recursion monad, like in Coq or more ergonomically in F*
How would you call foo from len?
Also where is len’s basis case?
I guess @light_rook forgot but it's ok if we know what he means :-) left as an exercise for the reader.
Oops, here it is!
len [] = 0
You wouldn't, that's the point!
Gotcha! So in fact you're embedding sub tc computations (in tc computations), not the other way around. I like that.
Exactly!
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.
Sadly, those people are still surprisingly few.
Yes. Let’s see where we are in 5 years or so.
Was thinking of such but to convince in this thread, need at least a couple of app implementation language examples!
Yeah. I thought goto.ucsd.edu/quark/ was promising as a start.
Thanks, I had forgotten about Quark!
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
Looks like i woke up the snowflakes.
I love how you don’t get that you’re the snowflake. “Wahhhh everyone is using electron and i *hate* it!” go cry somewhere my dude
Props for add-to-killfile sound.
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.
Get out of my mentions, little buddy
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.
That actually makes sense—thank you!
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.
(*against* iOS App Store rules)
That much was clear in your original tweet :)
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.
Think about an editor, copy-paste of HTML, social engineering.
“Smitty! Safen up!” (1:35 youtu.be/vqIsenRl_Wk)
Oh Germans!
ZE GERMANS!
youtube.com
It’s almost like we need a language that’s designed to be portable and is easier to verify, sign, and sandbox...
Already got you WebAssembly from JS + Typed Arrays precursor - what more do you want? :-P
I appreciate you ❤️
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.
Oh wait. Is OCap this: opencryptoaudit.org
I think I misunderstood. Neat though. And I stand by my last tweet :)
No, you had object capabilities as OCap right the first time.
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. :-(
We can definitely hope...
Minified JS is no picnic to read, true: but devtools beautify. And in a pinch, view-source wins still.
HTML is great, I am not touting JS markup generation. Or wasm as fat app with pixel-pushing UX. HTML forever!
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.
BTW, I left the Microsoft fold in 2006. Only recently had a reunion with Kathleen to find out she is now the chaperone for VB!
Great précis!
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.
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
LOL. I can’t seem to find time to write new posts, let alone update ones more than 10 years old! :-)
WebAssembly supports view-source:
WebAssembly/design
design - WebAssembly Design Documents
github.com
Oh interesting. My bad. Thanks!
But regardless, we have a wealth of learning resources today which far exceed “right click, view source, try to figure it out.”
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.
(No comment)
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
A bit alarming that that’s not clearly stated in the documentation and provide clear steps to securing it down.
Ayup. :-(
Ironically, I know some people who are looking at Electron because they see it as cheap security.
Never really looked much into it, but now I'll have... y'know... more questions.
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.
Discord - Free voice and text chat for gamers
Step up your game with a modern voice & text chat app. Crystal clear voice, multiple server and channel support, mobile apps, and more. Get your free server now!
discordapp.com
That name! 👏👏👏💯💯💯
Heavy Electron.
What are you moving too?
Thanks! Great read!
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.
Fun: did not know about the .call TLD.
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
What app is this, btw? Thanks.
I believe it's @actualbudget
actualbudget.com (beta download at actualbudget.com/beta/, new website coming soon)
Actual - Product Hunt
Actual - See what you actually have to spend. on Product Hunt
producthunt.com
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?
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...
Seems like you could provide safe versions of all of node core inside your VM.
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.
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.
PoLA -- good, good.
Read Mark Miller's thesis first, esp. the Confused Deputy problem first identified by Norm Hardy.
"The capability both identifies the file and authorizes the compiler to write there."
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.
I hope you did not think that came from me!
Yes, citing VC spend was lulz.
We're launching a startup that will support OCAP in JS, so stay tuned. Building a new SES and Dr.SES (research.google.com/pubs/pub40673.…) based on github.com/tc39/proposal-…. SES will support POLA for both es6 modules and node modules.
tc39/proposal-frozen-realms
proposal-frozen-realms - Drafting Frozen Realm proposal for ES7
github.com
If you want some implementation of this idea:
vjeux/jailtime
jailtime - Put your node code in jail and monitor all its communications
github.com
There's a reason we're investing in desktop PWAs. Is it on the Brave roadmap?
We are based on chromium stable (except on iOS of course) -- what's missing?
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/…).
We've been busy (and continue to be) adding capabilities to the real, standards-based platform. I'm cautiously optimistic.
Me too, I'm still betting on the Web -- but (to return to upthread topic) it'll take longer than Electron apps have to get secure :-|.
How feasible would it be to build an Electron (Proton?) on Go? Presumably more secure with a decent standard library to boot. Or is that just madness?
Proton is a fantastic idea ... would love to see it get traction.
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).
More like React Native than PhoneGap.
ReactNative exists, so compare to that, not to Electron. The appeal of Electron is not just Node but also HTML.
RN is for native *mobile* apps though. Would be pretty cool if that could somehow be extended to native desktop.
I remember many such platforms over the years (e.g., Flash, OpenLaszlo). The Web won, didn’t it?
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.
So does React Native. (And Proton). Without a browser.
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.
That is great, but desktop _per se_ is not going to bid up a second coming of native fat apps, IMHO.
That’s a reasonable take.
I rather agree with Alex that PWAs plus more Web vs native gap filling will win.
TIL proton is written by a high school sophmore that lives 5 minutes from me. That's dope.
Just googled it - the BASIC compiler or some other proton?
Proton native
Did not know that, thanks! Libui-node looks great.
Whoa Adam I thought you were referring to that here. twitter.com/adamrackis/sta…
How feasible would it be to build an Electron (Proton?) on Go? Presumably more secure with a decent standard library to boot. Or is that just madness?
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 😂
Hah classic javascript
Next year you should reward the lad by DJing his prom after party or some shit
I know right!? Major props to @kusti8! We gotta get you hired someplace where you can work on it full time!
;) 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
Intern with @FormidableLabs!
or @callstackio or another company who wants to specialize in Proton Native development. Electron apps can bloat in hell.
Fuck internship - someone needs to hire you as a full-time developer
Imagine being a sophmore and being able to pull that kind of contract work money? I would have rode into school on a Ducati in a suit
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.
Strong concur!
Punch Kyle pettit for me, tell him Kenny said it's cool
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”.
Sure, my tweet was saying ... ditch chromium. 😉 It’s built for a different problem than Electron apps are solving.
I like Electron, want to see the next refinement rather than it be banned from app stores due to deficiencies.
But "written in JavaScript" is kinda a big scope deficiency.
Not sure I’m following ?
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
Oasis looks cool!
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.
No argument there! Btw it is not all the backward compat that makes for big mem footprint.
True, a better argument is perhaps to say “there exists a renderer on the client system; use that, don’t ship your own.”
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
The HTML5 test - How well does your browser support HTML5?
The HTML5 test score is an indication of how well your browser supports the upcoming HTML5 standard and related specifications. How well does your browser support HTML5?
html5test.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.
I agree, web is actually in a good spot on tablet. Market share is pretty low compared to phones though.
From all signs, Apple will merge MacBook Pro and iPad, macOS & iOS, stipulating that the keyboard has to be great. Will laptop & tablet classes merge?
This is why they keep making the keyboard worse. By the time it's just a touch display people will prefer it :P
Won’t work. Already drove me back to 2015 mbp. Next stop, linux on a stinkpad.
Windows is pretty tight these days ...
Nope, need Unix under hood.
They kinda have that now.
WSL is nice. Would definitely love if Windows was _just_ a Unix shell 😀 (although I get bit everyone has the same use cases I do)
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.
WebAssembly changing this, games on frontier as ever. It is a race!
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.
Im talking about desktop; there’s a reason Electron apps are popular.
(And you may not represent the average user ;) )
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).
That is great, but desktop _per se_ is not going to bid up a second coming of native fat apps, IMHO.
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.
WDYT of PWAs with enough native APIs appropriately exposed?
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.
Disk (I still say it too; let's say filesystem) access is on the agenda: developer.chrome.com/native-client/… (find "_File"). Red to get off ledger...
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.
It's more of an install model, and you were game to install Electron apps...
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.
I'm not sure how fs access will work. Maybe Alex can say.
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.
Which one click? You mean installing an app?
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.
It's possible to imagine a way to do this with signing and Web Packaging, but most users and developers don't need this most of the time.
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.
Stuff like vscode can be given everything (heck, can run as admin, launch processes, read fs anyway)
E.g. prevent install from browser, require dl and click through install
Of course "stuff like VS Code can be given everything". The ecosystem-defining question is "who gives them everything, and why?"
I’d assume the user, because we just assume that the app is trustworthy, and will need far-reaching access.
Is your assertion that users make informed, reasonable decisions about software security?
i0.kym-cdn.com/photos/images/…
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.
Agree completely and I hope that never changes. Exactly why installed desktop apps will always have a place
"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).
So, why do you think that people would ever install Slack desktop over using it in Chrome, then? IMO there's still a distinction.
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:
Asymmetric Information
Asymmetric information occurs when one party to a transaction has more or superior information compared to another.
investopedia.com
Wow, really...
You really think that the only reason people use installed desktop apps over web apps is ... they're ignorant? 🙄
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.
Fantastic, thanks!
It also gives auto play permissions apparently.
Ah, yes, it does set the engagement score up. Forgot about that = )
...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.
WRT security; "Multiple new Intel CPU flaws revealed" so maybe Intel should take responsibility for electron as well?
Exclusive: Spectre-NG - Multiple new Intel CPU flaws revealed, several serious
New flaws and even more patches - "Spectre Next Generation" is just around the corner. According to information exclusively available to c't, researchers have already found eight new security holes in Intel processors.
heise.de
I just wish developers had access to a @zeithq like “now cli” deployment to pwa or @electronjs which was @intel secured by default
I'll go on the record saying _starting with_ `eval` & `apply` are self-owns.
Just don't start there. Full stop.
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.
Yeah, right now there’s a heavy reliance on Node. Which is maybe fine, for now.
Ideally I’d love to see some smart sandboxing added to Electron, somehow. It’s an incredible platform and I really want it to succeed.
Chromium has all the smart sandboxing you could need; Electron turns it off by default.
I assume they do that because Chromium lacks access to important system APIs.
Or, rather, Chromium with sandboxing on.
Great conversation - saved entire thing to one page here: convopage.com/c/991041204417…
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 😂
Haha totally. I was confused when you were like “WTF is Proton”
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.
RN Windows is really well done.
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. 😉
Note: size of the non-chromium C++ codebase is << size of chromium.
I thought Brave has had serviceworkers for a while. At least the desktop version has it, I'm sure.
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.
Slack is a terrible software though, but Vscode sure is good
I don't know if it's Electron's fault or the specific implementation of Slack, but it has performance issues in my experience.