[deleted]

Comments

• moseschrute@piefed.world ⁨2⁩ ⁨days⁩ ago

  The best thing to do is ignore anything anyone on Lemmy tell you, and use the tools the let you deliver the highest quality software. Those tools may be different for you than they are to me. People here have too many strong opinions, and you will never find a stack that makes them happy.

  source

  • nikolasdimi@lemmy.world ⁨2⁩ ⁨days⁩ ago

    thanks! well, the feedback and the questions did not come from lemmy per se but in general. And yes, I agree with you. People do have strong opinions and this is more a question for me - as I often feel that perhaps there is some “better” way to explain or show the impact of the decision. (and explain the trade off). But I think that ultimately you are saying one simple (but very important) thing: that you can not please everyone :)

    source

    • moseschrute@piefed.world ⁨2⁩ ⁨days⁩ ago

      Yeah. And if you like talking about the stack, that’s cool, but you should be able to talk about the project you’re passionate about without people criticizing some stack choice you made. If it’s a good app, then the stack is good enough imo.

      source
• litchralee@sh.itjust.works ⁨2⁩ ⁨days⁩ ago

  without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others

  From the perspective of a user, why would they care about development speed? A user, by sheer definition of wanting to use the software, can only use software that is already developed. If it’s not actually developed yet… they can’t use it. So either they see the software at the end of the development cycle, or they never see it at all. Development speed simply isn’t relevant to a user at that point. (exception: video games, but I’m not aware of any desktop game developed using a web framework)

  As for platform consistency, again, why would the user care? Unless each user is actually running the same software on multiple platforms (ie a Windows user at work, Arch at home, and BSD at their side-gig), this is a hard sell to get users to care. A single-platform user might never see what the same software looks like on any other platform. Even mobile apps necessarily differ in ways that matter, so consistency is already gone there.

  What I’m getting at is that the concerns of developers will not always be equally concerning to users. For users to care would be to concern themselves with things outside of their control; why would they do that?

  source

  • nikolasdimi@lemmy.world ⁨2⁩ ⁨days⁩ ago

    hm…great points, thanks for taking the time to answer.

    From the perspective of a user, why would they care about development speed?

    Yes, the tool is already developed but it will continue evolving right? I mean, we almost make 2-3 releases every month since we shipped the first version and then open sourced. So the speed still counts. Plus, the users who create the tickets and expect them to be tackled are actually developers themselves. So yeah, the ability to deliver (at a good pace) to these folks matters a lot.

    However - YES, if at some point the tool is at a state that the speed becomes less meaningful or useful, then indeed a change might be needed?

    As for platform consistency, again, why would the user care?

    Yes, since our users are Dev (and QA) folks, we thought that yeah, maybe someone could have different systems for work vs home vs side project (as you said). But another aspect that we thought is teams and collaboration. We didn’t want to have a scenario in which a team can not use it before some of the devs are using macs, others linux vs the QA folks using windows etc.

    What I’m getting at is that the concerns of developers will not always be equally concerning to users.

    Thats the heart of the discussion:) I guess because our users are also developers. :)

    source
• CallMeAl@piefed.zip ⁨2⁩ ⁨days⁩ ago

  How do you explain this tradeoff to users in a way that feels honest and understandable, without sounding like you are making excuses for Electron?

  To people who dislike Electron due to its size, I don’t think you can. To someone with that mindset, saying “we are seeing something like 50–60 MB for the actual usage” itself sounds disingenuous.

  However most people don’t seem to care that much about the size of Electron. Most people I know expect a modern system to have enough ram for it to not matter.

  source

  • nikolasdimi@lemmy.world ⁨2⁩ ⁨days⁩ ago

    Yeah, honestly, sometimes I feel frustrated trying to explain it, because I know some people will never be satisfied. I just want to be transparent about the tradeoffs and let people SEE the actual usage (even if it will indeed not convince everyone).

    source

    • femtek@lemmy.blahaj.zone ⁨2⁩ ⁨days⁩ ago

      It’s the usage they see used, not what the app itself is using. It’s like someone borrowed your car and paid for for just the gas and not the wear and tear. It matters to the PC user that they have less to go around and would rather use something without the overhead. I’m not against overhead when it makes sense, I use docker at home and kubernetes at work.

      source

      • -> View More Comments
• Scipitie@lemmy.dbzer0.com ⁨1⁩ ⁨day⁩ ago

  Hey,

  Person here who despises electron apps in part because of the memory footprint and in part because I don’t like neither chromium nor node.js - personal preference mainly.

  From your description I have the feeling that it’s unclear to your user base if electron is set or up to debate. There is only a thin line between “explaining” and “defending”.

  In terms of communication: “We’re using electron as foundation because it allows us to focus on development. We’ve considered alternatives like Tauri and XYZ and opted in favor of electron.”

  If there are situations that might make you rethink state those as well (“if someone provides a proof of concept via XYZ that an alternative is faster by y% while enabling us to still use (your core libraries and languages) we might consider a refactor.”

  If you’d engage with me after an electron rant on your codebase you’d just raise my hope that I might change your mind! Don’t give people hope, don’t feed the trolls and do your thing!

  Just please be honest with yourself: your app doesn’t use “50 to 60 MB”, it uses 500MBish on idle because of your choice. And that’s okay as long as you as developer say that it is.

  source
• slazer2au@lemmy.world ⁨1⁩ ⁨day⁩ ago

  You don’t have to. If they have an issue with it they can fork it build the tool how they like it.

  source

  • nikolasdimi@lemmy.world ⁨1⁩ ⁨day⁩ ago

    cynically true :)

    source
• monkeyman512@lemmy.world ⁨2⁩ ⁨days⁩ ago

  I would make an FAQ. I think for getting tone it is important to know what things are hard facts, what things are more subjective preferences, and what’s things are “we had to make a choice between options with no clear ‘best’ option”.

  source

  • nikolasdimi@lemmy.world ⁨1⁩ ⁨day⁩ ago

    yes thats a good idea, we actually made an FAQ that sits with our docs…I want to monitor to see if this helps people navigate some of these questions:)

    source