5 ms·
>Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages Just wanted to name th
by ivan_gammel 10y ago
>Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages
Just wanted to name the most obvious alternative: embedded browser component like QtWebKit, which allows to code most of the application logic on the language of your choice. Embedded browsers are the way people have been doing it since circa 2000 (by then, Windows was dominating platform and you could use embedded IE for rendering - the typical app size was much smaller than 200 Mb btw). I remember earning some money on a side project around that time - the CD catalog of bathroom equipment, which I implemented by borrowing huge part of my customer's website and embedding it in CBuilder app with few improvements for richer UX.
- mateuszf 10y agoBut then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.
- alexchamberlain 10y agoShould you be sharing that code? Should there be any business logic in the UI, or should it be pushed back into services that can be shared across both?
- mateuszf 10y agoMaybe not all the code, but you can share lot of the UI behaviour, which is usually quite complicated. This kind of sharing allows you to to have a very similar experience in both places too.
- ivan_gammel 10y agoValid argument, but only in case if that web app exists. But if it exists and you want to share the code, there's no point in using Electron or building a desktop app at all: you can just create a shortcut on the desktop or even turn it into offline web app in Chrome.
- bryanrasmussen 10y agonot really, there can be lots of reuse of code between the two apps without them being exactly the same. Reuse of major parts of your codebase have been a business case for many years, without requiring that you reuse all that codebase.
- Splines 10y ago> Yes - electron apps are slower and eat more ram - but someone else is paying for that. I hope you're being facetious here. If you develop any kind of desktop application and truly believe this, honestly this is disappointing to read.
- bryanrasmussen 10y agowell if the developers or company don't actually use the app then their users are the ones paying for the ram, aren't they?
- dagw 10y agoDoing something quick and dirty in electron takes N hours. Doing a 'proper' cross platform native app the right way takes N+P hours. If people are willing to pay for those extra P hours then I'd be more than happy to do things the 'right' way. However almost nobody is. I've spent a lot of time on team web-apps-suck, and in many ways I'm still a casual fan. But the truth is I can go from zero to good enough much faster with web apps than anything else, and unfortunately most people only want to pay for good enough.
- groovy2shoes 10y ago> Doing something quick and dirty in electron takes N hours. Doing a 'proper' cross platform native app the right way takes N+P hours. Source? Really, I'm not at all convinced that whipping up an Electron app is inherently quicker than whipping up a native app. Especially when we have robust, mature RAD tools for native toolkits, and things like Qt Quick, WPF, and Java FX let you go the whole "write your GUI in some markup language" route, if that's your bag.
- RandomOpinion 10y ago>Yes - electron apps are slower and eat more ram - but someone else is paying for that. Not that there aren't a lot of posts here defending Electron that basically say the same thing but don't you feel embarrassed in the slightest for saying that? Yes, there's a lot of things we, as coders, can do to make our lives more convenient by treating bandwidth, RAM, and CPU wastage as an externality that can be shoved off onto the end-user to pay for. That doesn't mean we should.
- mateuszf 10y agoI'm playing devils advocate here. It doesn't mean this is my way of thinking.
- jeremiep 10y agoI'm fairly certain electron could easily be modified to be installed once and used as the launcher for its applications. I'm also fairly certain we'll see this in the future. Therefore all claims that electron bloats 200Mb are just temporary. Its still a relatively young technology with huge potential (which also means huge potential for misuse!) I spent 5+ years writing native GUI apps in half a dozen frameworks, I hope to never do so again unless the project's requirements ask for it, which I don't see happening for most use-cases out there. Besides, almost nobody writes true native applications anymore - its all C# now which is ironic as its also extremely bloated with huge pools of average developers at best.
- Mithaldu 10y agoEven if the app is smaller on drive, it still takes ~200mb in ram for even the smallest apps.
- jeremiep 10y agoDropbox itself takes 200Mb and its a simple python app. Google drive takes 300Mb. VSCode takes about 100Mb of ram with a project opened right now. Even my Emacs takes 250Mb and I literally live inside it. All of them have at least 2Gb of virtual memory being mapped to them. Yet I still have 9Gb of free ram. If you want to go against bloat, you might just as well uninstall every single software from your computer, including its OS.
- hajile 10y agoQt now just embeds an outdated version of blink and v8. Not really a better solution.