Building a Desktop Application for Datasette | Hacker News Reader

Building a Desktop Application for Datasette

simonwillison.net

101 pointsTomte45 comments

For those wondering what "Datasette" is:

>Datasette is a tool for exploring and publishing data. It helps people take data of any shape or size, analyze and explore it, and publish it as an interactive website and accompanying API.

At first, i was a bit confused because i thought of the Commodore C64 Datasette [0] and wondered why one would need a desktop app for that...

[0] https://en.wikipedia.org/wiki/Commodore_Datasette

Same, but I was actually hoping for some kind of desktop app.

Thank you, I'm glad I wasn't the only one who went there...

Agree on the comments about getting setup with R/RStudio. Very straight forward for new comers and non-programmers which is >99% of the world.

I believe there is a market for a heavily simplified RStudio - call it RStudio Light. My belief it would crush the market (excel users, novice RStudio users) who simply want to summarise, plot data.

My vision is for a simple desktop app (with the core data functions in R) almost based off something like - https://cran.r-project.org/web/packages/esquisse/vignettes/g...

R is more popular than Python in science because scientists do statistics and R gives them literally every statistical analysis they'll ever need, many in the standard library itself, and is written by academic statisticians so everything has a "this is for doing quantitative data analysis " feel, as opposed to "this can be", or "this could be if you try this library". The greater popularity of R than Python predates RStudio.

It's great to see more desktop app in this space. Desktop app can handle big data much better (and cheaper) than a web app if the dataset is not terabytes.

I built a similar Desktop application where you can write SQL, though you will need to supply the CSV files. Here: https://superintendent.app

Very neat! I'm working on a similar open source project, at https://github.com/multiprocessio/datastation.

I started out just wanting a way to more easily connect code snippets, SQL, and graphs together. But it's evolved a bit more beyond that.

I thought Electron application is a web application running outside the browser window, and not what we usually called "Desktop Application".

From a users point of view a desktop application is something they can click on and it opens a window and starts working.

Yeah, that's exactly what I'm going for with this "desktop application".

I want my stuff to be usable by people who don't understand (or need to understand) the difference between a desktop application, a web application and a command-line application.

Ah another Electron shell being sold as "desktop".

They're common enough now that maybe we should just consider html, css, and js to be GUI scripting and markup languages in this context? Your browser is a desktop app and yet almost everything you do with it can only be done online. Perhaps it's fair to call this a Desktop app as it can be run offline, but not fair to call it a "native" desktop app.

It's not a problem of semantics or naming purity, it's a practical issue of resource consumption and UI/UX.

It's a tradeoff from some resources to other resources. If you want a native app, you can invest time to make one or money to pay someone to make one. If you don't, you'll have to pay with more CPU/RAM/brain power usage.

Small collection of Electron predecessors:

https://en.wikipedia.org/wiki/Active_Desktop

https://en.wikipedia.org/wiki/HTML_Application

https://en.wikipedia.org/wiki/XUL

https://www.allaboutsymbian.com/features/item/The_Wonderful_...

Eventually Electron will join them.

Pffft. Okay. That's quite a reach you've got there! ...as if any of those were ever near the same caliber as Electron in just about any aspect of user or developer needs.

> Eventually Electron will join them.

Perhaps it will, eventually, but not until we have better native desktop kits that fill the needs that Electron is serving right now and if they don't let you build apps with the most popular programming language in the world (that'd be JavaScript) then you can just forget it about it.

The good thing of being an old dog at this game is seeing technology of the same caliber as Electron, whatever that is supposed to mean, come and go every couple of years.

So I just tolerate it, while the pendulum reaches its point of maximum displacement.

Yeah I've only been programming since around 1981. Sorry to burst your bubble, but you're not the only old timer around here.

"Whatever that is supposed to mean", but you've still been seeing it? That makes no sense. None of those kits you listed have nearly the same robust quality of UX or DX as Electron. None of the technologies listed here even had a dependency manager (LOL). 3 of the kits weren't even cross platform!

Tolerate it? By making off-topic complaints about it on every post about a desktop app built with Electron, in an attempt to deride the conversation about the actual subject? Without even have a suggestion for a decent alternative?

Clearly there's some sort of disconnect with reality here.

Everyone is a dog on Internet, and yes I do tolerate and can't wait for something else to be the best thing ever after Electron.

Decent alternatives are standard Web applications that don't help the goals of Google turning the Web into ChromeOS.

Sure, everyone wants to be old on the Internet. I hear these twenty somethings constantly claiming that they’re in their sixties cuz it’s cool. /s

No, to tolerate something you need to have some measure of control over it in the first place. Given that you don’t have any control over Electron or other developers using it, you’re not actually tolerating anything. You have no choice in the matter. The only thing you could possibly do resembling tolerance would be to not comment on it... but you’re doing the opposite, even when nobody asked and in places you shouldn’t be.

You’re essentially just sitting here sneering at the community based on your ideology and your comments are not interesting or even practical.

Standard web applications that run in a browser are not an alternative and given that completely unreasonable suggestion I’ll just assume that this is satire.

Good luck stemming the tide!

To tolerate means having to endure using Electron based tools as part of job requirements, tools that have no place on privately owned computer systems.

It isn't a satire, it is the only place for applications on systems I own, either full Web or native, period.

On the systems I don't own, I tolerate Chrome packaged as "desktop" application.

Chrome is and always has been a native desktop application. Putting the word desktop in quotes doesn’t change that.

I thought the satire was the suggestion that standard web apps can replace a desktop apps.

It is, for the purposes of seeing Web pages, not for wrapping a Website into a custom build of it.

It's open source. It's for the purpose of using it for whatever we want to use it for. People decide this, not some ivory tower of objectivity that doesn't exist anywhere except in the minds of purists.

And it serves excellently as a framework for the desktop apps that use it. And that's why it's eating the market for purely native desktop apps.

Oh and Microsoft bought and uses the whole kit because they want to add to Chrome's hegemony right?

The small loud minority of HN complainers here should let them know that they're doing it all wrong. It's a whole 5 million lines of open source code - there's no way any other company but Google can maintain that! Brave doesn't exist either apparently.

It is only eating the market of GNU/Linux "desktops".

Care to cite a source to back that up?

Last I checked newer apps like Slack, Discord, VS Code and other market leaders use Electron to run on all platforms. I don't see a whole lot of new purely native desktop apps.

In any case, I use a Linux desktop for work so I'm quite happy either way.

For whatever it's worth -- this person "pjmlp", is probably one of the most fascinating and knowledgeable personalities I've ever stumbled across on the internet.

I've run across him everywhere. From places like the D-lang forums, /r/java, /r/dotnet, /r/cpp, Hacker News, decades old mailing lists for Oberon development, etc.

I wish he would write more, in blog form. He seems to have been around for decades and to know many obscure things which the world has forgotten.

There's also not a programming language I've ever seen him not intimately know the history and nuances of.

He's like some sort of omnipresent hacker-sage. I don't write or keep a blog myself because I feel like I've got nothing useful to add to the world, but I've considered trying to interview certain obscure programmers and other people I've come across that I find really impressive and fascinating, to share their stories with the world.

This person would be very on high on that list.

Perhaps you should start a fan club.

XUL was replaced by HTML and CSS - the UI for modern Firefox used to be XUL, now it's HTML (actually XHTML, I guess they couldn't quite kick the XML part of it): https://github.com/mozilla/gecko-dev/blob/master/browser/bas...

I assume they meant XULRunner[0], which was Mozilla's spiritual predecessor to Electron.

Some abandoned modern alternatives included Chromeless[1], Positron[2][3] and qbrt[4][5].

While technically possible using Firefox's XULRunner functionality (`firefox --app app.ini` — mostly undocumented, potentially unsupported in the future), as far as I can tell, Mozilla has abandoned the Electron approach for XUL/Gecko bundling, which is a shame since Firefox itself is basically just an implementation on top of the Gecko XUL runtime.

> "[Firefox] is distributed as the combination of a Gecko XUL runtime — libxul, other shared libraries, and non-browser-specific resources like those in toolkit/ — plus a Firefox XUL application — mostly just the files in Contents/Resources/browser/, plus the 'firefox' stub executable that loads Gecko and points it at a XUL application" [6]

On Android, there is also Geckoview[7][8] for embedding gecko.

[0]: https://en.wikipedia.org/wiki/XULRunner

[1]: https://github.com/mozilla/chromeless

[2]: https://github.com/mozilla/positron

[3]: http://web.archive.org/web/20210227132731/https://mykzilla.o...

[4]: https://github.com/mozilla/qbrt

[5]: http://web.archive.org/web/20210601133844/https://mykzilla.o...

[6]: http://web.archive.org/web/20210227132731/https://mykzilla.o...

[7]: https://github.com/mozilla/geckoview

[8]: https://mozilla.github.io/geckoview/

> ...currently the only way to build something on Gecko is to build a XUL application.

> You can do that in-tree by adding a XUL app to a fork of mozilla-central, like Positron does; you can do it out-of-tree in a distinct repo that uses a copy of Firefox and its –app flag to run the app, which I suspect is what mkaply is doing; or you can take a hybrid approach like Thunderbird (although this is deprecated and only supported for that app).

> In all cases, however, you’re building a XUL app, and a XUL app running on Firefox via –app is almost as capable and flexible as one built in-tree (except that you can’t make changes to Gecko itself).

> So it isn’t clear to me why developers wouldn’t build serious applications with that approach. Firefox itself is a serious application that uses that approach.

http://web.archive.org/web/20210227132731/https://mykzilla.o...

Ah another cheap Electron snipe being sold as "comment"

I figure if VS Code can call itself a desktop application then so can my thing.

As a somewhat experienced Mac developer, I'm not sure what Electron brings to the table for a project like this.

Why not create a simple Mac app with a web view? AFAIK the overhead of electron is more than 100MB, for an app that could probably be distributed as a ~10MB ZIP archive.

A native Mac app with a web view would also have much less RAM overhead -- and you wouldn't need to worry about updating Electron, since you would just be using frameworks bundled with macOS.

Sure, Electron is theoretically cross-platform. But you are going to need a lot of platform-specific code to package the app for macOS, Windows, or Linux anyway.

Anyway, just my two cents. Maybe Electron is less scary to get started for a web developer. But if you start a project like this, I really recommend giving AppKit and Swift a try. There's lots of examples out there. Native development is easier than you think.

What is even less scary is just to use the Web as is, and let the user keep just his favourite browser.

Because he's not just targeting mac. The code for packaging electron for different platforms has already been written.

I copy-paster the "installation" code on Github, and it runs fine on my Linux. I doubt you could do that with a native Mac app.

> Sure, Electron is theoretically cross-platform. But you are going to need a lot of platform-specific code to package the app for macOS, Windows, or Linux anyway.

Not really. The most platform-specific code I've got in my app is 1) the CI install instructions that use brew rather than apt-get [0] and 2) what exists in the application menu [1].

For packaging, electron-packager [2] handles everything else platform specific. So my Windows, Linux, and macOS builds share the exact same script [3]. The result gets zipped and uploaded to the relevant Github release page.

[0] https://github.com/multiprocessio/datastation/blob/master/.g...

[1] https://github.com/multiprocessio/datastation/blob/master/de...

[2] https://github.com/electron/electron-packager

[3] https://github.com/multiprocessio/datastation/blob/master/de...

Have you tried opening your app on a Mac? macOS literally suggests you move it to the trash.

Yeah, it's not signed at the moment. And fair that that's an extra platform-specific step.

Since my audience is developers and this is an early project I'm ok with them having to do the usual right-click Open and Open Anyway flow.

I feel it's a bit disingenuous to tell people how easy packaging Electron apps is when you skip the hard parts.

You can distribute native macOS apps that aren't signed too.

It's a step everyone needs to do regardless of electron or native.

So I don't think there's anything disingenuous here.

You said that you don't need platform specific code, but it turns out that's because you just skip the platform specific stuff, resulting in a product that I would not consider ready to ship.

Would that run on Linux and Windows?

Maybe because the author wants to target more than 15% of the desktop market?

https://gs.statcounter.com/os-market-share/desktop/worldwide

Don't feel bad - I'm writing this on a Linux laptop which has less market share (2%) than "unknown" (8%) on that graph.

I know it is a resource hog but I'm glad Electron is around so that I have access to the latest mainstream apps.

Reply on news.ycombinator.com