
Show HN: Vuido builds desktop apps using Vue.js without Electron - rmason
https://forum.vuejs.org/t/vuido-native-desktop-applications-using-vue-js/34538
======
z3t4
I'm currently developing a web app and while my nw.js/electron version is
around 50 MB and uses 200+ MB of memory, loading it in Firefox it's a 600kB
bundle, fully renders in less then half a second, and uses a whopping 8 MB of
memory in Firefox. Actually less the HN! So while I think this project is
cool, if you consider using it, also consider making a _in browser_ web app.
Also remember that the browser is more then just a HTML renderer. You have
stuff like speech recognition, text-to-speech, user input, sound api, 2d/3d
api, support for a bunch of mobile sensors like accelerometer, etc.

~~~
roryisok
I think you're failing to include the firefox memory usage in that second
example. the 200+MB memory of electron is because it includes the browser.
Your 8MB file also needs firefox to run, so in a naked desktop environment the
user first has to spin up 170MB+ of firefox before they can run your 8MB app.

~~~
z3t4
But you do not need to have five full Firefox's running for using five web-
app's.

Another benefit of web apps, is that with some effort it can run everywhere,
where as an app container like electron needs to have separate builds for each
platform.

~~~
roryisok
Agreed that's definitely a drawback.

Mozilla had an experimental project called qbrt that was like electron but
used the locally installed Firefox, exactly like you're describing. Hasn't
been updated in quite a while though

------
jasonkester
I feel like there's room for an Electron variant that's just "less electron".
As in, I don't need _all_ of Chrome to do my thing; just the HTML rendering
engine and JavaScript interpreter.

The thing that makes it 50gb is all the web sockets and ie4-comparable-iframe-
shims that nobody ever uses on the desktop. Lop all that stuff and see how big
the install is and how much memory it uses. My guess is it would be a lot
less.

~~~
nkkollaw
I'd welcome optimizations, but do we really care if an app is 50MB, in 2018?

I see a lot of bashing against Electron because of the size and memory
consumption of Electron apps, but at least on Linux Electron is a blessing.
Many times it's either an Electron app or no app at all, as many companies
wouldn't bother supporting Linux if Electron didn't make it so cheap and easy.

With that in mind, with many laptops coming with 128GB of storage and 8GB of
RAM nowadays, it it really that big a concern?

Even less for developers: my laptop has 1TB HDD + 256GB SSD, and 24GB of RAM.
I can definitely spare 50MB of disk space and 200MB of RAM.

~~~
nothrabannosir
> but do we really care if an app is 50MB, in 2018?

> my laptop has 1TB HDD + 256GB SSD, and 24GB of RAM. I can definitely spare
> 50MB of disk space and 200MB of RAM.

How much cache does your laptop have? All this RAM usage completely thrashes
any caches anywhere. Page caches, disk cache, etc.

Slack alone takes a heavy toll on my laptop. Combine it with any heavy website
on FF (which has gone insane on mac since Quantum) and the laptop is ready for
take-off.

Not to mention that we are slowly putting a ±$1k price tag on "comfortable
computing". People who spend <$300 on a computer are absolutely screwed, even
though they have orders of magnitude more power than a device which took
humanity to the moon (to use a hackneyed comparison).

I find using developer computers as a measuring stick a painfully elitist
perspective. In an ideal world, software developers would be banned from
spending more than $250 on hardware. Ever. [for their current workstation].
That would do more to change the face of software than any processor
improvement ever did.

> Many times it's either an Electron app or no app at all, as many companies
> wouldn't bother supporting Linux if Electron didn't make it so cheap and
> easy.

I agree with this. However, focusing on first order consequences can be
deceptive. Perhaps it is precisely the existence of Electron that suffocates
any budding competition for more performant but _slightly_ more involved
alternatives?

~~~
RaleyField
Make WPF-like replacement that works on Windows, macOS, Linux, Android, iOS
and their browsers and we will all switch. You are demanding that we all
become mega crops with N teams duplicating the same code in with native
frameworks and that just won't happen because a) we don't have cash laying
around b) users don't know the difference between 10 MB app and 200 MB app,
only us do.

> How much cache does your laptop have?

Enough. How much bandwidth does my ram have? Enough that it can fill cpu
caches in I don't notice time. I still have 12 year old Conroe with spinning
hard disk laying around and it never had any problem running VS Code so
there's that data point.

~~~
snuxoll
> Make WPF-like replacement that works on Windows, macOS, Linux, Android, iOS
> and their browsers and we will all switch.

Literally Xamarin.Forms, though without the Linux support still (and browsers,
of course, because native apps aren’t web apps).

------
rmason
Here's a link to the libui library that Vuido is based upon:

[https://github.com/andlabs/libui](https://github.com/andlabs/libui)

Both libui and Vuido are works in progress but seemed quite promising and are
being actively developed.

------
_asummers
So to me, the issue with Electron is that I'm already running Chrome, so I
should be able to take advantage of that. In particular, if I have N electron
apps, I want 1 Chrome running. I don't want to run certain applications inside
the browser, I want the separate app icon, etc. Is there anything that is
being done in Chrome/FF to support that kind of thing? That way it's up to the
site consumer's preference how they wish to consume the app, by having a
native browser consumer and not starting their own little Chrome each time.
And for the developer, they're basically shipping "containerized" code around,
modulo some features being unavailable in browser vs native, which could be
feature detected.

~~~
WhitneyLand
“I want 1 Chrome running”

Why? To save a little disk space? There are a lot of downsides to that.
Microsoft thought DLLs were a good idea once.

I know Chrome has better isolation but it’s still not as idiot proof and most
importantly, as cheap to support as having your own totally independent app.

If a user contacts you with a bug, you immediate know for a fact it has
nothing to do with any new chrome update or possible problems chrome may be
having and vastly narrow down the problem space.

~~~
easytiger
Given that chrome gives each tab its own heavy weight forked process, it is
also pretty irrelevant conceptually. OP didn't explain what advantage he
thought he'd get out of it being the same process he already runs other than
saving some MB of exe cache. Perhaps that's all he wants.

Either way these solutions are all rubbish.

------
WhitneyLand
What would be the disadvantages of just using a custom build of firefox for
apps that bundles non-sandboxed libraries as needed?

So for example, firefox.exe could actually be built to be my app.exe, with the
generic browser UI replaced with specific app menus.

The build could have options for bundling any library, or provide a simple OS
essentials abstraction library with a web sockets or local web server http
interface.

It would be a single use custom UI browser “app” with the same potential power
as an OS native app but easily portable.

Benefits

\- I think FF is a ~50MB download so after stripping out a little generic
browser functionality, simple utility apps should be about the same

\- One of the biggest problems with these ideas normally is the actual multi-
platform deployment can become the hardest part of a cross platform app, yet
FF has a polished multi platform install/setup solution already fully figured
out and maintained.

~~~
jitl
This is exactly what Electron / CEF is, except the tooling already exists for
CEF, and there’s already a large ecosystem of libraries.

~~~
WhitneyLand
There is theory and practice. similar concepts, but for so long we’ve heard
big hassles with electron solution real life deployment solutions (some
companies only don’t even deploy electron multi platform, if it were that
simple more would).

Also with memory usuage which was mentioned elsewhere in this discusssion.

The idea is maybe it could be done better. On the other hand maybe Electron
has made great strides over last year or so, it would depend on how much
progress has been made.

Cross platform code is great but in the end doing that while getting something
out the door end to end multiplatform as fast as possible is key, while at the
same time not having performance significantly worse than it would normally be
for the same code in an off the shelf browser.

------
pjmlp
> Vuido aims to be what Qt used to be, before it became almost as bloated as
> Electron,

Really?!?

I had to laugh at this one.

------
droidist2
Interesting, this reminds me of Proton Native. Both are based on libui.

Proton discussion:
[https://news.ycombinator.com/item?id=16978901](https://news.ycombinator.com/item?id=16978901)

libui: [https://github.com/andlabs/libui](https://github.com/andlabs/libui)

~~~
roryisok
I'm thinking you didn't read the post because the first two sentences are
about this being based on Proton Native

~~~
codetrotter
Inspired by, not based on, I think.

FTA: "Just like Proton Native, Vuido is based on libui, which is currently an
alpha version, but I think that it looks very promising."

~~~
yedpodtrzitko
That's not the point.

------
whoaminow
It's a good shift away from the crap that is Electron.js but once we are using
a native toolkit, why not use a native language too? ;-)

~~~
zengid
I think the whole 'hot-module-reloading' thing is pretty compelling, but its
possible to do apart from a JS environment (see flutter for instance). The
library that Vuido runs on, libui, has bindings to all kinds of languages:

[https://github.com/andlabs/libui#language-
bindings](https://github.com/andlabs/libui#language-bindings)

------
NetOpWibby
Link to repo:
[https://github.com/mimecorg/vuido](https://github.com/mimecorg/vuido)

I’m glad this exists, I didn’t want to setup a whole React thing.

------
tormeh
There is a movement to use the same tech on desktop as you would on the web,
but is anything moving in the opposite direction? Will there be a web version
of QT or something? That would be great.

~~~
mwcampbell
> Will there be a web version of QT or something? That would be great.

There _is_ a Web(Assembly) version of Qt, currently as a technology preview.
It's not great IMO, because it's inaccessible to screen readers and other
assistive technologies. The lack of accessibility is because the current
solution for web application accessibility, setting ARIA attributes on HTML
elements, isn't a good fit for rendering to canvas or WebGL. Maybe the browser
vendors will provide an alternative. Then again, maybe they won't, and Qt will
have to work around that impedance mismatch. In the meantime, I recommend that
developers continue developing web applications using web technologies
directly.

------
diaz
I don't use these technologies but looking at the screenshot in the post, it
triggers some memories of Adobe's Flex XML declarative UI making. It feels
like the same technologies just continue to be reinvented. Flex and Air were
gonna be the future everybody was talking about it... And here we are now.

------
framp
There is also just JavaScript in Qt which is more mature and probably
similarly - if not better - performing.

[https://doc.qt.io/archives/qt-4.8/qdeclarativejavascript.htm...](https://doc.qt.io/archives/qt-4.8/qdeclarativejavascript.html)

------
tribby
awesome. this is clearly an early proof-of-concept but I'll keep my eye on the
project. I'm also hopeful for weex (like react native for vue). despite moving
from alibaba to become an apache foundation incubator project, it has a long
way to go in terms of documentation -- nativescript seems to be winning that
particular battle in the vue world right now. it's exciting to see a desktop
project come along. vue makes a lot of sense for native apps because its
transition engine really lends itself to a "native feel" without a lot of
development overhead[1]. great work.

1\. [https://css-tricks.com/native-like-animations-for-page-
trans...](https://css-tricks.com/native-like-animations-for-page-transitions-
on-the-web/)

------
rapsey
unfortunately being based on libui it is limited to barely be usable. libui
does not even have a listbox.

~~~
buovjaga
It is being actively worked on, though:
[https://github.com/andlabs/libui/issues/310](https://github.com/andlabs/libui/issues/310)

------
zengid
I think the coolest thing about this is that it's using libui [1], so whether
you're trying to work on Proton Native, or Vuido, or any other flavor of
NodeJS-to-Native-GUI [2], we'll hopefully end up contributing to a single
library. (PS: libui has bindings to other languages as well [3]!)

[1] [https://github.com/andlabs/libui](https://github.com/andlabs/libui)

[2] [https://github.com/parro-it/libui-node](https://github.com/parro-
it/libui-node)

[3] [https://github.com/andlabs/libui#language-
bindings](https://github.com/andlabs/libui#language-bindings)

~~~
parro-it
> NodeJS-to-Native-GUI

I feel I have to find a better name for libui-node

------
yroc92
Why don’t I see more “native” applications just running through a locally
hosted web server? It’s the best of both worlds: file system access with your
server, and a great environment for developing a UI (any browser).

------
ttoinou
Nice. For those who don't care about native UI : has anyone tried to ship a
react-like library used in the OS native browser ? That way you avoid Electron
bloat, you just need to take care of the design for different native browsers.

~~~
roryisok
There's this

[https://github.com/zserge/webview](https://github.com/zserge/webview)

Basically a webview which can use a c++ backend and a js/html front-end, cross
platform

------
wetpaws
Confirm me if I'm wrong, but didn't you just invent GTK?

~~~
gnud
You're wrong. Libui uses GTK on linux, but uses native toolkits on windows and
MacOS.

~~~
zerr
So wxWidgets but in C. I wish it used snake_case (similar to Gtk).

------
roryisok
This is a cool project, although I'm starting to not like the look of native
apps anymore.

This will hopefully appease the electron haters but I suspect someone will
still complain about this being JavaScript

~~~
mwcampbell
> I'm starting to not like the look of native apps anymore.

Can you please explain why? On which platform, specifically?

~~~
IggleSniggle
Speaking just for myself...I like that Slack has the same look and feel no
matter what platform I bring it up on. I prefer a unified cross-platform
experience over a unified platform experience. I want my OS to disappear. I am
probably biased by regularly targeting multi platform myself.

This causes me to favor other lowest common denominator idioms as well, like
python 2.7 over 3, unconfigured vim, bash on windows, etc. When this isn’t
possible, I favor technologies that allow me to synchronize configurations
across platforms quickly and easily.

------
gcb0
you all need mote tk in your life.

maybe it's time for jsTk?

~~~
mwcampbell
Please no! Tk is inaccessible to blind users with screen readers, at least on
Windows. This has been the case for decades.

~~~
gcb0
thanks. Didn't know about that. only made small tools for myself with tk till
now.

------
Rjevski
One question: why would you use the awful clusterfuck that is JavaScript on
the desktop where you’ve got the freedom to choose from dozens of lovely
languages that actually are a pleasure to use?

JS is a necessary evil on the web, but why inflict such pain to yourself when
you’re able to use something else?

~~~
roryisok
Why do you speak English when you could be speaking French? Because it's what
you know, and lucky for you it's everywhere and you don't need to learn
French.

I'm making some assumptions about you as a person but you take my point I
hope. People use JavaScript over other languages because they already know it
and, hey, look, you can use it anywhere. Sure, it might be more efficient to
go and learn python or C++ or assembly or whatever but most people are happier
to leverage the skills they already have than go and learn a new language for
one app.

I'm a JavaScript coder by profession and in my extremely limited spare time I
want to build things, and if i use JavaScript it maximizes my time.

~~~
Rjevski
But don’t you believe in using the right tool for the job?

JavaScript is barely acceptable on the web, but again it’s a necessary evil as
you can’t easily use anything else.

But why use an inadequate tool on the desktop? The perceived time you save
upfront would backfire later on.

Now I’m not saying go and spend a year learning another language just to make
a side project (by all means use JS or whatever you’re familiar with), but if
you’re making a production-grade app, PLEASE use the right tool for the job
and it ain’t JS.

I, for one, am sick of JS & Electron contaminating apps I use daily like
Spotify, Slack, Signal, Telegram, etc. I wouldn’t mind it too much if this was
a niche thing and there were alternatives, but there aren’t. JS on the desktop
should die.

~~~
aaron-lebo
I don't really think JS is bad. I actually prefer it to most languages.

It's fast, concise, flexible, and has lots of modern features. It has some
weak spots, but all languages do. When people are so ideological about the
language it tells me they either haven't used it much or they are unrealistic
about flaws in other languages.

~~~
Rjevski
> haven't used it much

I actually used it, and hated it quite a bit (although ES6 solves most of my
gripes with it).

I understand and appreciate the necessity of JS on the web. JS is also the
perfect tool for that job as it’s been designed with the web & browsers in
mind, closely tied to HTML & CSS, and while it has overheads those are a
necessary evil in an environment where it’s commonplace to execute untrusted
code.

But it’s however completely inadequate for the desktop. Your users already
trust you since they run your binary Electron wrapper, so the “untrusted code”
argument goes out the window. You’re basically taking on an extreme overhead
(in terms of battery life and RAM usage) for no benefit at all. HTML/CSS is
not that great either, IMO native elements provided by the OS deliver a much
better UX and actually behave consistently across the entire OS.

