Hacker News Reader

Comment by dmitrybrant | Hacker News Reader

I specialize in data recovery / digital forensics tools, which require very low-level disk access to be able to read physical media at the block level. I doubt there will ever be an HTML5 standard for low-level disk access.

But aside from my particular specialty, I also prefer any other software I use to be fully native. I'm surprised that's such a controversial thing to ask for these days. All I ask is so precious little:

* I want the software I use to be designed to run on the CPU that I own!

* I want software that doesn't require me to upgrade my laptop every two years because of how inefficient it gets with every iteration.

* I want software that isn't laughably bloated. I think we have a real problem when we don't bat an eye upon seeing the most rudimentary apps requiring 200+ MB of space.

View on HN

I remember hanging out in /r/Unity3d and some newbie posted a download for their completed game. It was super basic - just a game where you move a cube around a grid, but the size of the game was insane, like half a gig.

The dev who posted it seemed perplexed when people told him the game was 100x bigger than it should be.

He was probably expecting useful feedback or even praise.

I hope that you did the kind thing and showed them how to adjust what gets compiled into their package, depending on whether they are targeting a development or production build.

Nothing worse than people who mock beginners showing their first work. We were all there, once.

> I doubt there will ever be an HTML5 standard for low-level disk access.

It's clear you've never worked with Electron; nothing about its system-level access has anything to do with HTML5 or related standards.

All of that lives in NodeJS, which offers reasonably low-level APIs for accessing system resources. For cases where that's not enough Node can easily call out to logic written in other languages, either directly through FFI (foreign function interfaces) or by spinning up an independent binary via the shell.

This is the problem with this discourse: the vast majority of the Electron haters are people who have no idea what they're talking about when it comes to the actual thing they're criticizing. It's particularly hypocritical when they go so far as to frame "JavaScript hipsters" as some combination of ignorant, inexperienced, and/or lazy.

I don't mean to hate on any particular groups of people, I'm simply a proponent of using the right tools for the job.

I can only speak from my own experience, but I have never dealt with an Electron app that wasn't noticeably slower than other apps, to the point of standing out like a sore thumb.

Or, put another way, when I notice an app performing especially slowly, I think to myself, "that's probably an Electron app", and I'm usually right.

Have you looked into webassembly and how browsers give access to filesystems[1], there could be hope for a future of high performant filesystem access.

[1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystem

that's not low level disk access

Can you explain how it isn’t?

If you are accessing the file system, you are accessing an abstraction, not the actual disk data (which is another abstraction on top of the actual hardware).

Does it give you access to /dev/disk0 (or /dev/nvme0, or /dev/sda0, or /dev/rdisk0 etc)? If not, no.

From the linked article:

This interface will not grant you access to the users filesystem. Instead you will have a "virtual drive" within the browser sandbox. If you want to gain access to the users filesystem you need to invoke the user by eg. installing a Chrome extension. The relevant Chrome API can be found here.

Reply on news.ycombinator.com