171–180 of 184 posts
Earlier quoted context omitted.
Linux doesn't dictate a native API for GUI. It de facto dictates the display server protocol though (currently being X11 and Wayland as the next generation). So any API would be built with that in mind. That said, most widely used APIs are Qt and GTK+.
That's what I thought. So I'm having trouble understanding how I would apply bitwize's iron rule.
Earlier quoted context omitted.
This is a great point, but also orthogonal to the tech/platform choice. One can still develop a front-end using web tech which connects to a localhost server (see for example Google Refine -- which runs a localhost web server). It may make packaging and distribution it tad more annoying, but there are tools that can do this, and then you get the benefit of cross-platform adoption -- as well as the option to make it a…
> a front-end using web tech which connects to a localhost server But what advantage does that offer over a native application? You’d then need a ‘native’ web server and would still rely on the local browser in a way that opens you up to more incompatibilities than just using the native interface framework?
Earlier quoted context omitted.
I sure hope compilers haven't been twiddling their thumbs for the past decade.
You mean developers, right? Compiler auto-vectorization hasn't really advanced that much. You still need to manually use SIMD intrinsics (or inline asm) to get any kind of worthwhile performance increase.
Earlier quoted context omitted.
> a front-end using web tech which connects to a localhost server But what advantage does that offer over a native application? You’d then need a ‘native’ web server and would still rely on the local browser in a way that opens you up to more incompatibilities than just using the native interface framework?
Ease of development for folks who aren't platform-native. Doesn't appeal to me, but then, I've parted ways with web applications.
An interesting usecase would be a LAN-local server, which would (with server-side data processing) avoid the slow uploading of data over the internet and could still utilise native computation speeds on the server.
Sure, your web app might feel instantaneous when your server is sitting across the LAN, but many users have crappy Internet connections, or are downloading a Torrent, or are living in New Zealand... Yup. New Zealand's internet speeds are just abysmal. On behalf of kiwis everywhere, can I ask that you all stop writing your own wrappers for web based videos? Instead, upload your videos to YouTube and embed that on your…
Sure, your web app might feel instantaneous when your server is sitting across the LAN, but many users have crappy Internet connections, or are downloading a Torrent, or are living in New Zealand... Yup. New Zealand's internet speeds are just abysmal. On behalf of kiwis everywhere, can I ask that you all stop writing your own wrappers for web based videos? Instead, upload your videos to YouTube and embed that on your…
Earlier quoted context omitted.
Not true. Lot's of applications use generic abstractions and look good at the same time. Firefox, LibreOffice, VirtualBox and etc. If you don't know how to make good GUI using generic toolkits it doesn't mean it's not possible. Anyway, if you buy application for its "looks" - there is something seriously wrong already. It should look good, no doubt, but it should be functional first. >as is the case for most producti…
Nobody on Mac runs Firefox except to test with because it's so obviously non-native. And I wouldn't describe LibreOffice as "not looking (and running) like shit". Again, nobody on Mac actually uses it, and Windows has the real Office.
All good thoughts, and similar to why I develop native apps for iOS vs web apps. I think John Gruber summarized it nicely when he said: "Facebook, bless them, has it right. What's great about the web is ubiquitous network availability, not running within a browser tab. Websites are just services, and what you see in a browser tab is merely one possible interface to that service. The best possible interface to that se…
Warning, rant: Web does not mean ubiquitous network availability. It's a turn of phrase that only seems to originate from Silicon Valley and Redmond. When I get on the London Underground my network is gone. When I drive from Cape Town to Hout Bay my network disappears. When I go into my favourite coffee shop in Berlin my network disappears. If an app (Evernote, for example) relies on a non- store-and-forward network…
At least native apps can fall-back seamlessly.
With each web project I take part on, I feel more and more in sync with what the author states. The proper way is to have desktop applications that take proper advantage of the hardware and operating system integration and use the network for communication. Leave the browser for the documents. No need for browser compatibility headaches or JavaScript/CSS/HTML hacks. Just use your favourite programming language and ta…
I'm surprised by this sentiment. I thought web apps had 'won' on the desktop? Is the pendulum starting to swing the other way?
There are many other areas when desktop is still the way to go.
Earlier quoted context omitted.
Yes, SVG is the perfect tool for this, and I bet there is no visualization library remotely as awesome as D3 for the desktop: https://github.com/mbostock/d3/wiki/Gallery
You can use D3 on the desktop as far as I know. It's a JS library.