3 ms·

I know nothing about Qt beyond the most basic description but I’m interested in exploring it as an alternative to Electron. I see lots of debate in the comments

I know nothing about Qt beyond the most basic description but I’m interested in exploring it as an alternative to Electron. I see lots of debate in the comments here but limited context to help me understand what is being debated. Is this book for me? What background should I, a total beginner, be aware of before I dive in?

psyclobe 8y ago
Qt is nice but takes some effort to make it do what you want it to do, just like any other c++ project. Once you get the hang of it though it can do just about anything, on any platform. At my previous job we had deployed a single code base QML ui interface across mac/windows/linux/android/ios. The mere fact you can do that and have it not look like junk everywhere is pretty cool.
sonnyblarney 8y ago
Qt is a very comprehensive system for apps developed mostly in C++. QML which is like a declarative Javascript, can be used to do quite a lot, but you'll almost certainly need to do some C++ customization in addition to the initial basic 'main app' process which requires C++ as well. Many of their customers use it for display/kiosk things (think 'in car display') so it has a lot of hyper-specific attributes which can make it seem a little difficult. The build process is ultimately C++ based (ie make, with their own layer called 'qmake') and so you're going to have to be familiar with that. In our experience it's quite slow moving compared to JS/CSS/HTML obviously, and performance gains are very situationally dependant.
- sickcodebruh 8y ago
  Thank you! That’s helpful. Since you’re comparing it to JS/CSS/HTML, does this mean you moved from that to Qt? If so, do you think it was a worthwhile move? When you say many of _their_ customers, who is they? Qt or the people responsible for QML?
  - sonnyblarney 8y ago
    I've used both on projects. HTML5 is comparable really when used in combination with Electron for example, i.e. to make an installable app. Surely you're aware of the limitations and challenges of HTML5, i.e. you can move quickly, but it's full of quirks. Electron is a little heavy. Qt I would use if performance was a concern, i.e. there were imaging algorithms, or if the hardware platform were non-standard. Yes, Qt's customers are auto-companies etc.. Qt is complex and it's a kind of a big step, and it's in C++ which is always a lot slower to move in, however it is powerful, there's really no other comparable.
    - sickcodebruh 8y ago
      Perfect, thank you. More and more, Qt sounds like the right fit for the product I work on.
      - sonnyblarney 8y ago
        Adding this now in case you read it: try not to underestimate how different and challenging the world of C++ and their extensive libraries can be. Literally they use QString, QVector i.e. their own, custom building blocks due to the crazy fragmented nature of the C++ world. The development approach is totally different and the kinds of devs you have to hire are totally different. They need to be much stronger, at the same time, focused on actually creating outputs and getting stuff done because you can easily get lost in C++/Qt. Oddly, most people who have experience in HTML5 are pretty close to the UI/design/user aspects to begin with, which is a different culture than most from the C++ world. And as I say the performance issues are totally situational. For any kind of regular business app or whatever, I'd go Electron, at least to start. Only if I was building video editing software, or a music DAW or something, then possibly QT.
        sickcodebruh 8y ago
        This is great advice and I really appreciate it. I work on a piece of fitness equipment. At the moment, our entire UI is built with TypeScript + React and it's been great: predictable, flexible, easy, and sooo fast to build and deploy. When we were still figuring out how to define our core product, this was crucial (especially the development speed) because I was working as a solo developer, responsible for quite a few environments, apps, aspects of the product, etc,... Now that things are more well-defined and we have actual customers, I'm thinking less about how many deploys I can do in a week and more about performance, stability, and the experience of using the product. As long as we're stuck in the browser, I worry about some of the compromises we'll have to make in all of those areas. We already have some C++ in the stack, so it wouldn't be _completely_ alien, though I'm sure it would still be _mostly_ alien. All that said, this is still a long way off. I can still go a long way with what we've got and I have far too many concerns that matter more to the product than this. I'm really just starting to think through options so I'm well-informed when the day comes that this does matter enough to actually start planning a change. Again, I really appreciate the advice!

psyclobe 8y ago

Qt is nice but takes some effort to make it do what you want it to do, just like any other c++ project. Once you get the hang of it though it can do just about anything, on any platform. At my previous job we had deployed a single code base QML ui interface across mac/windows/linux/android/ios. The mere fact you can do that and have it not look like junk everywhere is pretty cool.

sonnyblarney 8y ago

Qt is a very comprehensive system for apps developed mostly in C++. QML which is like a declarative Javascript, can be used to do quite a lot, but you'll almost certainly need to do some C++ customization in addition to the initial basic 'main app' process which requires C++ as well. Many of their customers use it for display/kiosk things (think 'in car display') so it has a lot of hyper-specific attributes which can make it seem a little difficult. The build process is ultimately C++ based (ie make, with their own layer called 'qmake') and so you're going to have to be familiar with that. In our experience it's quite slow moving compared to JS/CSS/HTML obviously, and performance gains are very situationally dependant.

sickcodebruh 8y ago
Thank you! That’s helpful. Since you’re comparing it to JS/CSS/HTML, does this mean you moved from that to Qt? If so, do you think it was a worthwhile move? When you say many of _their_ customers, who is they? Qt or the people responsible for QML?
- sonnyblarney 8y ago
  I've used both on projects. HTML5 is comparable really when used in combination with Electron for example, i.e. to make an installable app. Surely you're aware of the limitations and challenges of HTML5, i.e. you can move quickly, but it's full of quirks. Electron is a little heavy. Qt I would use if performance was a concern, i.e. there were imaging algorithms, or if the hardware platform were non-standard. Yes, Qt's customers are auto-companies etc.. Qt is complex and it's a kind of a big step, and it's in C++ which is always a lot slower to move in, however it is powerful, there's really no other comparable.
  - sickcodebruh 8y ago
    Perfect, thank you. More and more, Qt sounds like the right fit for the product I work on.
    - sonnyblarney 8y ago
      Adding this now in case you read it: try not to underestimate how different and challenging the world of C++ and their extensive libraries can be. Literally they use QString, QVector i.e. their own, custom building blocks due to the crazy fragmented nature of the C++ world. The development approach is totally different and the kinds of devs you have to hire are totally different. They need to be much stronger, at the same time, focused on actually creating outputs and getting stuff done because you can easily get lost in C++/Qt. Oddly, most people who have experience in HTML5 are pretty close to the UI/design/user aspects to begin with, which is a different culture than most from the C++ world. And as I say the performance issues are totally situational. For any kind of regular business app or whatever, I'd go Electron, at least to start. Only if I was building video editing software, or a music DAW or something, then possibly QT.
      - sickcodebruh 8y ago
        This is great advice and I really appreciate it. I work on a piece of fitness equipment. At the moment, our entire UI is built with TypeScript + React and it's been great: predictable, flexible, easy, and sooo fast to build and deploy. When we were still figuring out how to define our core product, this was crucial (especially the development speed) because I was working as a solo developer, responsible for quite a few environments, apps, aspects of the product, etc,... Now that things are more well-defined and we have actual customers, I'm thinking less about how many deploys I can do in a week and more about performance, stability, and the experience of using the product. As long as we're stuck in the browser, I worry about some of the compromises we'll have to make in all of those areas. We already have some C++ in the stack, so it wouldn't be _completely_ alien, though I'm sure it would still be _mostly_ alien. All that said, this is still a long way off. I can still go a long way with what we've got and I have far too many concerns that matter more to the product than this. I'm really just starting to think through options so I'm well-informed when the day comes that this does matter enough to actually start planning a change. Again, I really appreciate the advice!