5 ms·
>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, bu
by milansuk 7y ago
>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.
- jdnenej 7y agoThat'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.
- 72deluxe 7y agoSad 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.
- calferreira 7y agoIn 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.
- 72deluxe 7y agoI 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.
- calferreira 7y agoThe 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.
- 72deluxe 7y agoSad but true. A soul-destroying observation if I may say so!
- vpEfljFL 7y ago> 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.
- thu2111 7y agoObvious 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.
- deleted 7y ago[deleted]
- jdnenej 7y agoI 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.
- thu2111 7y agoI'm curious where you live. Is $300/year a big expense for you? Computers and developer salaries are usually much higher.
- s_y_n_t_a_x 7y agoSublime was the leader before VSCode and it had python plugins. VSCode is popular because it works so well with TypeScript
- 7y ago
- deleted 7y ago[deleted]
- _squared_ 7y ago> 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.
- ksml 7y ago> 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.
- milansuk 7y agoI agree. It highly depends on the use-case.