While a mobile app can certainly deliver a rich user experience, the availability of a standard, universally supported platform (read: a browser) is a more sustainable approach to application deployment.
We've been down this road before. In the pre-browser era, desktop application were king, but at a high cost to IT departments as well as end-users. The same game is being played out on mobile platforms now.
From a business perspective, do you really want to support multiple development efforts for each and every mobile platform? Will it be worth it in the long run?
The advantages of the mobile app platform must be balanced with the cost and maintenance overhead as well. Give me a great browser platform, and I'll gladly take its shortcomings over the long-term sustainment costs of a dedicated mobile app.
Only 37Signals is a B2B company that has a lot of customers that are developers. They have an API. Their source of income is their subscription and not apps for native platforms.
In other words, many of their customers who want a native app can scratch their own itch pretty easily, and 37Signals can cut down their own development efforts and focus on making their platform better.
The reason Evernote has apps for every platform is simple: that's the only thing they have going for them. Their interface isn't the best, and there are tons of other ways to save notes. They just happen to have really good cross-device integration. Other note-taking tools have users for different reasons.
I agree with 37Signals. App Stores are an obsolete concept that are only making a comeback because we have a new wave of devices without a solid set of mature cross-platform development tools.
EDIT: In other words, 37Signals wants to differentiate themselves from other applications in more unique ways than just "works natively on every device."
Honestly, as a customer I'm getting tired of having to install apps for everything I use, I'm getting tired of something not having the app on my Droid because it's only for iPhone and so on...
I think the HTML5/JS approach still has a way to go before the user experience will really catch up to native apps, and for some apps it will never happen. But the same could be said for desktop apps vs webapps and we all know how that turned out...
"all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."
Take it from a 38 year old with a mortgage and two kids: take time off from your current job/venture and see the world.
I travelled a bit, but not enough. My wife tried to convince me to backpack with her, but I thought my job at "CyberCash" (ever heard of them?) was just too important - turns out that it wasn't so important after all. I had the freedom, but didn't fully appreciate it.
I generally agree with the weak points that the OP pointed out regarding cron. That being said, throwing out cron, or any other built-in system tool, isn't always a great idea.
When you adopt a new scheduler, you're inevitably creating work for your enterprise. It's yet another thing that must be learned and documented. There may be a new syntax to learn, which will mean you're incurring training costs (and the cost of errors) down the line.
Programmers love to improve things, but there's a real world cost to change that can't be ignored. cron may be archaic and lacking power, but it's well understood.
As for enterprise schedulers, they've been around for years. Off the top of my head, I've worked with 'Autosys', and 'Appworx'. These were robust, enterprise-ready schedulers that supported conditional execution, locks, as well as their own scripting language.
To be fair he didn't say throw out cron. He said cron will have a place for rotating log files etc. Which to me is infrastructure type stuff and not application level.
So the sysadmins will still use cron to do the infrastructure type jobs. But when a programmer needs something in his app to be scheduled he can use the replacement, this also frees them up from asking the sysadmin to install a cron script.
It's not hard to generate a certificate request. While Firefox and IE may use different routines to do a local key generation, it's certainly not difficult.
The scary warnings you're talking about come up if you're connecting to an "untrusted" site - who's SSL server certificate isn't signed by a known, trusted root CA.
Yes, generating a certificate request isn't hard. Maintaining a CA is annoying at best.
Do you have a link to a site that describes how to do local key generation in Firefox and IE? Maybe I was just looking in the wrong places?
The scary warnings I was talking about are not the "untrusted" site warnings, they are the warnings you get after the remote SSL server times out. I guess this can happen after a few hours, depending on the server.
Yes, it's the best solution to this problem, but it's still a major pain in the ass.
Yes, it has. When this article first came round I read it all because it was interesting but it's certainly way above the median length of articles that do well here (and above the median of most online content, I'd argue). I'd certainly bill it as being "rather long," though wouldn't go as far as "extremely."
This article was written ten years ago, about Microsoft. At that time, the hallowed brands were the likes of Borland and Corel. Sure, Google is dominant in search and advertising, but things have a way of changing in this industry. It seems that the when a company comes to dominate a category, the category begins to lose relevance.
Microsoft's dominance of desktop computing comes to mind. They controlled the platform. Then, the applications and development tools. Eventually, no one entered the desktop application market without dealing directly with Redmond.
Google's not going anywhere soon, but rest assured - the next Google is being developed (or thought about) right now.
We've been down this road before. In the pre-browser era, desktop application were king, but at a high cost to IT departments as well as end-users. The same game is being played out on mobile platforms now.
From a business perspective, do you really want to support multiple development efforts for each and every mobile platform? Will it be worth it in the long run?
The advantages of the mobile app platform must be balanced with the cost and maintenance overhead as well. Give me a great browser platform, and I'll gladly take its shortcomings over the long-term sustainment costs of a dedicated mobile app.