5 ms·
Cool technique, but you hint at the best solution: "running all teams in a shared context to eliminate the overhead of one webview per team."
by pdog 10y ago
Cool technique, but you hint at the best solution: "running all teams in a shared context to eliminate the overhead of one webview per team."
- brianwawok 10y agoWouldn't the best solution be write it in C and have the entire app take 20MB of ram?
- deleted 10y ago[deleted]
- pjmlp 10y agoYes, it is incredible the amount of gimmicks web devs do instead of using the right tools for native development.
- joekim 10y agoCould you elaborate on what you think the elaborate on what the "right" tools would be?
- pjmlp 10y agoWrite in native languages, common to all platforms, using the OS specific APIs in each platform with the help on an abstraction layer. Lets pick C++ as an example of native language. Design the application architecture with the abstract ideas of what should be available across all platforms, but keeping in mind the native idioms. For each of such concepts, provide an interface (pure abstract classes in C++ speak) with an implementation for each OS. The actual cpp files are selected during the build process according to the OS being compiled, without any kind of #ifdefs. Then showing a notification to the user using this architecture is as simple as. auto notification = NotificationService.instance(); notification->show("New email available!"); Or opening a file, using the platform specific file dialogs: auto filePicker = Pickers.file_instance() auto filename = filePicker->open_file(); This are just two basic examples, the idea is not to replicate Qt, wxWidgets, JUCE,... rather pick just the concepts required for the application, not to build a full blown framework. This is the approach taken by quite a few companies. Of course, there is also the shortcut of using something like Qt, but then you need to live with the problem that the widgets aren't native, rather emulated. On the other hand, still outperforms any browser based application. The craziness with Electron based apps isn't nothing new to us oldies. Since the early days of the web, OSes have supported web widgets like MSHTML on Windows, Windows packaged Web Applications introduced on Windows Active Desktop, Mozilla's XUL and many others. They were never a match to native UI/UX.
- CapacitorSet 10y agoI think Slack is focusing on code reuse, eg. using the same HTML/CSS/JS codebase across all platforms - hence it would be preferrable to avoid having to compile for every platform.
- kalleboo 10y agoI don't think compliation is the issue, it's supporting the diverse platform APIs and UI toolkits.
- coldtea 10y agoThey use like 5 widgets (styled text, textfield, buttons, radios, etc). They could create their own UI toolkit with 1/10 the resources they have.
- pjmlp 10y agoApparently for the web dev generation, writing modular native code across OSes is a lost art, attained by us old druids not worth listening to.
- coldtea 10y agoYeah, and it's especially puzzling since they've given up one of the major hassles of going natively cross-platform anyway: having to support a native look and feel. Which makes creating a similar (uniform looking across platforms) native UI lib even easier than catering to the intricacies of each platform.
- joekim 10y agoIf this is true, then why are even bigger players with more resources like Facebook and Microsoft building on top of Electron instead of building natively? I surmise that you are not alone in believing that Slack would be better built as a native app. But if it's such a bad direction why are so many going down this road and what are they missing?
- deleted 10y ago[deleted]