λ /Applications/Trello.app/Contents ◆ tree -L 2
.
├── Frameworks
│ ├── Electron\ Framework.framework
│ ├── Trello\ Helper\ EH.app
│ ├── Trello\ Helper\ NP.app
│ └── Trello\ Helper.app
├── Info.plist
I came here to post a comment asking if it was an Electron app. Hopefully Electron's overhead can become lighter in the future making useful applications like this less bloated.
I’ve been a heavy Trello advocate since it launched, but the lack of real native clients puts a pretty low ceiling on it’s usefulness at scale.
Atlassian has plenty of native developers on their team, not sure why they would take this route...
The implementation with Electron, as most cases, sucks.
I work with a startup and they have a hybrid app, which binary is 3.5 megabytes [1]. UI is JS/HTML/CSS and is almost the same bundle as the web version [2]
Trello's app is 66MB [3]
1: https://itunes.apple.com/us/app/ninox-database/id901110441?m...
3: https://itunes.apple.com/us/app/trello/id1278508951?mt=12
I intentionally do this with Chrome's Tools > More Tools > Add to Desktop > Open as New Window option. Wrapping Spotify Web, Outlook 365 and HipChat into their own "application"s lets me treat them as if they are native apps, but for some reason it uses a lot less resources than the actual native apps.
Because most "actual native apps" now are not native apps but electron or some other HTML + JS + CSS wrapper running an entire separate browser to render the app. By running the web page as separate windows you're effectively getting the same app but sharing the browser overhead.
I really hope this trend stops soon.
In what way? That services stop trying to be desktop applications and live on the web and web browser? Or that Electron itself is not an adequate framework for cross-platform development?
Genuinely curious, is there something I'm missing out on / some way they work better out of the browser?
Maybe I'm missing the key point of a desktop Trello - what does it do that can't be done on a webpage?
Electron is just kids re-discovering MSHTML.dll.
I have seen this twice now; our file transfer service was being hindered by poor file API support by the browsers, so we built a desktop app to wrap the web app and provide better file access. And for a shopping app to get around iframe restrictions.
This app will do that, so I'll seriously think about Trello again.
Trello is also a core part of our workflow (we're custom software developers) and so Cmd/Ctrl + T to open a new tab and type in "tre"...<Enter> to load Trello is basically muscle memory at this point.
All of that is to say, what's the need for a "native" app? I say "native" because it's Electron, which isn't really native per se. But still, why??
It's also pretty darn big though.
Still need to design your application to sync data - that's the hard part.
Electron has given a lot of devs that cop-out. I would rather Electron didn't exist... you'd have fewer desktop apps yes, but the fewer that are out there would be higher quality, and there'd be more work for people that don't buy into this web-must-be-everywhere mentality.
No reason this has to require an electron wrapper, you could do it with the 'save to desktop' options, not sure whether any browser actually offers it yet though.
And since all libraries are already on your OS, the build is really small, as well as the memory footprint.
1: https://developer.apple.com/documentation/webkit/wkwebview
I was bearish on it initially but it's starting to prove itself in a way where I'm seriously considering it.
Also as a former desktop developer who moved to the web a lot of what it does looks pretty good tbh.
That and TypeScript has completely changed my opinion of "client side" web development, it's solved so much of the pain it's unbelievable and is good enough I'd consider it for desktop development for me the killer example is vscode - proof that you can write fast applications on the platform.
Your inner trader is peeking out... :)
Yet (modulo mobile) somehow companies managed to do this in the 90s with far less productive development tools. The difference is the diluted power of the consumer: when software was a purchased product made for Ks of subscribing customers, small contingents of customers being upset about subpar UI and performance was a real threat to the viability of your business. Now Outlook or any Amazon app can be absolute slow, buggy garbage on nearly every platform (and they are), but the enormous customer base (diluting collective action) and entrenchment of locked-in platforms and data mean there's little incentive to obsess about product quality. Instead companies prioritize cost reduction, new customer acquisition (focusing on product chrome refreshes instead of robustness), or just give over to development momentum apathetic to quality.
That's cutting out a huge bit of functionality.
> small contingents of customers being upset about subpar UI and performance was a real threat to the viability of your business
Only if there was a better alternative available, there was still plenty of garbage software. If someone made a product like Outlook with the backing that MS can provide, but better performing, everyone would use it. Case in point, G-Mail
