Hacker News Reader

> I can use the same UI components that I use for making websites and easily share code between all platforms.

I propose that using web components for desktop/mobile applications is not a good thing.

>I propose that using web components for desktop/mobile applications is not a good thing.

Agree, every platform has it's distinctive look & feel and as a user I expect that my apps follow this for 100%. Recently I checked out Flutter, with the 1.0 release i thought it's worth to play around with it. The first thing i did, was installing their demo app on my iPhone they showed on the release event. Within seconds I noticed that there was something wrong. They tried hard to reimplement the bounce effect during scrolling on iOS, but it just didn't feel 100% right.

I totally understand, that not every user out there has this sharp eye for things like that and that there is definitely a business value going cross platform, but this is not something I would be proud as a developer. It's the cheap root for the developer ending up in a cheap experience for their users. Share your business logic between platforms if appropriate, theme it for your CI if needed, but do the UI as expected.

I disagree. I think cumulative hours across the average spectrum of users, they spend far more time on the web / in a web browser / in web tech-based apps than they ever spend (or at least notice they spend) in a "native" app. The web platform has won. It is native toolkits that have to follow web conventions now (hyperlinks, routing, deep linking, system back buttons, etc), and there are users starting to complain when they don't. The platform distinctions are starting to be meaningless to users so long as basic "web" usability is met. (I've met people that switch between Android and iOS regularly based upon whatever was a cheaper device or had a better plan with their carrier. Those sorts of people absolutely don't care about "native" widgets and see the differences in platforms as a silly barrier to the web.)

(Arguably that's a problem with Flutter too because it isn't "native" nor "web", it doesn't entirely meet the expectations of web users currently either.)

For better and worse, the web is a ubiquitous platform, and I think getting to be just about the only platform that matters today, regardless of the remaining fan wars between the "native" platforms.

While they are arguably old, these two quick sources I found seem to indicate quite the opposite:

https://amp.businessinsider.com/time-spent-mobile-browsing-v...

https://amp.theguardian.com/technology/appsblog/2014/apr/02/...

Even though they are old, the trend at the time was clear: people are spending more time in apps (most of which are probably native) than on the web. The idea that the web is universal and what most people spend their time on isn’t a fact you have established.

Web technologies are loved by developers for their speed and ubiquity. But as a user, I strongly prefer the feel of mobile apps for my day to day interactions. I find the web, particularly on mobile, to be a mess. The interaction models are all unique and confusing and typically not well implemented, while native UI widgets work well and are understood.

But your mobile device is also only one device you interact with in a day. Very few people have the same OS across all their devices, even if you allow for the "close cousins" scenarios like people that only use iOS and macOS. Everyone uses the web everywhere, though, it's the one thing guaranteed to tie all of a user's devices/accounts/actions/"digital life" together today.

I don't have numbers to back it up, I have a lot of anecdotal evidence I've seen, but it does look like there seem to be at least as many people that don't care what widgets an app uses, so long as the app works, as there are people such as yourself that even notice native UI widgets and care about them (deeply and vocally, as often the case may be).

Perhaps, but I surmise that most people spend a large amount of their personal time and life on their mobile devices while people who are using full computers are generally doing so for work. I have seen it personally in my work that native mobile app usage has surpassed both desktop and mobile web usage.

> I propose that using web components for desktop/mobile applications is not a good thing.

It may not be, but it can be the difference between a developer releasing something that has real value to end users versus not releasing anything at all.

One could say that building an Electron app is an example of doing things that don't scale.

As a solo developer using Electron means that I don't have to reimplement all the UI components I already have, and I can publish a decent cross-platform app, where instead of spending time reimplementing everything across platforms I can spend time optimizing it.

I know of no other framework that gives me this power.

We use websites with different UIs every day, can you imagine if we were also complaining that Facebook doesn't feel "native"?

The fact that the component is made up of html, css and javascript instead of layout code, styling code and logic code seems irrelevant.

The difference boils down to feel and behavior. You can style web controls to look very close or identical to native controls, but they’re always going to feel “off” with issues like increased latency, wrong animation curves, and lack of support for system features (such as spring loaded dragging and drag and drop on macOS).

Why?

Electron is amazing for dev velocity. I love it there.

However, most importantly for my day job, it's not good for security. Adopting Electron requires me to accept the same structural weaknesses that led to all of the NPM malicious commit issues that have cropped up lately, and with Electron it runs as me, the user, not inside a browser sandbox. As a dev in a security team, not inadvertently creating attack vectors is literally part of my job, so that combination of factors is scary. In hindsight... I'm putting Discord in a sandbox.

Other native languages/SDKs/frameworks don't have this issue if only because so much of them come from first party entities and it's very viable to cut implicit trust to the repositories.

That makes Electron not a viable option for anything related to my day job unless it's guaranteed to be running in a VM, closed off from everything else. When some of the Node.js permissions related stuff gets put in, I'm going to like Electron much, much more than I do now.

> and with Electron it runs as me, the user, not inside a browser sandbox

You could actually not use any external modules in your main process and have the renderer process sandboxed [1], node integration [2] can be disabled too.

[1] https://electronjs.org/docs/api/sandbox-option

[2] https://electronjs.org/docs/faq#i-can-not-use-jqueryrequirej...

Thanks for bringing this up, I wasn't aware of the option. This changes how I look at the trade-offs of using Electron.

Unfortunately, that only covers the rendering code, and it still backtracks a lot of the reason putting JS into a native environment is convenient in the first place. But it's a lot better than the "nothing at all" I thought it was before.

We know that, it is the attitude of making it easier for developers and then letting the customer have to make quite big sacrifices that create the negative comments.

VS Code is built on Electron, which means it has a huge advantage from my point of view as a user: I can just remove stuff from the UI that I don't need and tweak it a bit with a few lines of CSS. I'm not sure what quite big sacrifices I'm making for this.

There are definitely awful Electron apps, but that's usually because of the developers, not because of Electron.

I can do the same on emacs too, says nothing about electron, just that you are familiar with css/js.

You can do the same with emacs because it's hackable enough, but you probably can't do the same with other native non-hackable apps like Word or Photoshop. I could do the same almost as easily with any Electron app, kind of like you can customize any website on your browser.

You have to separate performance of the application and the runtime. There are a lot of applications out there that are based on electron that are perfectly reasonable that are used by loads of people who by and large don't complain about performance issues. I tend to have several open at any time. Yes, they use a bit more memory. That's why you have virtual memory, ssds, and cheap ram these days. It's a complete non issue for anyone with decent equipment from anywhere in the last five years.

If you are so unlucky to be stuck on an ancient laptop with not enough ram, spinning disk, and an OS that doesnt't do the right things with virtual memory (non stop swapping for no good reason), that's going to be noticeable and annoying. Been there, done that, and it sucks.

If that is the case and you are a professional developer, get some decent gear, set it up properly, and stop whining. If on the other hand you are an end user, adjust your expectations accordingly to the fact that you are running old crappy hardware and don't try to install everything and the kitchen sink; or alternatively just be patient. Most users need nothing else than a browser running these days.

All fine and good but if there is a native app that has the same feature list, I’m going to choose that one 70% of the time and go without the other 30%. So long as you are also aware of that demographic it’s hard to argue with any of your other points from the dev POV.

There are definite a lot of advantages to building with web technologies, it's just that Electron is an excessively heavy way of enabling it since it basically just gives you a webapp with a whole browser bundled in. PWAs are a much better alternative since you can just use the one browser instead of having one running for every Electron app.