HTML5 is the future of development, and it sucks
blog.framebase.io
blog.framebase.io
The reason is the same as to why Java never replaced C/C++: Performance.
HTML requires runtime interpretation so matter how fast that is made compiled programs will be orders of magnitude faster. The reason lies in the laws of physics and as such will always be an insurmountable factor in favor of machine code.
So called experts have been predicting the end of native programs for many years however it has failed to materialize. When the web catches up and can do something as well as a native program the native program has moved on to even bigger and better things.
There will always be a place for both and the likely future will be just as it is today, a mix of web-based apps and native apps.
As a matter of fact if you look at the current market with mobile platforms included native applications have actually increased.
As a side note, if you are looking at Microsoft as an indicator of the future you will be sorely disappointed. Microsft's "me too" development strategy seved them well in the past however in the last five years it has been their undoing. It is possible that they can turn things around but it certainly won't be with Windows 8.
We might be. I've been thinking a lot about this, because this is something we will eventually need to do. It is ridiculous how contrived and complicated it is to develop for the web nowadays. When the web first came out, all you had to know to make a competitive website was HTML and some Perl or PHP. Now it is a fatter HTML(+Haml), along with CSS(+Sass/Less), JavaScript+jQuery+Backbone(+CoffeeScript), Ruby+Ruby on Rails+RSpec/Python+Django, and potentially others, none of which are getting any simpler. It's already become impractical for neophyte developers to learn the ways of the web versus Android/iOS.
The main issue is that we would have to design a successor to the web that is so much better that it's worth jumping ship and obsoleting the huge amount of work put into building the web, and worth the work of creating and maintaining ports for every platform and convincing millions of people and thousands of developers that it's the future, in the midst of a cold war between the open web and walled garden platforms.
I plan on writing a post with my design for such a successor :) This is something more people should be discussing. An open platform can't win if it takes so much contrived knowledge to make an app for it.
Different constraints, different security model, different applications. But the fact that triple A games still routinely crash on Windows is enough of an indicator that the security and stability of native code is highly overrated.
If native isn't up to the task, then HTML/JS certainly ain't because HTML/JS is hosted in a browser that runs natively. That was his whole point.
Furthermore, I have witnessed hundreds of different "top sites" that simply don't work in all sorts of browsers. The typical response from web devs is, "They probably built it wrong." Well, I suppose you can apply the same logic to your triple A games example. (Popularity may not be due to any one type of quality. Look at Minecraft.)
But, when a native app crashes, it usually means an exploit waiting to happen. When a browser renders something wrong... it renders something wrong. You close the tab and move on.
Why would I want to write a cloud service front end 3 times - in Obj-C ,Java, C#, HTML5 itself (firefoxos). There's no value.
Because you want native platform look and feel? Will you have WP tiled layout in your iOS app?
PS: you could use Mono.
Eh? Anyone who has ever programmed any functional language can grok JS very quickly.
I don't care what you say - I will find a market that I can develop native apps for or I will quit being a developer. That is how much I think HTML/CSS/JS suck for front-end development.
The only thing the web's got going for it is the zero-deployment. Everything else about the web (for apps) is stone-age compared to native platforms.
"I can’t help feeling that we might be better just starting over with a totally new spec."
Agree, 100%. I don't want to use a document platform as an application platform. HTML is fine for documents. Let's have something new for apps please. I don't want to type "5 divs" to have a simple 3-column grid layout. I want to type "grid columns=3".
HyperTEXT MARKUP Language
HTML is for documents. Some sort of sick, twisted ideology has proclaimed it the all-useful programming language, but I repeat -- HTML is not an all-purpose programming language, the proof is in the name.
I want to deal with arrays, strings, pointers, and variables. I want to get down there with the hardware and control it myself. I want to optimize memory myself.
I want to do the dirty work because I want control over the computer I'm programming for.
Trying to replace C/C++/ObjC/Java/Python with HTML is like trying to replace LaTeX with plain text formatting. It's just way too limited for ~90% of the uses of programmers.
Don't get me wrong, HTML is awesome for documents and has come a long way, but it is no application development platform.
Not when you have <h1> and <body> tags scattered throughout instead of
#include <iostream>
#include <string>
int main()
{
using namespace std;
cout << "Do you honestly think HTML5 is a replacement for C++?\n";
String x;
cin >> x;
cin.ignore();
if ( x = "Yes" )
{
cout << "You probably work for Google. Get out of here!\n";
}
else if ( x = "No" )
{
cout << "It's nice to see that we're on the same page here; HTML is a document editing language first and a programming language 50032th.\n";
}
return 0;
}I think a lot of people conversationally use the term HTML to mean the same thing.
Anyway, I'm interested to know what your experience is. What kind of apps do you make and how has HTML (the royal, general HTML) worked out vs native kits?
HTML/JS/CSS as an application development platform is improving and covers most development needs, social, LOB, SaaS, etc. HTML turns out to be a pretty decent view rendering engine. It's still a bit rough around the edges and won't replace native code in all situations, though, it is a much easier way of targeting and deploying to users across a multitude of platforms.
Edit: As for experience, I spent 5 years on native apps, deployed to strictly controlled government Windows environments. Nightmare. Rebuilt same apps in a quarter of the time in HTML/JS/CSS, with far fewer issues. Work on various other Web apps now, couldn't be happier especially with all the tools/libraries/services springing up.
I actually deploy desktop apps to a lightly controlled HIPAA environment that is mostly Windows. We use ClickOnce to get as close to zero-deployment as possible. We also do web applications private and public (for our clients).
Personally - I'm not sure how I could build HTML apps faster and still retain the same quality. I'm betting that your HTML apps, like ours, aren't as "rich" as the desktop counterparts.
Another variable is that rewriting any product as a minimum-viable-product often goes quicker. Not saying that's how it went out for you, but it's worth mentioning.
Genuine question here. We're working in this space and we want to know more about what you feel is lacking. We have our ideas on how things can be improved, but we want to hear specifics from developers like yourself.
1. Abstractions that make sense, that are not built up from hacks, but are core to the platform itself. That is my number one peeve about the web. Like I said in my original post, I want to specify "grid columns=3" instead of "div div div div div".
2. Control. When I build a native app, I have several orders of magnitude more control over the resulting product. Compare to the web and being at the mercy of browser manufacturers. I can access memory, files, TCP, UDP, ICMP. I don't have to break my program up into front-end + server if I don't want to. I don't have to use shims to get rounded corners or drop shadows. I can make a program that runs in your "tray" and receives push notifications without having to setup some complicated server-sided hackery to faux-push to the browser. I can make the computer do whatever my user wants, but not only that - I can do it with ease because I'm in control.
3. Choice of programming language. With native, I have a number of viable choices. (I don't care that anybody else thinks Javascript is great. Relatively, it's not...and besides...I want a choice. I want control! I am a solid Js programmer (was doing it 15 years ago and I haven't let it stagnate - I recently ported Node.js core module system to a completely different, non-v8 engine.)
4. Modularity (an important instance of "Abstractions that make sense"). Most native environments allow the developer to easily modularize commonly used artifacts (code, UI components, images, etc) without sacrificing performance. Compare to the web where it's a real PITA to make anything modular CSS, HTML or Javascript without resorting to using other tools that "transpile" down to CSS, HTML or Javascript - at which point I'm not using the web platform anymore, I'm using something else.
BTW, I never said those toolkits were better than HTML/CSS, just said that it is doable. In general, the more you depend on the native rendering engine for your widgets (be it the browser's or heavy-weight controls in your native toolkit) the harder it is to get consistency. If you use something like FLTK (which looks kinda gross, but renders every control) then you get consistency at between platforms, but not with the platform.
In other words: meh.
Due to the different behavior of browsers for handling "native" HTML elements (select lists, radio buttons, etc), I think it's a good thing advanced and opinionated constructs like grids are not built in.