Hacker News Reader

Comment by milansuk | Hacker News Reader

>It should be fast. We don’t want to make round-trips to a server to interact with the application.

The cloud apps are not slow only because of moving data, but there is also a problem that an average server is fast(16cores CPU + 64GB RAM), but If it's used by let's say 100users, It means one user has only 0.16core + 0.64GB memory. So an average laptop(4cores/4GB) or phone(4cores/1GB) is way faster. Basically people buy billions of transistors to use them only as a terminal to the cloud. Not to mention privacy risks.

A week ago, I did showHN for skyalt.com. It's a local accessible database(+ analytics, which is coming soon). I'm still blown away how fast it is, that you can put tens of millions of rows to single table with many columns on consumer hardware and you don't pay for scale or attachments.

View on HN

> If it's used by let's say 100users, It means one user has only 0.16core + 0.64GB memory. So an average laptop(4cores/4GB) or phone(4cores/1GB) is way faster.

This is overly simplistic. You're pretending that cores/memory are "allocated" to users, but really, a user might only make a few tens of requests, and the server only needs to spend a second or two servicing each request. On a server with only 100 users, it could very well be the case that a user has all 16 cores + 64gb available at the time they make a request. Also, as another commenter pointed out, you could use a large chunk of that memory for shared resources, and then each request might only need a few mb of memory to service a request.

I agree. It highly depends on the use-case.

That's not a fair comparison since most of the memory usage is just loading the app in to memory and then everyone is sharing the same app already loaded. Web apps don't have to be nearly as slow as they are. It's just that it's easier to make a slow app than a fast one. Also desktop apps are becoming super slow and bloated now thanks to electron.

Sad about the Electron route. I don't consider it to be "desktop" software. Native toolkits are miles faster than the extremely lazy approach of running an entire new browser instance because someone wanted to write javascript for their "app". It's terrible.

In my opinion it's not all about lazyness.

You have to consider the costs of building an app native for each platform vs a cross platform framework built with javascript. Single javascript code base for all platforms is a lot cheaper.

I am not sure on that really. I built a cross-platform control software for high-end audio equipment that ran on macOS and Windows and did all of its own drawing (charts, graphs, ALL controls [knobs, buttons, grids, faders etc etc etc], 2D overview with links of all devices, 3D scene of venue layout with OpenGL, diagrams, alerts and floating popup windows). No bitmaps used anywhere, all generated in code. Another guy handled the network stack that it used which was an entirely-bespoke protocol and he wrote the control firmware on the equipment. This was in C++ with wxWidgets. It redrew every 50ms and logged data received so you could keep historic data of all devices on the network.

I am pretty sure that all of these giant companies releasing garbage Electron apps have a bigger budget than the budget on the 2 people (us!) that wrote what we wrote in 2.5 years.

When I see how abysmal apps like Skype and Slack are, I despair. Colossal amounts of RAM and simply displaying text and pictures.

It might be more convenient for the developer to write in the first language they learned but it is producing giant bloated applications. More CPU cycles, more allocations, more power consumed, shorter battery life on mobile devices (laptops), more charging of devices, more fossil fuels burned.

The difference between you and the big corps is, you care, they don't.

You care about delivering a high quality and high performance application, big corps just want to sell a product.

Also, just because they have a bigger budget doesn't mean they are all about spending it, they probably want to squeeze it as much as they can.

Sad but true. A soul-destroying observation if I may say so!

> Also desktop apps are becoming super slow and bloated now thanks to electron.

I can't quite get this point. From my perspective software engineers love/adore electron applications.

Look at VScode as the example:

- electron based javascript application

- telemetry included

- proprietary build with "open core"

It is literally the most popular code editor right now (p.s. I don't use it). Why as a tech savvy user you will use something you don't like for 5-10 hours each day to do your work?

Only answer I can see that electron is not an issue here.

Obvious answer: it's the only IDE-like thing that's both well supported and caters to the huge population of JavaScript-only developers, who generally don't want to use IntelliJ or similar products because they can't customise it using only web-stack skills.

That is, if JetBrains had made JS plugins first class citizens of their products, possibly VS Code wouldn't be as popular as it is.

I use vscode even though I don't particularly like it. Imo rubymine is a better editor but vscode does 90% of the job while not costing $300/year.

I'm curious where you live. Is $300/year a big expense for you? Computers and developer salaries are usually much higher.

Sublime was the leader before VSCode and it had python plugins. VSCode is popular because it works so well with TypeScript

Electron makes it easy to build badly-performing apps. VSCode has put a lot of effort into avoiding this.

VSCode is proof that an Electron app can be performant, but that's not the rule, and most people writing Electron apps aren't as talented as the VSCode team.

Also, there's an expectation that an IDE will be somewhat heavyweight. I don't mind if VSCode or IntelliJ grabs a few gigs or RAM, because I live inside those applications and depend on the features they provide.

What I don't want or need is Yet Another Electron Based Markdown Editor that gobbles up half my laptop's memory so that I can edit a hundred line text document.

As a user of VSCode, I use it in spite of it being based on Electron because there are no other good alternatives. It is noticeably very slow on many tasks, and has a large startup time. I recently had it basically become unusable when opening a 2MB yacc file and had to switch to Sublime Text to edit the file. I much prefer Sublime Text in terms of speed, but VSCode simply has more and better extensions for different programming languages making it better for day-to-day coding. If somebody were to make a performant text editor that has similar features to VSCode I would switch in a heartbeat.

I was a strong supporter of VSCode for a long period of time. Now I realise there is always an alternative.

After taking time to learn my tools I can't use vscode anymore because of how inefficient and restrictive it is now for my workflow. I mainly prefer tools that can last a lifetime and time you've investend now can yeld much better results across several decades of usage.

Here is short list of tools I can't live without: magit, org-mode, undo-tree (actualy it was a feature request and vscode team said it's too compticated for broad audience), ability to hack your code editor as you wish. Ability to work all day without touching a mouse once.

I do not love electron applications. They gobble RAM. Allocation is the enemy of performance.

I stopped using VS Code because of the billions of files it ships with (does anyone remember DLLs these days or what?) and its performance and debugging capabilities were very disappointing.

> Also desktop apps are becoming super slow and bloated now thanks to electron.

The people who build slow electron apps would have built slow native apps, if they could build one.

Reply on news.ycombinator.com