> There’s no app store for your browser-based client with anything like the scale and size and polish of those for mobile apps.
I think google (or other search engines) are the open webs equivalent of an "app store"
Software in 2014
191–200 of 265 posts
Re: Software in 2014
#192Earlier quoted context omitted.
I want to see some good Xamarin & PhoneGap apps, honestly the ones I've seen don't come close to natively built ones. Also if you are developing a game, you'd better stay far away from UIKit and do everything in OpenGL if you hope to get the same type of performance on Android using a translation tool. The article is pretty much spot on. For most people who want to write great software, the client side is currently a…
Xamarin and Phonegap are completely different beasts. You are thinking about Phonegap now. Xamarin ones are natively built ones; you use Apple classes to build everything but just in C# instead of Objective-C. So you have to rebuild the frontend twice indeed for Android and iOS but it does look and function 'native' as if you did it with Xcode. Phonegap => not so much; most just works like shit, but you only have to…
Sorry, I got Xamarin confused with Titanium, which was a pretty bad experience for me for the week that I tried it. If I tried to do anything fancy, it was completely useless.
Also any time you are using 3rd party tools like Titanium / Xamarin to develop these apps it comes with gotchas / limitations that may not even be worth it in the end (it seems like Xamarin has less gotchas). The main issue is that you still have to do UI twice in the end (iOS & Android), and one more time for web.
Re: Software in 2014
#193> There’s no app store for your browser-based client with anything like the scale and size and polish of those for mobile apps. I think google (or other search engines) are the open webs equivalent of an "app store"
While search engines aid in discovery, they are not an easy way for customers to "buy" apps by just entering a password associated with their phone account.
Re: Software in 2014
#194Earlier quoted context omitted.
> What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite. They inevitably end up with an office suite that sucks, but that's not the browser's fault. Yet, because it runs in the browser and is available everywhere, that's why I use Google's Docs. And GMail's web interface is better than any email client I tried until now. > Browsers are fine as lon…
> Yet, because it runs in the browser and is available everywhere, that's why I use Google's Docs. And GMail's web interface is better than any email client I tried until now. IMHO, this is a case of solving a problem at a wrong level. I also find that matches provide neither a sufficiently long-lasting, nor a sufficiently intense fire to cook. Longer and thicker matches would obviously be a solution to this, and it…
> The "mobile" part ceases being true when their battery is only sufficient to allow them to be mobile for the duration of an entry-level delayed road trip. I'd much rather have a dumphone and a tablet than a smartphone.
You sound like someone who lives in a somewhat-rural area. Smartphones are somewhat like smart cars, in that they're basically built for urbanites--people who mostly either end up at home each night (where there's a charger), or travel by flying (and take their charger with them.)
Re: Software in 2014
#195Earlier quoted context omitted.
> What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite. They inevitably end up with an office suite that sucks, but that's not the browser's fault. Yet, because it runs in the browser and is available everywhere, that's why I use Google's Docs. And GMail's web interface is better than any email client I tried until now. > Browsers are fine as lon…
> Yet, because it runs in the browser and is available everywhere, that's why I use Google's Docs. And GMail's web interface is better than any email client I tried until now. IMHO, this is a case of solving a problem at a wrong level. I also find that matches provide neither a sufficiently long-lasting, nor a sufficiently intense fire to cook. Longer and thicker matches would obviously be a solution to this, and it…
> Yes; and I do think smartphones are a terrible piece of engineering.
I can't read that and not scoff. I don't know how you can seriously argue that smartphones aren't a great piece of engineering. The power, accessibility, and flexibility offered in a device that easily fits in your pocket is pretty amazing in my book. Yes, battery technology isn't the best, but to say somehow that what has happened in the smartphone industry in the past 5 years isn't an amazing piece of engineering, I find that pretty laughable. I guess we should all go back to our brick phones and blackberries for the business types then?
Re: Software in 2014
#196Earlier quoted context omitted.
> I do think it's a shame that the providers of these platforms lock them down to APIs in their chosen languages/frameworks I never understand this point. All APIs are exposed via some protocol. Whether it's javascript, C, Objective-C or HTTP. High-level APIs like HTML5 or Cocoa need to be exposed in a high-level language. The restrictions imposed by js or obj-c are an inescapable part of what make these environments…
It's an interesting debate, and in particular UI bindings often need higher level access. I'm not convinced that the trade off of being locked into whatever Apple decides is the one true language and API is worth the gains though. I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser. T…
> I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser
On the server, that's definitely true. On the client, it's basically the same situation w/r/t languages. But this is a client/server distinction, not a native/web distinction.
Clients are just inherently coupled to the APIs that they use. Servers aren't so much. The coupling in languages reflects this.
> If all the platform vendors had standardised on an API in say c as web browsers or unix have, we'd have a much more convincing case for mobile taking over the world and competing with the web
That's an interesting point (although we'll then be totally locked to a particular platform/language on the client) and I think the web will eventually win. But not for a while.
At some point, the rate of progress on native will decrease and the advantages of standardization (cost, mostly) will overcome the disadvantages (lack of progress). It'll be interesting to see how the manafacturers adapt to that. I suspect that Google will do better than Apple.
Re: Software in 2014
#197The JS sort example was interesting... solution.
[5, 10, 1].sort(function(a,b){return a - b});Re: Software in 2014
#198I think this paints a rather meagre picture of software development in 2014: > More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP. A lot of things that shouldn't talk HTTP are expected to just because there's an army of programmers who don't know better. Also, it's actually hard to make things talk HTTP, partly due to HTTP itself. However, much of this complexity is hidden…
> In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved?
In the same weird world that an old NeXT Cube is easier to write applications for and has more responsive apps than the modern web client HTML5 apps.
Re: Software in 2014
#199I think this paints a rather meagre picture of software development in 2014: > More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP. A lot of things that shouldn't talk HTTP are expected to just because there's an army of programmers who don't know better. Also, it's actually hard to make things talk HTTP, partly due to HTTP itself. However, much of this complexity is hidden…
> What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite. They inevitably end up with an office suite that sucks, but that's not the browser's fault. Yet, because it runs in the browser and is available everywhere, that's why I use Google's Docs. And GMail's web interface is better than any email client I tried until now. > Browsers are fine as lon…
> Phones are also fine as long as you use them for what they are meant to be used: initiating phone calls.
I don't know that is the case... Between the crappy bluetooth voice commands in my car, and having to unlock and click through 3+ items to get to a dialpad, I don't think "smart phones" make very smart phones...
Re: Software in 2014
#200> What’s worse is that you can’t even count on people accepting the mobile-app updates you send them. There's a good reason for this: companies routinely push updates that either (1) change the user interface, usually for the worse (Google Maps), (2) remove functionality, or (3) introduce bugs/reduce stability (e.g. Viber). No wonder that customer's delay updating as much as possible. Almost every time I update my ap…
(4) Many apps request new, intrusive, permissions for every update. I don't want to review the permission list all the time so any time an app requests something new i default to not update it. If the app worked good before without the permission why would it need more now?