7 ms·

I can't work out why you wouldn't develop a native app anyway - all this scaffolding in a Web UI to imitate native controls (like menus) seems completely backwa

I can't work out why you wouldn't develop a native app anyway - all this scaffolding in a Web UI to imitate native controls (like menus) seems completely backwards to me. Seems just lazy, but in an odd way because writing native apps isn't rocket science or difficult. It's not like they're implementing thousands of native controls or user interface components - a listview with an edit box at the bottom...

bananabiscuit 5y ago
I am a fan of native apps but I do have to admit it is nice that slack is -exactly- the same on any platform you access it from and that will continue to be the case without any effort from their developers. Different ports of native apps invariably start drifting unless lots of care is taken to make sure they don’t, and that does not happen to always be a priority for companies.
- yurishimo 5y ago
  This is true and a valid use case I think. Slack has abstracted enough of their UI to be re-usable cross platform that any re-write would likely be a regression. Look at 1Password and the amount of shit they get on HN with the beta version. Rewrites are hard and they take a tooooooon of time to do correctly and require a lot of engineering work to keep the product consistent across platforms. Do I wish that electron apps were better optimized? Yes, however, I also can accept the tradeoff for apps that need to work "everywhere". For the most part, Slack works just fine. Their problems are less the UI/UX and more to do with infrastructure. Slack rewriting to a native app would have a tiny (if any) effect on these outages.
zild3d 5y ago
> I can't work out why you wouldn't develop a native app anyway Really? One code base, one language, write features once. I think it's more about eng resourcing (headcount, onboarding, roadmap parity / feature drift, etc) than whether making a native app is hard. Anecdotal, but I feel like the React Natives and Electrons have made it so you see less "Sorry we're only on Mac", and "We're only on Android, iOS coming soon!" from apps
- speed_spread 5y ago
  > so you see less "Sorry we're only on Mac" There's the problem, nobody's sorry for offering only these static 100MB chat clients taking 2GB+ of RAM once launched. These apps are technically ridiculous, especially since all they do is embed a website. I mean, if all your company's willing to deliver is website, why even bother with the apps... But that's all fine right? We'll just upgrade to 64GB and 128GB machines soon!
uoaei 5y ago
We are seeing a bit of a backlash nowadays to "SPA everything // webdevs will save the world" naive techno-utopianism. Turns out that nail actually has some funny curves and the hammer isn't enough!
ActionHank 5y ago
Don't underestimate just how much devs can dig their heels in because they want to work in JS.
- TranquilMarmot 5y ago
  Is there a problem with this? Other than "JS Bad" chest-thumping? If so many devs want to work in it, there's probably a reason.
  - Nextgrid 5y ago
    If you're a JS developer and don't know (or enjoy) other languages, the most lucrative choice is to keep using JS and advocating for it whenever possible. If they've already got many JS developers onboard, it's normal that their opinion will be biased and they wouldn't want to switch to another language and essentially make their own job obsolete (except for the minority that also happens to be equally-proficient in whatever desktop programming language is chosen).
    - TranquilMarmot 5y ago
      I've been working at web-based startups for over 10 years now, and I know VERY few devs who only know JS. Most are also proficient (or at least have working knowledge of) whatever other languages we're using. Usually JVM-based like Java, Kotlin, Scala or something else like Ruby or Elixir. Everywhere I've been, we always "choose the right tool for the job". Recently, making apps that can run across every OS and in the browser, the right tool for the job has been JS (well, TypeScript these days, but same thing).
TranquilMarmot 5y ago
> It's not like they're implementing thousands of native controls or user interface components This is not true in any way. Slack also have workspaces, channels, notifications, video calls, file sharing, admin tools and probably even more features. It's not just IRC. Maybe writing a web-based app is lazy... except when you have to write native apps for macOS, Windows, Linux, Android, and iOS, and some people still need access via a browser. And each one has different ways of displaying images and videos and doing calls and handling file access. Now you have 5+ apps that you're maintaining, each with their own dedicated team since each one is unique. Want to roll out a new feature? Cool, now you have to write it 5 times across 5 teams. Good look coordinating that. I know there are technologies that let you share code across all of the different native clients. But a webview wrapped in i.e. Electron handles most of it for you! Why would you do it any other way except to appease people who complain about bloat?
- throw10920 5y ago
  This is a bad argument that is factually incorrect in some ways. Slack already has three different clients - a web one (which includes the Electron desktop wrappers), one for Android, and one for iOS. They've already demonstrated that they have the engineering resources and coordination to develop and maintain three completely separate clients (albeit poorly) - so adding a fourth one (native C++ codebase using Qt that would work well on Windows, Mac, and Linux) would not be the Herculean engineering effort required to go from one to five, and your implicit assertions that (1) they currently only have a single client and (2) that a different client would be required for each of Windows, macOS, and Linux are simply false. > But a webview wrapped in i.e. Electron handles most of it for you! Why would you do it any other way except to appease people who complain about bloat? Because (1) performance (2) accessibility and (3) stability - the things that users actually need. Slack's performance is extremely bad and you get people constantly complaining about it; their accessibility is janky and suboptimal because they're reinventing desktop UI controls on the web; and their applications have repeatedly broken (such as the disastrous input box rewrite[1]) because they're trying to do things with the web platform that it wasn't meant to do. (in case you're wondering how using a desktop client would help - you expose a "lite" version of your functionality in the web application and put the full functionality in the desktop tool) You're using "appease" as marketing-speak for "fix the very real problems with their web application that people constantly complain about". Slack should fix their application because it isn't serving the users well. Performance problems are functionality problems. As it stands, Slack is showing us that they aren't even pretending to care about their users - they're just trying to make a buck selling to large organizations. [1] https://news.ycombinator.com/item?id=21589647 https://news.ycombinator.com/item?id=21589647

bananabiscuit 5y ago

I am a fan of native apps but I do have to admit it is nice that slack is -exactly- the same on any platform you access it from and that will continue to be the case without any effort from their developers. Different ports of native apps invariably start drifting unless lots of care is taken to make sure they don’t, and that does not happen to always be a priority for companies.

yurishimo 5y ago
This is true and a valid use case I think. Slack has abstracted enough of their UI to be re-usable cross platform that any re-write would likely be a regression. Look at 1Password and the amount of shit they get on HN with the beta version. Rewrites are hard and they take a tooooooon of time to do correctly and require a lot of engineering work to keep the product consistent across platforms. Do I wish that electron apps were better optimized? Yes, however, I also can accept the tradeoff for apps that need to work "everywhere". For the most part, Slack works just fine. Their problems are less the UI/UX and more to do with infrastructure. Slack rewriting to a native app would have a tiny (if any) effect on these outages.

zild3d 5y ago

> I can't work out why you wouldn't develop a native app anyway Really? One code base, one language, write features once. I think it's more about eng resourcing (headcount, onboarding, roadmap parity / feature drift, etc) than whether making a native app is hard. Anecdotal, but I feel like the React Natives and Electrons have made it so you see less "Sorry we're only on Mac", and "We're only on Android, iOS coming soon!" from apps

speed_spread 5y ago
> so you see less "Sorry we're only on Mac" There's the problem, nobody's sorry for offering only these static 100MB chat clients taking 2GB+ of RAM once launched. These apps are technically ridiculous, especially since all they do is embed a website. I mean, if all your company's willing to deliver is website, why even bother with the apps... But that's all fine right? We'll just upgrade to 64GB and 128GB machines soon!

uoaei 5y ago

We are seeing a bit of a backlash nowadays to "SPA everything // webdevs will save the world" naive techno-utopianism. Turns out that nail actually has some funny curves and the hammer isn't enough!

ActionHank 5y ago

Don't underestimate just how much devs can dig their heels in because they want to work in JS.

TranquilMarmot 5y ago
Is there a problem with this? Other than "JS Bad" chest-thumping? If so many devs want to work in it, there's probably a reason.
- Nextgrid 5y ago
  If you're a JS developer and don't know (or enjoy) other languages, the most lucrative choice is to keep using JS and advocating for it whenever possible. If they've already got many JS developers onboard, it's normal that their opinion will be biased and they wouldn't want to switch to another language and essentially make their own job obsolete (except for the minority that also happens to be equally-proficient in whatever desktop programming language is chosen).
  - TranquilMarmot 5y ago
    I've been working at web-based startups for over 10 years now, and I know VERY few devs who only know JS. Most are also proficient (or at least have working knowledge of) whatever other languages we're using. Usually JVM-based like Java, Kotlin, Scala or something else like Ruby or Elixir. Everywhere I've been, we always "choose the right tool for the job". Recently, making apps that can run across every OS and in the browser, the right tool for the job has been JS (well, TypeScript these days, but same thing).

TranquilMarmot 5y ago

> It's not like they're implementing thousands of native controls or user interface components This is not true in any way. Slack also have workspaces, channels, notifications, video calls, file sharing, admin tools and probably even more features. It's not just IRC. Maybe writing a web-based app is lazy... except when you have to write native apps for macOS, Windows, Linux, Android, and iOS, and some people still need access via a browser. And each one has different ways of displaying images and videos and doing calls and handling file access. Now you have 5+ apps that you're maintaining, each with their own dedicated team since each one is unique. Want to roll out a new feature? Cool, now you have to write it 5 times across 5 teams. Good look coordinating that. I know there are technologies that let you share code across all of the different native clients. But a webview wrapped in i.e. Electron handles most of it for you! Why would you do it any other way except to appease people who complain about bloat?

throw10920 5y ago
This is a bad argument that is factually incorrect in some ways. Slack already has three different clients - a web one (which includes the Electron desktop wrappers), one for Android, and one for iOS. They've already demonstrated that they have the engineering resources and coordination to develop and maintain three completely separate clients (albeit poorly) - so adding a fourth one (native C++ codebase using Qt that would work well on Windows, Mac, and Linux) would not be the Herculean engineering effort required to go from one to five, and your implicit assertions that (1) they currently only have a single client and (2) that a different client would be required for each of Windows, macOS, and Linux are simply false. > But a webview wrapped in i.e. Electron handles most of it for you! Why would you do it any other way except to appease people who complain about bloat? Because (1) performance (2) accessibility and (3) stability - the things that users actually need. Slack's performance is extremely bad and you get people constantly complaining about it; their accessibility is janky and suboptimal because they're reinventing desktop UI controls on the web; and their applications have repeatedly broken (such as the disastrous input box rewrite[1]) because they're trying to do things with the web platform that it wasn't meant to do. (in case you're wondering how using a desktop client would help - you expose a "lite" version of your functionality in the web application and put the full functionality in the desktop tool) You're using "appease" as marketing-speak for "fix the very real problems with their web application that people constantly complain about". Slack should fix their application because it isn't serving the users well. Performance problems are functionality problems. As it stands, Slack is showing us that they aren't even pretending to care about their users - they're just trying to make a buck selling to large organizations. [1] https://news.ycombinator.com/item?id=21589647 https://news.ycombinator.com/item?id=21589647