9 ms·

Creating a Slack app that uses fewer resources

125 points by underanalyzer 6y ago

rovr138 6y ago
Interesting. I’m now curious how multi[1] compares to Fluid[2]. I haven’t used it in a while, but that app used to be present on all my installs. Can’t remember what happened that I stopped using it. [1] - https://github.com/kofigumbs/multi https://github.com/kofigumbs/multi [2] - https://www.fluidapp.com/ https://www.fluidapp.com/
- sneak 6y ago
  Multi is open source, free-as-in-freedom software. Fluid was proprietary commercial software (and the author was also a real jerk).
  - rcarmo 6y ago
    Multi is open source software (GPLv3), but it is also paid software ($15).
    - sneak 6y ago
      If it's really GPLv3, then that would be called "donationware", as free-as-in-freedom software is also free-as-in-beer, as the author acknowledges in the README. The license seems ambiguous though because there's no LICENSE file in the repo and the website has copy about requiring a paid license to use the software; the only place GPLv3 is mentioned is in the README. I opened an issue requesting clarification. https://github.com/kofigumbs/multi/issues/37 https://github.com/kofigumbs/multi/issues/37
      - nottorp 6y ago
        Actually the GPL never says you cannot sell your software. It just says you have to provide source with it and you cannot prevent others from redistributing the source. Edit: no idea what the software mentioned above does, just correcting a common misconception.
      - hkgumbs 6y ago
        Author here—my understanding of the GPL matches that in the sibling comment. "GPL never says you cannot sell your software. It just says you have to provide source with it and you cannot prevent others from redistributing the source." If I'm incorrectly co-opting some open source nomenclature, I'd love if someone could let me know. As I said in the issue linked above, I do need to update the purchase website to bring that language more inline with what's on GitHub.
        mthoms 6y ago
        I didn't read your specific wording but generally - using GPL in this fashion is perfectly fine and quite common.
      - mthoms 6y ago
        Many shops that "sell" GPL software (ie. the massive WordPress plugin and theme ecosystem) are actually selling support, convenient, secure(ish) updates, and good karma. It's perfectly legit. You can find the sources for these items elsewhere on the web but the hassle and security implications just aren't worth it.
  - Wowfunhappy 6y ago
    What did the author of Fluid do?
  - mthoms 6y ago
    Why do you say he's a jerk? I had some positive interactions with the author. He went out of his way to explain how to do something that wasn't officially supported (how to include my own user scripts). Nothing major. But way better support than I ever expected for a $5(!) desktop app.
deleted 6y ago
[deleted]
Fizzadar 6y ago
I've toyed around with this idea before[1], and am v.excited to see Multi.app as a packaged up/refined version, awesome stuff. [1] - https://pointlessramblings.com/posts/why-always-electron/ https://pointlessramblings.com/posts/why-always-electron/
anaisbetts 6y ago
In this screenshot, this app is using 286MB of memory and the official Slack app is using 200MB, how is this better? fwiw, this is how the original Slack Mac app worked and it sucked. We had to tell users to upgrade their OS so that their app worked, because NSWebView (and WKWebView) are tied to the OS release. If their computer was too old, telling a customer to Buy a new Mac is a pretty terrible experience.
- masklinn 6y ago
  > In this screenshot, this app is using 286MB of memory and the official Slack app is using 200MB, how is this better? Yes not sure where they got the 1.2x ratio in their favor, although if we're only rounding to the nearest unit the official slack uses 220MB, not 200. TBF the machine has plenty of memory available, so trading some memory for less CPU time, less GPU time, better idling and faster startup seems… a pretty good tradeoff. The one thing I'm doubtful of is whether the official slack application really does nothing but wrap the webapp with no additional functions?
  - anaisbetts 6y ago
    It does not - the Slack app injects extra APIs into the DOM, and the Slack webapp recognizes it's being loaded in the Desktop app and adds additional functionality (the Downloads pane for example)
  - sriku 6y ago
    > the machine has plenty of memory available On my MacBookAir with 4GB of RAM, Gmail+GCalendar+Slack+GChat+Trello+Docs is enough to put memory pressure on the system. Gmail+Calendar alone end up taking up 1.5-2GB after a while. No respect for memory.
    - devwastaken 6y ago
      No one should subscribe to building software for a purposefully underpowered and outrageously overpriced computer. You have the responsibility to have better hardware than a 2005 pc.
znpy 6y ago
"I have created a slack app" -- just repackaged a webview. I was intrigued because slack used to have APIs and and IRC proxy, and I was wondering if the author has used some kind of weird way to connect to slack and impersonate an user.
- akx 6y ago
  Slack still has the same realtime and RPC-style APIs.
  - p_l 6y ago
    It's also actively fighting against just writing an alternative client, IIRC from my experiences trying to run weechat-slack
    - e12e 6y ago
      My experience with wee-slack is pretty good, actually. Although lately I've been running the "native" app.
  - znpy 6y ago
    Are they usable for the purpose of writing a client?
    - monadic2 6y ago
      No, they seem explicitly designed to avoid interactive use an end user.
      - znpy 6y ago
        Ah, that's what I felt. Thank you.
dicytea 6y ago
There's Ripcord[1], if you want something that is actually lightweight and webtech-free. It can also function as a client for Discord. A shame that it is closed-source though. [1] https://cancel.fm/ripcord/ https://cancel.fm/ripcord/
- sitharus 6y ago
  Ripcord is great, if you're willing to take the functionality tradeoff in exchange for not using 800MB of RAM. I'm quite willing to do that. In particular if your slack channels are heavy users of actions then you'll have problems - the buttons often don't work and the layouts are messed up. On the plus side it doesn't animate anything, which is a huge win.
  - masklinn 6y ago
    > Ripcord is great, if you're willing to take the functionality tradeoff in exchange for not using 800MB of RAM. I'm quite willing to do that. In OP's context you're also using a Qt application of macos, which is as much a match made in heaven as using x11 applications on macos (very much not).
    - Wowfunhappy 6y ago
      Qt apps aren't great on macOS but I'd put them very far ahead of x11 apps.
- dvfjsdhgfv 6y ago
  Ripcord will be great one day, but e.g. for Discord it doesn't seem to support rate-limited channels (which means most in my case). Otherwise it seems a wonderful app and I wish the missing functionality is added soon.
- amelius 6y ago
  What multiplatform UI lib does it use?
  - 6y ago
pcr910303 6y ago
If you're a Mac user that cares about user experience, I would like to (aggressively) recommend Shrugs.app[0]. It's a Cocoa/AppKit app, made with macOS native technologies that integrates most of macOS features in the Slack experience. It's the best app in the town, surpassing Ripcord (which is developed in Qt and is ugly and foreign in macOS) or using Slack in the browser (my usual option), or using the Electron client. It's written by Helge Heß[1], which you might have heard about - he has some fun projects like SwiftWebUI[2]. [0] https://shrugs.app https://shrugs.app [1] https://www.helgehess.eu https://www.helgehess.eu [2] https://github.com/SwiftWebUI/SwiftWebUI https://github.com/SwiftWebUI/SwiftWebUI
- saagarjha 6y ago
  I’ve been using it for months and it’s seriously good. It’s really a shame that one person can write something like this and yet Slack “doesn’t have the resources” to make their experience better on native platforms.
  - danpalmer 6y ago
    Let me say up front that I really dislike the Slack app, but I do think this comment is unfair on Slack. For them, the biggest lever to improved user experience is almost certainly _product features_ not performance or native integration. As much as I'd like drag and drop support or less RAM usage, Slack are mostly trying to convert people who have never used instant messaging in the workplace to using it daily (which I think is overall a win), and mostly trying to make users who are not as comfortable with software as we are use a new piece of software. As an example, when I share a Google Docs link in Slack, I get a prompt from Google Docs _in Slack_ with a one click button to "fix" sharing so that those in the channel will be able to see it. That feature is probably vastly more impactful than improving system integration. For there to be features like that, or an ecosystem of third party integrations, speed of development is likely a huge factor, and for that, being able to share the codebase across web and desktop apps is likely a no-brainer. As much as I'd love to see a more performant Slack, it's likely that it would have large negative impacts on the speed of iteration elsewhere, and so I can understand why they don't do it. Yes there are faster Electron apps, but typically they manage that by... not being Electron apps in certain areas, and sacrificing adaptability for that. Also, Slack doesn't change _that_ much right?! Well yes and no. As an end user we probably only get ~10% of the changes – 90% may be experiments that never see the light of day but still have to be built in order to find the 10% that are worth it. And even then, assuming the new features are only designed for ~50% of users, because users don't typically use every feature of a product, you'll only actually see 1 in 20 changes that the Slack team build.
Philip-J-Fry 6y ago
The downside with using native web views was that if you wanted a cross platform application, you had to use IE11 web views on Windows. So that limitation alone prevented many developers ever going down that route. The solution to that was Electron and bundling a modern web browser with the application. However... The latest versions of Windows 10 now use the newest Chromium based Edge as the native web view. So the need to use Electron is slowly going away.
- devwastaken 6y ago
  Webviews are less efficient than electron because electron integrates node and the v8 engine together, along with a number of specific patches and improvements meant for singular desktop use. You can't patch webviews nor change their behavior. Also windows webview2 is very alpha and currently not useful. No v8 access, very little configurability, and its not using any less memory. It will be years before it's ready. Chromium itself should have impliments webviews long ago.
  - saagarjha 6y ago
    > Webviews are less efficient than electron because electron integrates node and the v8 engine together, along with a number of specific patches and improvements meant for singular desktop use. This doesn’t logically follow?
- rollcat 6y ago
  - So which one is the "native" web view on Linux / BSD? Use whatever version of Webkit is supplied by the distro? This is a security nightmare, as these are outdated and full of bugs more often than not. - How does using 2 or 3 different rendering engines solve the problem for the developer? They have to now put in the extra effort and QA for each engine/platform. - So at the time Electron was founded, it might have made more sense to ship Webkit on Windows. But the developers instead chose to plug in all the extras from Chrome (?). Might have been a better choice to build directly on raw Webkit. - Even if a Hello World app was 200mb shipped and took 500mb of ram to run, it's still on the developers to get it to a state where it's an order of magnitude worse once it gets to do something useful... I'm still torn on the issue. I firmly believe going full native is the most user-friendly option, but I appreciate the increased cost and complexity of development, testing, support. But using an embedded web view of any kind feels incredibly, incredibly cheap. Especially for companies with the scale and budgets of Github or Slack.
e12e 6y ago
There's also https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack which is a plug-in for the weechat irc client.
nottorp 6y ago
Imagine how much fewer resources it would use if a native app were available...
- dmitrybrant 6y ago
  Yes, I'm often puzzled by developers who award themselves a medal for squeezing a bit more performance out of an enormous bloated web app, when a native app would be orders of magnitude lighter and faster.
sercand 6y ago
I wish Slack distribute their iPad app to mac as catalyst app. With the ability to run iOS apps on Apple Silicon macs this will be much easier but I'm afraid that they will block this and still distribute their resource heavy electron app.
- rollcat 6y ago
  The native Slack app for iOS is still hot garbage. I have an A13 device, it's the only app to regularly freeze when doing simple actions, including sharing from another app. All Catalyst apps on Mac that I've tried (including Apple's own Home) feel about as badly out-of-place as anything Electron.
catchmeifyoucan 6y ago
I believe Blazor desktop is really promising. Same premise - and let’s you use C# for the underlying native system access and reuses the native webview. https://gunnarpeipman.com/blazor-on-desktop-webwindow-experiment/ https://gunnarpeipman.com/blazor-on-desktop-webwindow-experi...
welder 6y ago
Related, there's also Franz which is another chat app aggregator/wrapper. https://meetfranz.com/ https://meetfranz.com/
- andrewkdinh 6y ago
  Ferdi is a hard fork of Franz adding features and removing some unwanted features like the paywall https://getferdi.com/ https://getferdi.com/
simooooo 6y ago
He says it uses 1.2x less memory. Can someone help me understand this
js2 6y ago
> I recently created a macOS app called Slack Lite, which beats Slack's desktop app across a few performance axises. Nit: the plural of axis is axes. (Due to its Greek etymology I think? https://en.wiktionary.org/wiki/axis https://en.wiktionary.org/wiki/axis) I'd probably use "metrics" though.
- hkgumbs 6y ago
  Fair enough, updated.
cyanic 6y ago
I created an app similar to Multi, but for Linux. If anyone is interested, take a look at DWAS[0][1]. It allows blocking requests, injecting scripts and applying custom styles among other things. [0] https://gitlab.com/codecyanic/dwas https://gitlab.com/codecyanic/dwas [1] https://gitlab.com/codecyanic/dwas-manager https://gitlab.com/codecyanic/dwas-manager

125 points by underanalyzer 6y ago

Interesting. I’m now curious how multi[1] compares to Fluid[2]. I haven’t used it in a while, but that app used to be present on all my installs. Can’t remember what happened that I stopped using it. [1] - https://github.com/kofigumbs/multi https://github.com/kofigumbs/multi [2] - https://www.fluidapp.com/ https://www.fluidapp.com/

sneak 6y ago
Multi is open source, free-as-in-freedom software. Fluid was proprietary commercial software (and the author was also a real jerk).
- rcarmo 6y ago
  Multi is open source software (GPLv3), but it is also paid software ($15).
  - sneak 6y ago
    If it's really GPLv3, then that would be called "donationware", as free-as-in-freedom software is also free-as-in-beer, as the author acknowledges in the README. The license seems ambiguous though because there's no LICENSE file in the repo and the website has copy about requiring a paid license to use the software; the only place GPLv3 is mentioned is in the README. I opened an issue requesting clarification. https://github.com/kofigumbs/multi/issues/37 https://github.com/kofigumbs/multi/issues/37
    - nottorp 6y ago
      Actually the GPL never says you cannot sell your software. It just says you have to provide source with it and you cannot prevent others from redistributing the source. Edit: no idea what the software mentioned above does, just correcting a common misconception.
    - hkgumbs 6y ago
      Author here—my understanding of the GPL matches that in the sibling comment. "GPL never says you cannot sell your software. It just says you have to provide source with it and you cannot prevent others from redistributing the source." If I'm incorrectly co-opting some open source nomenclature, I'd love if someone could let me know. As I said in the issue linked above, I do need to update the purchase website to bring that language more inline with what's on GitHub.
      - mthoms 6y ago
        I didn't read your specific wording but generally - using GPL in this fashion is perfectly fine and quite common.
    - mthoms 6y ago
      Many shops that "sell" GPL software (ie. the massive WordPress plugin and theme ecosystem) are actually selling support, convenient, secure(ish) updates, and good karma. It's perfectly legit. You can find the sources for these items elsewhere on the web but the hassle and security implications just aren't worth it.
- Wowfunhappy 6y ago
  What did the author of Fluid do?
- mthoms 6y ago
  Why do you say he's a jerk? I had some positive interactions with the author. He went out of his way to explain how to do something that wasn't officially supported (how to include my own user scripts). Nothing major. But way better support than I ever expected for a $5(!) desktop app.

deleted 6y ago

[deleted]

Fizzadar 6y ago

I've toyed around with this idea before[1], and am v.excited to see Multi.app as a packaged up/refined version, awesome stuff. [1] - https://pointlessramblings.com/posts/why-always-electron/ https://pointlessramblings.com/posts/why-always-electron/

anaisbetts 6y ago

In this screenshot, this app is using 286MB of memory and the official Slack app is using 200MB, how is this better? fwiw, this is how the original Slack Mac app worked and it sucked. We had to tell users to upgrade their OS so that their app worked, because NSWebView (and WKWebView) are tied to the OS release. If their computer was too old, telling a customer to Buy a new Mac is a pretty terrible experience.

masklinn 6y ago
> In this screenshot, this app is using 286MB of memory and the official Slack app is using 200MB, how is this better? Yes not sure where they got the 1.2x ratio in their favor, although if we're only rounding to the nearest unit the official slack uses 220MB, not 200. TBF the machine has plenty of memory available, so trading some memory for less CPU time, less GPU time, better idling and faster startup seems… a pretty good tradeoff. The one thing I'm doubtful of is whether the official slack application really does nothing but wrap the webapp with no additional functions?
- anaisbetts 6y ago
  It does not - the Slack app injects extra APIs into the DOM, and the Slack webapp recognizes it's being loaded in the Desktop app and adds additional functionality (the Downloads pane for example)
- sriku 6y ago
  > the machine has plenty of memory available On my MacBookAir with 4GB of RAM, Gmail+GCalendar+Slack+GChat+Trello+Docs is enough to put memory pressure on the system. Gmail+Calendar alone end up taking up 1.5-2GB after a while. No respect for memory.
  - devwastaken 6y ago
    No one should subscribe to building software for a purposefully underpowered and outrageously overpriced computer. You have the responsibility to have better hardware than a 2005 pc.

znpy 6y ago

"I have created a slack app" -- just repackaged a webview. I was intrigued because slack used to have APIs and and IRC proxy, and I was wondering if the author has used some kind of weird way to connect to slack and impersonate an user.

akx 6y ago
Slack still has the same realtime and RPC-style APIs.
- p_l 6y ago
  It's also actively fighting against just writing an alternative client, IIRC from my experiences trying to run weechat-slack
  - e12e 6y ago
    My experience with wee-slack is pretty good, actually. Although lately I've been running the "native" app.
- znpy 6y ago
  Are they usable for the purpose of writing a client?
  - monadic2 6y ago
    No, they seem explicitly designed to avoid interactive use an end user.
    - znpy 6y ago
      Ah, that's what I felt. Thank you.

dicytea 6y ago

There's Ripcord[1], if you want something that is actually lightweight and webtech-free. It can also function as a client for Discord. A shame that it is closed-source though. [1] https://cancel.fm/ripcord/ https://cancel.fm/ripcord/

sitharus 6y ago
Ripcord is great, if you're willing to take the functionality tradeoff in exchange for not using 800MB of RAM. I'm quite willing to do that. In particular if your slack channels are heavy users of actions then you'll have problems - the buttons often don't work and the layouts are messed up. On the plus side it doesn't animate anything, which is a huge win.
- masklinn 6y ago
  > Ripcord is great, if you're willing to take the functionality tradeoff in exchange for not using 800MB of RAM. I'm quite willing to do that. In OP's context you're also using a Qt application of macos, which is as much a match made in heaven as using x11 applications on macos (very much not).
  - Wowfunhappy 6y ago
    Qt apps aren't great on macOS but I'd put them very far ahead of x11 apps.
dvfjsdhgfv 6y ago
Ripcord will be great one day, but e.g. for Discord it doesn't seem to support rate-limited channels (which means most in my case). Otherwise it seems a wonderful app and I wish the missing functionality is added soon.
amelius 6y ago
What multiplatform UI lib does it use?
- 6y ago

pcr910303 6y ago

If you're a Mac user that cares about user experience, I would like to (aggressively) recommend Shrugs.app[0]. It's a Cocoa/AppKit app, made with macOS native technologies that integrates most of macOS features in the Slack experience. It's the best app in the town, surpassing Ripcord (which is developed in Qt and is ugly and foreign in macOS) or using Slack in the browser (my usual option), or using the Electron client. It's written by Helge Heß[1], which you might have heard about - he has some fun projects like SwiftWebUI[2]. [0] https://shrugs.app https://shrugs.app [1] https://www.helgehess.eu https://www.helgehess.eu [2] https://github.com/SwiftWebUI/SwiftWebUI https://github.com/SwiftWebUI/SwiftWebUI

saagarjha 6y ago
I’ve been using it for months and it’s seriously good. It’s really a shame that one person can write something like this and yet Slack “doesn’t have the resources” to make their experience better on native platforms.
- danpalmer 6y ago
  Let me say up front that I really dislike the Slack app, but I do think this comment is unfair on Slack. For them, the biggest lever to improved user experience is almost certainly _product features_ not performance or native integration. As much as I'd like drag and drop support or less RAM usage, Slack are mostly trying to convert people who have never used instant messaging in the workplace to using it daily (which I think is overall a win), and mostly trying to make users who are not as comfortable with software as we are use a new piece of software. As an example, when I share a Google Docs link in Slack, I get a prompt from Google Docs _in Slack_ with a one click button to "fix" sharing so that those in the channel will be able to see it. That feature is probably vastly more impactful than improving system integration. For there to be features like that, or an ecosystem of third party integrations, speed of development is likely a huge factor, and for that, being able to share the codebase across web and desktop apps is likely a no-brainer. As much as I'd love to see a more performant Slack, it's likely that it would have large negative impacts on the speed of iteration elsewhere, and so I can understand why they don't do it. Yes there are faster Electron apps, but typically they manage that by... not being Electron apps in certain areas, and sacrificing adaptability for that. Also, Slack doesn't change _that_ much right?! Well yes and no. As an end user we probably only get ~10% of the changes – 90% may be experiments that never see the light of day but still have to be built in order to find the 10% that are worth it. And even then, assuming the new features are only designed for ~50% of users, because users don't typically use every feature of a product, you'll only actually see 1 in 20 changes that the Slack team build.

Philip-J-Fry 6y ago

The downside with using native web views was that if you wanted a cross platform application, you had to use IE11 web views on Windows. So that limitation alone prevented many developers ever going down that route. The solution to that was Electron and bundling a modern web browser with the application. However... The latest versions of Windows 10 now use the newest Chromium based Edge as the native web view. So the need to use Electron is slowly going away.

devwastaken 6y ago
Webviews are less efficient than electron because electron integrates node and the v8 engine together, along with a number of specific patches and improvements meant for singular desktop use. You can't patch webviews nor change their behavior. Also windows webview2 is very alpha and currently not useful. No v8 access, very little configurability, and its not using any less memory. It will be years before it's ready. Chromium itself should have impliments webviews long ago.
- saagarjha 6y ago
  > Webviews are less efficient than electron because electron integrates node and the v8 engine together, along with a number of specific patches and improvements meant for singular desktop use. This doesn’t logically follow?
rollcat 6y ago
- So which one is the "native" web view on Linux / BSD? Use whatever version of Webkit is supplied by the distro? This is a security nightmare, as these are outdated and full of bugs more often than not. - How does using 2 or 3 different rendering engines solve the problem for the developer? They have to now put in the extra effort and QA for each engine/platform. - So at the time Electron was founded, it might have made more sense to ship Webkit on Windows. But the developers instead chose to plug in all the extras from Chrome (?). Might have been a better choice to build directly on raw Webkit. - Even if a Hello World app was 200mb shipped and took 500mb of ram to run, it's still on the developers to get it to a state where it's an order of magnitude worse once it gets to do something useful... I'm still torn on the issue. I firmly believe going full native is the most user-friendly option, but I appreciate the increased cost and complexity of development, testing, support. But using an embedded web view of any kind feels incredibly, incredibly cheap. Especially for companies with the scale and budgets of Github or Slack.

e12e 6y ago

There's also https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack which is a plug-in for the weechat irc client.

nottorp 6y ago

Imagine how much fewer resources it would use if a native app were available...

dmitrybrant 6y ago
Yes, I'm often puzzled by developers who award themselves a medal for squeezing a bit more performance out of an enormous bloated web app, when a native app would be orders of magnitude lighter and faster.

sercand 6y ago

I wish Slack distribute their iPad app to mac as catalyst app. With the ability to run iOS apps on Apple Silicon macs this will be much easier but I'm afraid that they will block this and still distribute their resource heavy electron app.

rollcat 6y ago
The native Slack app for iOS is still hot garbage. I have an A13 device, it's the only app to regularly freeze when doing simple actions, including sharing from another app. All Catalyst apps on Mac that I've tried (including Apple's own Home) feel about as badly out-of-place as anything Electron.

catchmeifyoucan 6y ago

I believe Blazor desktop is really promising. Same premise - and let’s you use C# for the underlying native system access and reuses the native webview. https://gunnarpeipman.com/blazor-on-desktop-webwindow-experiment/ https://gunnarpeipman.com/blazor-on-desktop-webwindow-experi...

welder 6y ago

Related, there's also Franz which is another chat app aggregator/wrapper. https://meetfranz.com/ https://meetfranz.com/

andrewkdinh 6y ago
Ferdi is a hard fork of Franz adding features and removing some unwanted features like the paywall https://getferdi.com/ https://getferdi.com/

simooooo 6y ago

He says it uses 1.2x less memory. Can someone help me understand this

js2 6y ago

> I recently created a macOS app called Slack Lite, which beats Slack's desktop app across a few performance axises. Nit: the plural of axis is axes. (Due to its Greek etymology I think? https://en.wiktionary.org/wiki/axis https://en.wiktionary.org/wiki/axis) I'd probably use "metrics" though.

hkgumbs 6y ago
Fair enough, updated.

cyanic 6y ago

I created an app similar to Multi, but for Linux. If anyone is interested, take a look at DWAS[0][1]. It allows blocking requests, injecting scripts and applying custom styles among other things. [0] https://gitlab.com/codecyanic/dwas https://gitlab.com/codecyanic/dwas [1] https://gitlab.com/codecyanic/dwas-manager https://gitlab.com/codecyanic/dwas-manager