31–40 of 141 posts
I have eagerly waited for this release, as it uses Chrome 66. Previous stable version used Chrome 61, which lacked some nice additions to JS, most notably for me - the complete Intl API support.
Oh look, finally you are getting some API that has existed on proper frameworks for more than a decade.
Earlier quoted context omitted.
It's still about twice the work. Or n-times, for n platforms.
Twice the work for front-end only, and even that is arguable. The overall logic of the client across different platforms will be very similar. The only thing that will change is language and implementation details.
Earlier quoted context omitted.
Twice the work for front-end only, and even that is arguable. The overall logic of the client across different platforms will be very similar. The only thing that will change is language and implementation details.
Different environment, different conventions, different bugs, different design, different support, different everything. Different teams that have to communicate. It is 'arguable' that it's twice the work, that is true. Twice is the lower bound.
Earlier quoted context omitted.
Is writing native apps honestly still so hard these days? I can appreciate the concerns about maintaining multiple codebases and dealing with different delivery mechanisms and their rules, but modern iOS/macOS and Windows APIs (at least; I cannot speak for Android and Linux) seem just as easy, let you work in arguably better languages, evolve at a faster rate, and provide a better experience for users and their machi…
It is. Especially for multi billion dollar companies with 100s of developers. Because you know careful evaluation, strategic direction, ROI etc has shown users prefer to update their own hardware instead of demanding companies to write efficient software.
Earlier quoted context omitted.
do you really though
If it makes for easier programming, yes. Writing Slack as a native app would be a massive pain. Especially due to all the web-like features it has, the fact that it's one codebase (mainly) for desktop and web. They also have to support Windows, Linux, Mac and mobile. Not an easy task
When you're working on your own project, some time sink that you didn't anticipate may be frustrating, but other than that, I definitely prefer it to coding something I already know how to do well.
I really hope whatever the NativeWindow changes are allow Slack to finally stop rendering when the app goes to the background. My battery has been killed a couple times by the Slack renderer using ~30% cpu playing gifs while the app isn't visible, and their support says its because they don't have a notification hook for minimizing
Is writing native apps honestly still so hard these days? I can appreciate the concerns about maintaining multiple codebases and dealing with different delivery mechanisms and their rules, but modern iOS/macOS and Windows APIs (at least; I cannot speak for Android and Linux) seem just as easy, let you work in arguably better languages, evolve at a faster rate, and provide a better experience for users and their machi…
If it was so easy as you said, a lot of macOS apps would've been portable to Windows years ago given the market share.
I work for a cross-platform company, Windows is a much more difficult to develop for compared to macOS. You can write a Cocoa UI but what do you do on Windows when you need to support Windows 7 and above? Win32 controls are grossly outdated but the best accessible/consistent experience across multiple versions, UWP controls is limited to Windows 10 and best under MS Store, WPF has been neglected but so far it is the fastest way to develop a GUI. Microsoft has decided to split UWP out of Microsoft Store to bring it to everyone with UWP XAML Islands etc.
The reason Slack prefers Electron is because you can just write the same HTML/CSS front-end, deploy it, and all Slack apps can simply be refreshed to show the newest UI. You cannot do that with native apps at all. You could get around with a few webviews embedded in the native apps but might as well go full Electron.
Earlier quoted context omitted.
There are more complex apps with native versions for multiple platforms, by smaller companies.
Such as?
Earlier quoted context omitted.
Is writing native apps honestly still so hard these days? I can appreciate the concerns about maintaining multiple codebases and dealing with different delivery mechanisms and their rules, but modern iOS/macOS and Windows APIs (at least; I cannot speak for Android and Linux) seem just as easy, let you work in arguably better languages, evolve at a faster rate, and provide a better experience for users and their machi…
It's not writing the native code that's the problem, it's designing the same GUI experience across platforms that's nearly impossible to do. If it was so easy as you said, a lot of macOS apps would've been portable to Windows years ago given the market share. I work for a cross-platform company, Windows is a much more difficult to develop for compared to macOS. You can write a Cocoa UI but what do you do on Windows w…
Qt and other GUI frameworks (like Juce and FLTK) exist and are blisteringly fast. You don't have to package an entire web browser to make something cross platform.
Earlier quoted context omitted.
It is. Especially for multi billion dollar companies with 100s of developers. Because you know careful evaluation, strategic direction, ROI etc has shown users prefer to update their own hardware instead of demanding companies to write efficient software.
If it's hard for a dev to write a native apps, then maybe they should re-evaluate their career choices and leave it to the competent ones.
Earlier quoted context omitted.
There are more complex apps with native versions for multiple platforms, by smaller companies.
Such as?
Then there are many games, which by their nature require native performance, and of course have to present the same frontend. :)