On Tuesday, 24 April 2018 at 10:30:21 UTC, Chris wrote:
> - cross platform: no need to deploy libs (e.g. Gtk on Mac and Windows)

Well... that depends. If you can just use the browser already installed, yeah, but then you have to deal with cross-browser (which is still a thing, like I did a wysiwyg editor for work that is a redistributable server exe they run locally, but the ui is in a browser. You get better results on firefox than chrome due to a bunch of little things.)

Same with deprecation. Web stuff breaks somewhat frequently, and new features requiring bleeding edge won't always be there.

On Tuesday, 24 April 2018 at 11:15:43 UTC, Uknown wrote:
> On Tuesday, 24 April 2018 at 10:30:21 UTC, Chris wrote:
>> On Monday, 23 April 2018 at 14:38:44 UTC, TheGag96 wrote:
>>
>>>
>>> That's definitely what I'm trying to avoid... I feel those kinds of interfaces are 99% of the time mega bloated for what they are. Discord is the only one that seemed big enough for the britches of an entire browser instance. Absolutely not a fan of Electron and the like.
>>>
>>> I have never tried dwt! I should give that a shot. And I was trying gtkd once, and I should probably try again. Back then, I had to compile with --build=plain due to some weird linker issues.
>>
>> The advantage of using web technologies for UI:
>>
>> - high re-usability: use the same or similar layout+functionality for desktop, Android/iPhone apps and web based UIs.
>> - freedom as to layout and theming with CSS (highly customizable for users too)
>> - cross platform: no need to deploy libs (e.g. Gtk on Mac and Windows)
>> - maintenance: older JS code / CSS will still be ok in _most_ cases, whereas Gtk and other frameworks introduce depractaions and breaking changes so that you have to a) rewrite parts of your code and b) maintain older (outdated) versions of the program until you can be sure that the older libs are no longer used / distributed
>> - distribution: While users don't care about your maintenance costs, they do care about having an app available on their smart phones/desktops/online. So multiply various versions of say a Gtk app by platform (_at least_ you have to maintain 2Gtk*3Platform = 6 apps). Users hate being told that it only works on Linux desktop. Thus, web technologies can be a real gain.
>> - progress: web technologies have made huge progress JS and CSS are much better now. Layout and js engines are much smarter as well. So you benefit from this and get it more or less for free on every platform.
>
> These are nice points, but the fact remains that running a web browser torun something as simple as a text editor is extremely inefficient. I personally don't use atom, VS-code or anything else, because they are all very slow. I tried VC-code once. It was nice in terms of UI, but was borderline unusable because it would take almost half a second to register keys, and the laptop fans would always spin up.
> Using it on a laptop means:
> - You will be using far more memory. This means its harder to open multiple tabs or programs (profiler + editor or docs in Firefox)
> - Mobile device battery life takes a hit. This is non negligible. Battery life on my old mac using just vim (with a few plugins) is 6 hrs. With vs-code it was 2-3 hrs
> - Way more on disk memory. With disk space becoming cheap, this is less of a concern for most modern devices, but why be wasteful? Besides, in developing countries, its still pretty hard to get lots of storage, which means users are forced to decide which apps are more important.
> - If the mobile device's CPU is under less load, in general it will remain cooler and thus less likely to throttle. Putting pressure on the thermal cap by running CPU intensive programs like a browser, when it can be done more efficiently is bad
>
> We should be getting more efficient with time, especially considering Moore's law is on its last legs, not less efficient

I forgot to mention consistency. This is the biggest reason I don't use non native apps. I'm not talking about your app being consistent across operating systems. I'm referring to being consistent with programs on the current system. E.g a native macOS app has a certain way it looks and behaves. I can expect cmd+w to close a window, cmd+q to quit and the the "traffic lights" to be on the top left. Non native apps mess things up, making them harder to use. Keyboard shortcuts _generally_ work, but when they don't they are a pain. Even messing with buttons, making them smaller, or placing them weirdly, or using custom tabs and menus makes it harder to work with a program.
For e.g. look at the divide between "modern" and "native" apps on Windows. Even on linux, back in the day, GTK apps looked out of place on QT systems and vice versa.

On Tuesday, 24 April 2018 at 12:44:59 UTC, Uknown wrote:

>
> I forgot to mention consistency. This is the biggest reason I don't use non native apps. I'm not talking about your app being consistent across operating systems. I'm referring to being consistent with programs on the current system. E.g a native macOS app has a certain way it looks and behaves. I can expect cmd+w to close a window, cmd+q to quit and the the "traffic lights" to be on the top left. Non native apps mess things up, making them harder to use. Keyboard shortcuts _generally_ work, but when they don't they are a pain. Even messing with buttons, making them smaller, or placing them weirdly, or using custom tabs and menus makes it harder to work with a program.
> For e.g. look at the divide between "modern" and "native" apps on Windows. Even on linux, back in the day, GTK apps looked out of place on QT systems and vice versa.

Well, this is only an issue if you want to provide an OS specific LAF for users who expect it and want it this way (Mac users, Windows users). So if you design an image or text editor for desktop, you would probably want to go native. However, loads of apps these days are meant for tablets, phones and the web. If, for example, I were to develop an app for language learning, I'd definitely not go native, but base the UI on HTML+CSS+JS. In that way, you can re-use it for smart phones and the login section of the user account. It'd be madness not to. A lot of apps have their own unique look these days (just as websites do), and users know (and even expect) that. If for some reason you have to interact with the OS's services on say an iPhone, you can always write a thin native wrapper in Objective-C or Swift. But I wouldn't base the logic on and around the native framework.

As for the rest, it's all about trade-offs and use cases. I don't use web-based programming editors nor would I write one, for the reasons you mentioned and because it has a well defined use case, i.e. hours of programming on your lap or desktop. For a language learning app, a weather app, a converter etc., going native is in most cases a bit OTT.

On Tuesday, 24 April 2018 at 12:29:04 UTC, Adam D. Ruppe wrote:
> On Tuesday, 24 April 2018 at 10:30:21 UTC, Chris wrote:
>> - cross platform: no need to deploy libs (e.g. Gtk on Mac and Windows)
>
> Well... that depends. If you can just use the browser already installed, yeah, but then you have to deal with cross-browser (which is still a thing, like I did a wysiwyg editor for work that is a redistributable server exe they run locally, but the ui is in a browser. You get better results on firefox than chrome due to a bunch of little things.)

True, true. I've had my share of that. But often it can be fixed easily or the next version of the browser can already cope with it.

> Same with deprecation. Web stuff breaks somewhat frequently, and new features requiring bleeding edge won't always be there.

In my experience, if you stick to plain JS+CSS+HTML things don't break that often. On the network side things can change. Then again, if you stick to robust bog standard protocols and the like, you're not really in danger of having to re-write everything.

On Monday, 23 April 2018 at 06:12:33 UTC, TheGag96 wrote:
> Heya guys. For my projects that use a GUI library, I've tried both tkd and DlangUI. Both I feel have their drawbacks, and I'd like to know if any of you are using anything you find better. In my case, my ideal choice would be:
>
> - Nice bindings/API, friendly to idiomatic D
> - Cross platform
> - Can compile to a standalone binary (no shared libraries or extra files)
> - Reasonably efficient
> - Support for a good amount of well-working widgets
>
> Although quite a cool library, my biggest issue with DlangUI was that it was a little mind-bending at times to keep track of multiple widgets that view/modify the same data without screwing things up. I saw QtE5 recently and have been thinking about trying it out.
>
> What do you all recommend? Thanks!

I'd recommend dqml[1] or full Qt using Calypso[2] instead of QtE5. I'm currently using dqml in a project and it is working out great.

[1]: https://github.com/filcuc/dqml
[2]: https://github.com/Syniurge/Calypso

On Tuesday, 24 April 2018 at 14:30:07 UTC, Thomas Brix Larsen wrote:
> I'd recommend dqml[1] or full Qt using Calypso[2] instead of QtE5. I'm currently using dqml in a project and it is working out great.

Awesome, thank you! I'll keep that in mind!

On Tuesday, 24 April 2018 at 13:08:24 UTC, Chris wrote:
> In my experience, if you stick to plain JS+CSS+HTML things don't break that often.

...If you can get things written in the first place. Over the summer I interned at a place where they taught me how to write a web app, and I very quickly learned that unless you're using TypeScript or something, it's nearly impossible to write clean, well-structured JavaScript code, just by the nature of language itself. And even then it's still kinda gross.

My whole point with what I said earlier was that there's no reason to be greedy about resources for your app unless it's specifically needed. If you're trying to deploy on every imaginable platform, I could absolutely see the benefit of being able to develop one app for all of them at once through the web - but that's even assuming there's no major quirks/concerns between all browsers.

Uknown's point about Moore's Law, I think, is the one we should be paying attention to. A while back, I saw a talk by Jonathan Blow called "Making Game Programming Less Terrible"[1], and lately it's been on my mind a ton. I've begun to think that by going straight to web/Node stuff is just contributing to the degeneration of software/computing. Things are so much slower than they should be nowadays because programmers either A) didn't know any better how to write software that's as snappy as it should be, or B) wanted to make things easier/cheaper for themselves.

A bit off-topic I suppose lol, but I hope this kind of outlines why I follow D so much in the first place and why I want something lightweight but workable if I can find it.

[1] https://www.youtube.com/watch?v=gWv_vUgbmug

On Monday, 23 April 2018 at 06:12:33 UTC, TheGag96 wrote:
> Heya guys. For my projects that use a GUI library, I've tried both tkd and DlangUI. Both I feel have their drawbacks, and I'd like to know if any of you are using anything you find better. In my case, my ideal choice would be:
>
> - Nice bindings/API, friendly to idiomatic D
> - Cross platform
> - Can compile to a standalone binary (no shared libraries or extra files)
> - Reasonably efficient
> - Support for a good amount of well-working widgets

I can't say I've seen a library which meets your ideal but I still find DWT my favorite; not that I'm well verse in GUI libraries.

I think this is a fair statement about SWT (what DWT is based on). SWT provides the basics for graphical interfaces it doesn't try to do things for you. The JFace library is intended to provide a little more help, but I don't think it has made it over to D yet.

On Tue, Apr 24, 2018 at 06:13:46PM +0000, TheGag96 via Digitalmars-d wrote: [...]
> Uknown's point about Moore's Law, I think, is the one we should be paying attention to. A while back, I saw a talk by Jonathan Blow called "Making Game Programming Less Terrible"[1], and lately it's been on my mind a ton.  I've begun to think that by going straight to web/Node stuff is just contributing to the degeneration of software/computing. Things are so much slower than they should be nowadays because programmers either A) didn't know any better how to write software that's as snappy as it should be, or B) wanted to make things easier/cheaper for themselves.

This reminds me of Nick Sabalausky's rant once that back in the 80's we used to run programs on 64KB RAM and 8kHz CPUs, and lived with the slow performance, and nowadays we have GB's of RAM and multicore GHz CPUs, and we are finally able to write web apps that do basically the same things with about the same slow performance as in the 80's (but with many orders of magnitude greater resource consumption).  Software has come a long ways indeed.</sarcasm> :-D


T

-- 
MASM = Mana Ada Sistem, Man!

On Tuesday, 24 April 2018 at 18:43:54 UTC, H. S. Teoh wrote:

> This reminds me of Nick Sabalausky's rant once that back in the 80's we used to run programs on 64KB RAM and 8kHz CPUs, and lived with the slow performance, and nowadays we have GB's of RAM and multicore GHz CPUs, and we are finally able to write web apps that do basically the same things with about the same slow performance as in the 80's (but with many orders of magnitude greater resource consumption).  Software has come a long ways indeed.</sarcasm> :-D
>
>
> T

https://www.artima.com/cppsource/how_to_go_slow.html

On 04/24/2018 08:44 AM, Uknown wrote:
> Even on linux, back in the day, GTK apps looked out of place on QT systems and vice versa.

That's still true even now, albeit maybe not to the same extent (that is, until you try to save/open a file...).

We REALLY need a lib that provides the GTK API/ABI and converts to Qt. (Might be a nightmare to maintain though, the way GTK loves changing/removing things on a whim...)