A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
Web is horrible. Mostly dynamic typed languages and tooling that lags 30 years behind native development. (Hello vim, good bye IDE).
Mobile is interesting from a standpoint that it's more resource constrained than real software. Tooling is adequate. The languages tend to be the ones you know from native development (Java, C#, C++, C).
Both paradigms are not overly complex and any half way competent native "desktop" developer should be able to produce mobile/web software within a few days.
Started on desktop, did some web, now doing some mobile.
The process of learning it isn't hard and the process or your approach doesn't have to be so different from desktop. The best way I can think of to really learn what it is to do something on it is to try a project that makes practical sense for the platform you're aim at.
Also I think just because it's in a browser doesn't make it an web app. It's then a desktop app built with web technologies.
Think about what can each platform bring to the solution for a problem and do they make sense for a given software set. I think they all should complement each other not aim to replace each other even if they overlap.
Once you can identify what you want to do with the platform it would be easier to learn how to accomplish that.
Tuesday, March 17, 2015
I haven't done any mobile, but I was desktop only programmer around 2005 with 6-7 years of experience and then started to get into web programming. The essential difference, the mind shift is that you have two contexts instead of one. GUI, the end user presentation is one context, the backend processing is another. In desktop these two are in the same context (stack or however you call it). You press a button, event is called, you do some processing and respond back. Everything is in the same context. In web, you press a button, the server is called (that runs in completely another context), the server processes the call, responds, the browser catches the response and shows the response (a report, a message or whatever).
It would be very similar like Microsoft client server applications (RPC) from the end of 90ths. The web server (PHP, Rubi, .NET) is the COM component and the client (browser together with js/html) is the client application. So, keep in mind that there are two separate worlds/contexts and you should get into this very quickly.
The tricky part is handling all of the error situations where your request never made it to the server, the server returns a 500 error, the request times out before returning, etc.
A lot of apps fire off a request and then do other stuff and if the response comes, it fires an event in the app indicating the response is back and to handle it. It does take a mind shift to split your code "in half". Almost like going back to early Windows message-based programming (which is still there but it's been abstracted away).
I guess I was thinking more in terms of programming, but really I am also interested in the business side of it. When I tell my friends that I am working on a desktop program, they sort of sound sad and think that I should definitely be only doing mobile, or maybe web. I know that is not necessarily true based on what I read on this forum, but then again, it seems much better to be able to pick one's platform based on business choices instead of merely being LIMITED to one platform type because you just don't know how to do it.
For me, I do have an idea for a new app that might work nicely as an iPhone app, but to do that would require buying a Mac, maybe buying in iPhone (I have an iPad), and then learning Objective-C and their toolkits. Not a small activation barrier, it feels to me.
Web development has a lower barrier, but for me there is a patience-taxing barrier; I just get turned off by it so far.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz