I'll try here to articulate something I feel about how software should be. This includes both software for end users, and software for developing software (such as programming languages). This is something that, whenever I run up against something in today's software that runs counter to this principle, I sigh and shake my head. Here it is:
For the user, there should be no distinction between platforms.
An application should give the same capabilities, the same information (modulated by platform-specific idioms and resources) regardless of whether the user is using the Web or a mobile app. The distinction between the two is artificial. The fact that developers currently have to use different languages and tools to develop for the different platforms is either an oversight or an intentional barrier.
I should be able to save a website as an icon to my phone's home screen, and use it as an actual mobile app, not just a convenient bookmark to a tab in Safari. Conversely, I should be able to use something that's ordinarily a mobile app, within a browser as if it were a web application (perhaps with URLs to various screens or objects within it).
I consider responsive design, wherein a web page changes its layout to fit the screen real estate available, to be a step in the right direction. Ideally, it's just as easy to reach all the relevant links and areas whether the user is using a desktop or mobile web browser.
Some software is written for developers, and so...
For the DEVELOPER, there should be no distinction between platforms
If I want to develop native apps in Python, I should be able to do that. If I want to write front-end code in Python, I should be able to do that (which is why I got excited about Transcrypt for a bit). I want the same for you and your favorite language (if that is, for some reason, not Python 😬).
Carrying this even further, I feel like I should be able to use a language with a framework written for another language. Python on Rails, for example.
"A world without borders or boundaries..."
I'm sure there are lots of reasons why this is all a bad idea, or not feasible. Or maybe you know of good ways of crossing these artificial boundaries, or have an idea of how to erase them forever. Let me know what you think in the comments.
Cover image: Milliau Viaduct, France. Source: Digital Trends, or at least a Google Image Search page that links there.
Top comments (9)
I understand why you feel this way. I really do. But if there's one thing I've learned, it's that using the best tool for the job pays off.
Platforms were built with certain languages, frameworks, and architectures in mind. And while you can build things with any number of transpiled or hybrid tools these days, you're going to have a better experience reading the vendor's documentation and writing with the libraries and languages that they build the platform with. This ultimately means the user is going to get an experience that is consistent, performant, and feels at home on their device and you're going to have a codebase that is maintainable by yourself and others into the future unlike fragile approaches to building with unsupported environments.
And "best tool for the job" isn't just a client thing. You can write a server with anything, in any number of languages, picking the frameworks around that language for the task at hand. Ask yourself: are you building a large server monolith or a small microservice? Do you need low level access to things for performance, or you just serving up some files? A language + framework that's the best tool for that job will show itself once you start talking it out. A Golang microservice would be very different than a Rails instance, for example. Would either work? Of course, but why not pick what makes the most sense instead of just picking the language that you're most familiar with?
What if somebody else joins the project and has to figure out your weird Python -> Javascript transpiler? Does anybody even want to work on that? When you go interview for a job and they say "So it says here you've been doing Android development" and you say "Yeah, but in Pearl and HTML5", they'll probably give you a pretty weird look. There's vibrant communities of whatever environment you can think of, and it's fun to be a part of those communities. You're opting out if you aren't building upon a common ground. Ask the RubyMotion people when they show up to WWDC.
And take it from me, if you're paving your own road and building with alternative tools, you'll be reinventing the wheel... a LOT. You won't be saving time, you'll be wasting it figuring out things that would be simple otherwise.
I've written about my thoughts on cross-platform development in clients on my blog, and explained why I feel the tech stack matters when building things. Feel free to give it a read: gabekangas.com/blog/2018/2/why-you...
Plus learning new things is a hell of a lot of fun and makes you a better developer, and maybe even a better person. Once you realize you're not restricted to the single language you're most comfortable with you realize there's nothing that you can't do. And that's pretty cool.
Thanks for your thoughts. As someone who's used at least a dozen languages, I know it's fun to learn new things.
I agree that what I'm talking about is not possible in all situations. It's more like (the beginnings of) a mission statement. It's intended to say that we should value certain things, even if they currently are not valued by the status quo. If people want what I'm talking about, they'll demand it from the developers of the software and platforms they use. If nobody wants it, then things will stay as they are.
While platforms often prefer certain languages, that's a choice that platform authors make, which they could have chosen otherwise. In your blog post, it was Apple who chose to exclude React and Xamarin developers, not something inherent to what iOS is. Netscape chose not to make a language-agnostic scripting environment the norm for the web.
Wheels often have to be reinvented when there's a new way of doing things. That's not necessarily a reason not to try.
Regarding hiring: React Native and Transcrypt are possible solutions when you already have front-end developers or Python developers respectively. React and Python are both already popular tools. In the case of React Native, I doubt hiring would be an issue. In the case of Transcrypt, I want to work on it, for one, and would be overjoyed if someone paid me to do that. I know lots of other people who like Python at least, and I bet some of them would work with Transcrypt if there were money involved.
There's a critical flaw in trying to erase boundaries here. The differences between mobile, tablet, desktop, etc. are not about screen size - that matters, but people resize a browser window, too. Make your stuff so it'll show on as wide a span of sizes as possible, and you'e golden.
No, it's mainly about input methods. Touch screen input is and will remain very distinct from mouse input, and a physical keyboard is a far different affair than a software keyboard on a touch screen. Touch screen input means no hovering, no cursor hinting, and far less precision in put, meaning far larger inputs are required - which will irritate a mouse user! No hardware keyboard means no key short cuts, no tab completion, none of the features we routinely use keys for - but software keyboards usually have predictive text, with varying accuracy, and built-in emoji capability, both of which their uses will expect to be able to use.
Then there's browsers and OS'es response to custom input types - looking at HTML inputs, the 'date' and 'time' inputs come to mind a great deal here. On Android, for instance, tapping an input field of type 'time' gives you a fancy clockface style dialog where you select a time. On a desktop Chrome, however, you just have an up and a down button to increment or decrement time. Meanwhile, 'date' inputs show, respectively, a nice calendar picker, and an ugly box that looked like it fell out of a 1990's accounting system. Consistency is, apparently, for chumps? But that's our problem now, as the developers.
From a UX perspective, there are huge differences between touchscreen devices and desktop devices. And I thank my lucky stars that the Windows 8 era hybrid devices haven't taken off more than they have, TBH.
I don't disagree about different input/output methods sometimes needing different design. However, sometimes this ends up meaning that certain capabilities are only available on one platform or another. For example, right-click type menus and searching within text are usually unavailable on touch interfaces (or at least not obvious). Providing or emphasizing those capabilities is a choice that developers or designers could make, in a way that's suitable to a given platform.
This is what I mean, though. It's a rare designer who can make all options available on both platform types. So it may be best to design the two apart, each focusing on making its best UX available.
Actually the real barrier is UX, not language. You have to design for each platform so that the app provides same user friendliness in all platforms. So platform here is mobile, VR, desktop, laptop...etc; not iOS, Android, Windows. This is exactly why new Windows start screen failed. There is no shared experience between a tablet and desktop. What is shared are just the information and actions (ex: my email content and an action that shows me the inbox).
Since this mostly means re-writing at least the experience of the app from scratch, it can be better to do it using platform tools. You can still use a common engine for the logic, which is especially easier if your app depends mostly on a back-end. For example in my opinion it is better to design a webpage separately for mobile and desktop than use a responsive design. It is not just touch vs mouse, your website should be able-to-be-used-while-walking, or while in toilet..etc
At this point I feel pretty sympathetic to Flutter where you design for mobile but not for iOS or Android, while still using their native interfaces. It is not surprising such a new language emerges while we start discussing similar topics. Also as a game developer I like how cross platgorm game engines work where experience matters more than the platform. I think every front-end developer and UX designer should do some games to get an idea of some hardcore experience designing.
Looking at how games provide the best experience across different kinds of platforms is a great idea.
Actually my point was not cross-platform game design, but solely game design itself. It is a kind of very dense experience design that may be helpful for developers to see their job more than system programming, i.e. something that includes experience programming.
Still, unlike apps many games work very well cross platform only with subtle tweaks (if not none). So checking them across different platforms would also definitely provide good perspectives.
Here are few resources I can think of off the top of my head.
For Responsive Design:
For developing native apps using web technology: