I feel like I have just seen the future and it is very bright. This would make mobile development so much easier and open up a completely new range of possibilities.
Just imagine ....
- writing just one app that runs on every desktop and mobile phone out there.
- apps which update entirely automatically, without any extra line of code, because they are basically just cached versions of a website.
- a designer, who just knows CSS & HTML, can make an entirely new GUI for your phone.
- an eco-system where the development of the interface (HTML) is completely separate from the kernel/browser and you can choose which kernels/rendering engine to run on your phone, independent of the user interface and vice versa.
- etc. etc.
Kudos to Mozilla for their vision and for not just developing the technology, but making a good looking prototype to demonstrate it.
However, I am a little bit skeptical that a web-based OS will perform the same as a native OS, especially in terms of battery consumption. But smartphones only get more powerful and html rendering engines only faster, so it can only be a matter of time. Also a little nitpick with respect to the title: the OS not entirely build using HTML, CSS and JS, it's just the user interface, which is just small part of the OS (compared to the kernel, etc.).
EDIT: I know most of this is already possible in principle, but the user / developer experience would be completely different.
- Everything is already one terrible interface for everything. Make a better interface.
- The better companies will minimize this. We still depend on cloud services like Gmail, github et.. on a day to day basis. And they still mess it up occasionally.
- There are ready designers who know nothing about UI design for each particular device pumping out apps.
- Look at the linux ecosystem. I think its working out.
* I don't know what programs you're using. I think the iOS interface is great and rife with amazing UIs by both Apple and 3rd party devs that I enjoy using every day. If your devices have terrible UIs that are non-unique, that's your business.
* I rely on those services via clients that beat the hell out of the native web offering. Cloud services are an inbuilt way of life, cloud or web-based apps can go die in a fire as far as I'm concerned. They have two benefits: Developer simplicity and access from anywhere. Everything else is just downsides.
* Of course, but making it easier doesn't help. Just like with all fields, most programmers and software designers are amateur and lazy. IMO making even easier for these people to create terrible apps and making it the cornerstone of a mobile OS is a really bad idea.
* ...You're joking right? I don't even know where to begin with that one, except to look at Linux on the desktop numbers and then come back to me.
The way I see it is this: the apps, the GUI and the underlining OS would be completely decoupled from eachother (much like Linux/BSD and Gnome/KDE). The OS would be free software, because that is what FOSS is good at (not end user facing software).
For the apps and GUIs there would be a marketplace (or ideally several), where people/companies can sell or give away for free their software. Most GUIs and apps would suck (just like most apps suck today). But there would be a few ones, which are truly great, much better than Google or even Apple could ever make them. And these would not be made by big companies, but by small startups consisting of creative people.
All software can update. There is nothing fundamentally different between a web apps' ability to update and a desktop applications' ability to update. If you need any proof of this, just look at Chrome.
Once you run software on your computer, if that software can connect to the internet, it can update itself!
there is something fundamentally different, you can choose not to update a native appp, you can also choose to run an old verion. you can also continue a native app if the creator decides its not worthwhile, or google buys them out
My point is that there is nothing* preventing any native app from including code to update itself. Over time, I believe that more and more native apps will do this. For example, Firefox is moving in that direction now.
* Except for in the case of iOS. Apple has a policy that apps are not allowed to update themselves. But there's still no technical limitation.
Right so we're discussing the reality of the situation, which is that web apps would have no choice but to force update (as they would be run server-side and hence the client wouldn't have a choice) and that native apps could be possibly, but aren't.
This is another Visual Basic craze, in which someone creates a way for non-programmers to program and everyone piles on thinking it will be the next big thing.
I thought that the general consensus was that you never wanted multiplatform anyway. Not because it can't be done but an app that looks and acts the same on both iOS and android (for instance) will suck horrible on at least one platform (but probably both).
Apps which will update automatically? That's just as possible with native apps but you have the option to turn that off - because it's a bad idea for a lot of applications. In general if you don't respect that as a developer I don't want to use your apps.
You can make an entirely new GUI for android right now if you wanted to. But for the same reason as in my first paragraph, you really don't wan't to fragment your userbase. The GUI guidelines are very important for apps to integrate well, as an app developer you would now have to support all those third party interfaces that will change every five minutes... I wouldn't call that a bright future.
Designing a good GUI is hard and if you have managed to make it easy it is going to be really bad.
> I thought that the general consensus was that you never wanted multiplatform anyway.
There is no consensus. It's like there is no consensus on static vs. dynamically typed languages. Both are good for different things, both have an important place.
On the one hand, without multiplatform apps, new platforms have a problem. The original iPhone had no apps, but it ran the web and everything on it. Likewise, without multiplatform apps, people on minority platforms - Linux, OS X, etc. - have far fewer choices.
On the other hand, without platform-specific apps, you miss out on a level of customization and tailoring that isn't possible in a multiplatform app.
Designing a good GUI is hard indeed and it requires a completely different skill set than the engineering task of writing a good OS/kernel/broswer. That is why ideally the two should be taken on by different teams in my opinion.
So the plan is to force the UI-team to work in javascript and that way automatically get rid of the kernel-guys?
No, but seriously, who does that today? (aside from one-man operations) And how is this going to help?
As to a third party GUI, I'm fond of the idea in for instance the android world. Instead of manufacturer-specific user interfaces, why not a third party interface developed by an independent company that doesn't produce phones. As it is now manufacturers care more about being unique than good and google doesn't put enough effort in it because everyone will change it eiterway.
But there are serious obstacles to succeeding with that and I don't see why that has anything to do with the development-side of it.
> No, but seriously, who does that today? (aside from one-man operations) And how is this going to help?
People used to write code in assembly and interface directly with the hardware. Then OSes and compilers came and made everything easier for everyone involved. Only a few highly specialized hackers know how to write device drivers and assembly anymore.
I am convinced that in a few years from now (remember I was talking about the future) the majority of developers will be "frontend developers" who know HTML/CSS/JS (or hopefully JS replaced with something more productive). Right now that thought might suck, but imagine how many tools and libraries will be available by then.
> But there are serious obstacles to succeeding with that and I don't see why that has anything to do with the development-side of it.
I am not sure what you are talking about. I am talking about completely decoupling the user interface from the rest of the OS, a little bit like it is the case on the desktop with Linux / BSD and KDE / Gnome. Only that making user interfaces does not require a lot of technical knowledge.
EDIT: Just to clarify. I am talking about a hypothetical future mobile OS not Android or iOS. The way I am seeing this is a little bit like WordPress plugins. There would be a default GUI, but most people would download a custom one. A large number of UIs would be free, but if you want to be hip you need to pay for the latest one. There will be an entire new class of UI designers, just like since a while ago there is a new class of mobile app developers.
EDIT2: The OS itself would be FOSS and the hardware would dead cheap, because it is just a commodity. Eventually it will replace desktops, for instance with a special javascript API to run a virtual machine, which can run a desktop OS on your phone, if you need one, e.g. for development.
I'm not arguing against the use of a high-level language.
I also thought of *nix as an example, and that is in my eyes a perfect example of how you do not want it to be (the result at least).
I don't get the need for many different interfaces. You do realize that as an app developer you have to constantly adjust your app for different interfaces, and people complain they have to make high-resolution interfaces for the ipad3 - that's nothing compared to trying to adapt to different user interfaces.
A user interface is an investment, a whole ecosystem that many generations of applications depend upon. You don't just change it at will, think about all the inconsistencies you'd have to deal with.
>However, I am a little bit skeptical that a web-based OS will perform the same as a native OS...
I believe the idea is that it will be native on ALL devices, thereby eliminating the need to convert one application for multiple devices. An application written in HTML5/CSS/JavaScript for the web should function the same way on a mobile device OS that is essentially a web browser. Am I wrong?
Comments
I feel like I have just seen the future and it is very bright. This would make mobile development so much easier and open up a completely new range of possibilities.
Just imagine ....
- writing just one app that runs on every desktop and mobile phone out there.
- apps which update entirely automatically, without any extra line of code, because they are basically just cached versions of a website.
- a designer, who just knows CSS & HTML, can make an entirely new GUI for your phone.
- an eco-system where the development of the interface (HTML) is completely separate from the kernel/browser and you can choose which kernels/rendering engine to run on your phone, independent of the user interface and vice versa.
- etc. etc.
Kudos to Mozilla for their vision and for not just developing the technology, but making a good looking prototype to demonstrate it.
However, I am a little bit skeptical that a web-based OS will perform the same as a native OS, especially in terms of battery consumption. But smartphones only get more powerful and html rendering engines only faster, so it can only be a matter of time. Also a little nitpick with respect to the title: the OS not entirely build using HTML, CSS and JS, it's just the user interface, which is just small part of the OS (compared to the kernel, etc.).
EDIT: I know most of this is already possible in principle, but the user / developer experience would be completely different.
Just imagine...
- One terrible interface for everything
- Apps that update to broken versions without asking you and can't be reverted
- A web designer, who knows nothing about UI design for an app let alone the specific UI conventions of each device pumping out apps
- An ecosystem where it's a complete free for all. That always works out right?
Yeah I think I'm going to stop imagining now.
- Everything is already one terrible interface for everything. Make a better interface.
- The better companies will minimize this. We still depend on cloud services like Gmail, github et.. on a day to day basis. And they still mess it up occasionally.
- There are ready designers who know nothing about UI design for each particular device pumping out apps.
- Look at the linux ecosystem. I think its working out.
* I don't know what programs you're using. I think the iOS interface is great and rife with amazing UIs by both Apple and 3rd party devs that I enjoy using every day. If your devices have terrible UIs that are non-unique, that's your business.
* I rely on those services via clients that beat the hell out of the native web offering. Cloud services are an inbuilt way of life, cloud or web-based apps can go die in a fire as far as I'm concerned. They have two benefits: Developer simplicity and access from anywhere. Everything else is just downsides.
* Of course, but making it easier doesn't help. Just like with all fields, most programmers and software designers are amateur and lazy. IMO making even easier for these people to create terrible apps and making it the cornerstone of a mobile OS is a really bad idea.
* ...You're joking right? I don't even know where to begin with that one, except to look at Linux on the desktop numbers and then come back to me.
The way I see it is this: the apps, the GUI and the underlining OS would be completely decoupled from eachother (much like Linux/BSD and Gnome/KDE). The OS would be free software, because that is what FOSS is good at (not end user facing software).
For the apps and GUIs there would be a marketplace (or ideally several), where people/companies can sell or give away for free their software. Most GUIs and apps would suck (just like most apps suck today). But there would be a few ones, which are truly great, much better than Google or even Apple could ever make them. And these would not be made by big companies, but by small startups consisting of creative people.
All software can update. There is nothing fundamentally different between a web apps' ability to update and a desktop applications' ability to update. If you need any proof of this, just look at Chrome.
Once you run software on your computer, if that software can connect to the internet, it can update itself!
there is something fundamentally different, you can choose not to update a native appp, you can also choose to run an old verion. you can also continue a native app if the creator decides its not worthwhile, or google buys them out
chrome is the exception not the rule
My point is that there is nothing* preventing any native app from including code to update itself. Over time, I believe that more and more native apps will do this. For example, Firefox is moving in that direction now.
* Except for in the case of iOS. Apple has a policy that apps are not allowed to update themselves. But there's still no technical limitation.
Right so we're discussing the reality of the situation, which is that web apps would have no choice but to force update (as they would be run server-side and hence the client wouldn't have a choice) and that native apps could be possibly, but aren't.
This is another Visual Basic craze, in which someone creates a way for non-programmers to program and everyone piles on thinking it will be the next big thing.
See my post below (the one that the majority of development will be in HTML/CSS/JS in a few years). I don't want to copy & paste it here.
I thought that the general consensus was that you never wanted multiplatform anyway. Not because it can't be done but an app that looks and acts the same on both iOS and android (for instance) will suck horrible on at least one platform (but probably both).
Apps which will update automatically? That's just as possible with native apps but you have the option to turn that off - because it's a bad idea for a lot of applications. In general if you don't respect that as a developer I don't want to use your apps.
You can make an entirely new GUI for android right now if you wanted to. But for the same reason as in my first paragraph, you really don't wan't to fragment your userbase. The GUI guidelines are very important for apps to integrate well, as an app developer you would now have to support all those third party interfaces that will change every five minutes... I wouldn't call that a bright future.
Designing a good GUI is hard and if you have managed to make it easy it is going to be really bad.
> I thought that the general consensus was that you never wanted multiplatform anyway.
There is no consensus. It's like there is no consensus on static vs. dynamically typed languages. Both are good for different things, both have an important place.
On the one hand, without multiplatform apps, new platforms have a problem. The original iPhone had no apps, but it ran the web and everything on it. Likewise, without multiplatform apps, people on minority platforms - Linux, OS X, etc. - have far fewer choices.
On the other hand, without platform-specific apps, you miss out on a level of customization and tailoring that isn't possible in a multiplatform app.
Designing a good GUI is hard indeed and it requires a completely different skill set than the engineering task of writing a good OS/kernel/broswer. That is why ideally the two should be taken on by different teams in my opinion.
So the plan is to force the UI-team to work in javascript and that way automatically get rid of the kernel-guys?
No, but seriously, who does that today? (aside from one-man operations) And how is this going to help?
As to a third party GUI, I'm fond of the idea in for instance the android world. Instead of manufacturer-specific user interfaces, why not a third party interface developed by an independent company that doesn't produce phones. As it is now manufacturers care more about being unique than good and google doesn't put enough effort in it because everyone will change it eiterway.
But there are serious obstacles to succeeding with that and I don't see why that has anything to do with the development-side of it.
> No, but seriously, who does that today? (aside from one-man operations) And how is this going to help?
People used to write code in assembly and interface directly with the hardware. Then OSes and compilers came and made everything easier for everyone involved. Only a few highly specialized hackers know how to write device drivers and assembly anymore.
I am convinced that in a few years from now (remember I was talking about the future) the majority of developers will be "frontend developers" who know HTML/CSS/JS (or hopefully JS replaced with something more productive). Right now that thought might suck, but imagine how many tools and libraries will be available by then.
> But there are serious obstacles to succeeding with that and I don't see why that has anything to do with the development-side of it.
I am not sure what you are talking about. I am talking about completely decoupling the user interface from the rest of the OS, a little bit like it is the case on the desktop with Linux / BSD and KDE / Gnome. Only that making user interfaces does not require a lot of technical knowledge.
EDIT: Just to clarify. I am talking about a hypothetical future mobile OS not Android or iOS. The way I am seeing this is a little bit like WordPress plugins. There would be a default GUI, but most people would download a custom one. A large number of UIs would be free, but if you want to be hip you need to pay for the latest one. There will be an entire new class of UI designers, just like since a while ago there is a new class of mobile app developers.
EDIT2: The OS itself would be FOSS and the hardware would dead cheap, because it is just a commodity. Eventually it will replace desktops, for instance with a special javascript API to run a virtual machine, which can run a desktop OS on your phone, if you need one, e.g. for development.
I'm not arguing against the use of a high-level language.
I also thought of *nix as an example, and that is in my eyes a perfect example of how you do not want it to be (the result at least).
I don't get the need for many different interfaces. You do realize that as an app developer you have to constantly adjust your app for different interfaces, and people complain they have to make high-resolution interfaces for the ipad3 - that's nothing compared to trying to adapt to different user interfaces.
A user interface is an investment, a whole ecosystem that many generations of applications depend upon. You don't just change it at will, think about all the inconsistencies you'd have to deal with.
>However, I am a little bit skeptical that a web-based OS will perform the same as a native OS...
I believe the idea is that it will be native on ALL devices, thereby eliminating the need to convert one application for multiple devices. An application written in HTML5/CSS/JavaScript for the web should function the same way on a mobile device OS that is essentially a web browser. Am I wrong?
Where were you when webOS was struggling to take off?
P.S. You might want to take a look at the Enyo framework, the one aspect of webOS that has a chance of fulfilling its potential.
enyojs.com