Live data from Hacker News

Qt for WebAssembly Technology Preview

blog.qt.io

171–180 of 196 posts

Re: Qt for WebAssembly Technology Preview

#171
post #30

Earlier quoted context omitted.

The best native apps aren't cross platform. The worst native apps often are (at least from a mac perspective). We are simply moving to the lowest common denominator for all platforms, to the profit of business and the loss of the end-user. We can now develop software that is equally shitty for everyone much cheaper than we could before. Is that the end of the world? No, of course not. But we aren't building better to…

I don't disagree that the best native apps are amazing. But it seems so wrong to regard a desire to build cross-platform software as some kind of scheme by developers against their users. In so many cases, being able to use a program/service on many platforms is a huge part of what makes it valuable to the end-user. You can get your gmail from your computer, or your phone, or from a web cafe, and have it all work the…

> In so many cases, being able to use a program/service on many platforms is a huge part of what makes it valuable to the end-user.

Sure, some users, in some cases, may happen to use some features that are new. The pitch isn't "this is a good tool", it's "you have to use this tool to interact with others or retain data portability." Seems pretty user hostile to me.

Re: Qt for WebAssembly Technology Preview

#172
post #169

Earlier quoted context omitted.

A few notes: 1) Qt Widgets development stopped with 5.0. I had bugs filed on the embedded Linux targets and was told "sorry, these will never be fixed". 2) #1 means that Qt wants you to use QML. I need to run a Javascript engine on my target? Note in the comments of that blog post that they hope to run on an A7 (or really fast M7)...someday. 2b) ...And if they do run on a lower end platform, you still need a POSIX O/…

Never understood the obsession some people have with Qt

It's a solid toolkit that gets the job done and gets out of the way.

I've shipped a dozen products with it over the course of my career.

On embedded targets I'd never use anything else. The alternatives are way too simple or overscripted playback engines that have no flexibility with underlying code.

Re: Qt for WebAssembly Technology Preview

#174
post #150

Earlier quoted context omitted.

But the native version already does that! What can electron do that the native version cannot ? The point of electron is that it let you write code once (in JavaScript or something that transpile to js, like TypeScript or Elm) and built multi-plateform software. But if you have a native software that can be built in wasm, it also can be built on Windows + Mac + Linux. Why using electron in that case? Electron is grea…

You are right, in this case it does not make sense since you can already distribute the Qt compiled version.

And even if you want to ship native code within your Electron app, why would you use wasm instead of the native code with ffi ?

Re: Qt for WebAssembly Technology Preview

#175

Earlier quoted context omitted.

On the one hand, I find it funny that people are using bloated electron to avoid writing Qt code, and now you can write Qt code even on the web! On the other hand, if you already do have a Qt application, then you can maybe get a webapp for almost free?

See, this is what I get for procrastinating. I've been asked by a customer to port my recent Qt app to iOS. Got the equipment, was about to get the development environment set up, got XCode installed....and now this. This is pretty exciting if it all works as expected. EDIT: aaaaaaand after trying some of the demos at https://github.com/msorvig/qt-webassembly-examples using a brand new iPad (iOS11/A10 Fusion core) us…

EDIT3: got it to cross compile and load off a server. And....ugh. It's got a long way to go. It works, at least. Still too large for a mobile device however.

Re: Qt for WebAssembly Technology Preview

#176

Looking at software that uses Qt[1], I'd say I'll be impressed once they have compiled one of them, say for instance Stellarium, to Wasm. It'd be great to see how a full software, not just a toy demo, behaves in webassembly. 1. https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...

On a comment to the article:

> To give an example, the app I’m working on (https://github.com/OSSIA/score) is roughly 300kloc of Qt / C++ code and compiled in WASM almost from the first try. I’m still having freezes in some places but overall it’s working great.

Re: Qt for WebAssembly Technology Preview

#177
post #101

Earlier quoted context omitted.

It certainly feels more native than web/electron, swing, XUL, GTK and just about every other cross platform technology. It's about as good as you'll get without a native client for each platform, which will always be the best option. The only other options is the hybrid approach which uses native widgets like wxWidgets, but this means you're limited by the lowest common denominator.

I used to care about the native feel, but now as long as something has a good UI I don't really care that much. Case in point, visual studio code. The file menu is native and that's about it. The rest is html / JavaScript and it's a great interface. I don't care that the buttons don't match whatever OS theme I'm using. The web never has.

> Case in point, visual studio code.

I think most people consider visual studio to be an exception, not the norm. Whether or not visual studio's performance success represents what the typical developer should be expected to get when writing idiomatic JavaScript in Electron has probably not been fairly evaluated in the face of popular performance slugs like slack.

Re: Qt for WebAssembly Technology Preview

#178

Earlier quoted context omitted.

Hello world in Qt is 25MB as a demonstration of 'lightweight' Qt.

uh ? I have a large Qt / boost app (300kloc) that I compiled with Qt/WASM and the resulting .js is less than 20 megabytes.

That was for native compilation and those figures were from their own website.

Re: Qt for WebAssembly Technology Preview

#179
post #18

Earlier quoted context omitted.

There are some things we mourn. Nobody mourns cross platform distribution of native apps. Anyone who does hasn’t had to manage the insanity of installer apps and of papering over a million different OS versions and app versions. It’s 2018 and we still don’t have a common, wide spread, OSS framework for self-updating native apps that runs on all the major desktop operating systems. And let’s not even go into app store…

The cross platform part is called source code. If all the chunks you use to build your app are cross platform packaging wont be horrible.

Quick example: to delivery safely my app with an web app, I need to add HTTPS and that's basically it. These days I can add Letsencrypt trivially.

With modern Windows, macOS, Linux, iOS, Android, I'm going to have to run around for ages figuring out how to sign my packages. Despite what you might say, it's never easy or pleasant.

Re: Qt for WebAssembly Technology Preview

#180

Earlier quoted context omitted.

I've used it a fair bit and it gets very messy very quickly. It pretty much encourages spaghetti code. Also it is very incomplete. For example there's no way to do custom widgets that draw text (e.g. a graph). There's no good text area widget (there is one but it is extremely limited - you couldn't use it for a log output for example). Plain QtWidgets is way way better on every level except animation and styling. And…

It definitely can get messy, but there are some very easy ways to keep your project well structured. 1. Refactor out to separate components a lot . 2. Use the .ui.qml and .qml code behind pattern to separate UI from code. 3. Use singleton QtObjects to create abstract classes that contain any non-UX behavior. As for graphing, the built in components work pretty well: https://doc.qt.io/qt-5.10/qtcharts-index.html As fa…

Unlike most of Qt, QtCharts is GPL, not LGPL. You can't avoid the virality by dynamic linking.
Post reply on HN