5 ms·

What I don't get about the rant is why it matters what the "modern" way is. It's not like any of the old tools have disappeared right? If you don't like Electr

What I don't get about the rant is why it matters what the "modern" way is. It's not like any of the old tools have disappeared right? If you don't like Electron/NW, nobody's stopping you from building native apps with Qt, GTK, or you can just draw your own UI raw! If you don't like frameworks with their own templating systems, maybe don't use them? I don't like them either! and yet rather than complain I just don't use them... Abstractions by their nature make some use cases easier and others harder. They trade off efficiency for familiarity. If an abstraction is "popular" it just means many people appreciate its benefits over its limitations for their particular use case. Being opinionated is the whole point. If you don't like it or if it doesn't fit, don't use it. Gatekeeping in general is bad. Dismissing a modern framework because it's "too high level" is rather silly. On the other hand, dismissing someone only because they're not using the "modern" stack (whatever that is) is equally silly.

int_19h 5y ago
As a developer, that is correct. As the end user of those "native" web-repackaged apps, the experience is just subpar. Give me back my native widgets and consistent UX.
- crubier 5y ago
  You can have them back! Just use old versions of your apps, or old apps. But you won’t because deep down you know that those “web repackaged” apps are actually better than old GTK apps. More features, nicer UI, etc.
  - emodendroket 5y ago
    It depends, probably the "old version" of Spotify or whatever doesn't work anymore.
  - int_19h 5y ago
    Not really. The problem with old versions of apps is that they don't support anything newer (standards, protocols, file formats etc). And then there's security vulnerabilities. But that aside, when picking between different pieces of software, one of which is Electron, and the other one is Qt, I'll always pick Qt unless the Electron one is drastically better feature-wise (haven't seen that in practice yet).
vbezhenar 5y ago
Responsibility stops me from building applications and services using obscure tools or writing my own tools. Because it'll be rewritten by later developers using commonly-used tools. There's certain expectations. You don't write your own logger library in Java, you're using logback or log4j (despite them being monstrosities). You don't write your own framework or use some obscure framework like Helidon. You use Spring Boot because everyone uses that. If you'll write your GUI application using Gtk, it's likely to be rewritten with Electron just after you leave the company and next developers will not be able to speak C because they just finished some JS bootcamp and just went into industry. I can use assembly language for my own projects if I want. Nobody cares. But for code that I was hired to write, I'll use most appropriate approach and usually that's a most popular approach. Even if I'd love to just write some SQL, I'll bring Hibernate and meddle with its configurations because that's what everyone uses and knows (and hates) in Java. That'll produce maintainable software that won't get rewritten tomorrow because you used arcane tech nobody understands. Using non-conventional approaches might be good for job security, though, I guess.
- jabbany 5y ago
  > Because it'll be rewritten by later developers using commonly-used tools. Everything will eventually be rewritten so this isn't much of an argument... What's "common" today won't be that way forever, likely not even for a couple of years (which is the whole point). There's no reason to use a particular tool because it's common. A proper developer uses the tool that is right. If that happens to be old, so be it. An engineer should be able to decide what to use based on merits of tools not just picking up the new shiny.

int_19h 5y ago

As a developer, that is correct. As the end user of those "native" web-repackaged apps, the experience is just subpar. Give me back my native widgets and consistent UX.

crubier 5y ago
You can have them back! Just use old versions of your apps, or old apps. But you won’t because deep down you know that those “web repackaged” apps are actually better than old GTK apps. More features, nicer UI, etc.
- emodendroket 5y ago
  It depends, probably the "old version" of Spotify or whatever doesn't work anymore.
- int_19h 5y ago
  Not really. The problem with old versions of apps is that they don't support anything newer (standards, protocols, file formats etc). And then there's security vulnerabilities. But that aside, when picking between different pieces of software, one of which is Electron, and the other one is Qt, I'll always pick Qt unless the Electron one is drastically better feature-wise (haven't seen that in practice yet).

vbezhenar 5y ago

Responsibility stops me from building applications and services using obscure tools or writing my own tools. Because it'll be rewritten by later developers using commonly-used tools. There's certain expectations. You don't write your own logger library in Java, you're using logback or log4j (despite them being monstrosities). You don't write your own framework or use some obscure framework like Helidon. You use Spring Boot because everyone uses that. If you'll write your GUI application using Gtk, it's likely to be rewritten with Electron just after you leave the company and next developers will not be able to speak C because they just finished some JS bootcamp and just went into industry. I can use assembly language for my own projects if I want. Nobody cares. But for code that I was hired to write, I'll use most appropriate approach and usually that's a most popular approach. Even if I'd love to just write some SQL, I'll bring Hibernate and meddle with its configurations because that's what everyone uses and knows (and hates) in Java. That'll produce maintainable software that won't get rewritten tomorrow because you used arcane tech nobody understands. Using non-conventional approaches might be good for job security, though, I guess.

jabbany 5y ago
> Because it'll be rewritten by later developers using commonly-used tools. Everything will eventually be rewritten so this isn't much of an argument... What's "common" today won't be that way forever, likely not even for a couple of years (which is the whole point). There's no reason to use a particular tool because it's common. A proper developer uses the tool that is right. If that happens to be old, so be it. An engineer should be able to decide what to use based on merits of tools not just picking up the new shiny.