You can have my native SDKs when you pry them from my cold, dead fingers.
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".
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 guess I'm still wondering what specifically you disagree with. You didn't say anything about that; just the wording. I don't think the GP's argument was well stated, but the general sentiment seems clear enough.
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?
I'm sorry, I meant that the comment I replied to didn't seem to imply that HTML meant "suite of relevant standards".
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.
It's so funny how people can have similar experience and opposite results. I don't doubt that you build them quickly, but there are a lot of variables to take into account I think.
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.
What about the web is stone age and that you would need for web development to be on par with native development?
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.
Sure you will. Not a free lunch to be had when writing portable code.
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.
There's plenty of js grids out there that allow you to pass in column definitions. You should try out angular.js, you can build your own directives to support expressions like "grid columns=3"
Why are they hacks? HTML provides a set of well-defined, programmatically accessible, renderable elements which support events. You are free to manipulative them as you see fit. If you want to paint your own controls, you can do that too. It's really not so different from native UI definitions I've used.
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.
> I can’t help feeling that we might be better just starting over with a totally new spec.
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.
I agree that HTML5 is not pretty and not ideal. A large part of the HTML5 trend (for apps) is that most apps have moved to the cloud. This means that the front end is not overly complex. For a world where software is moving to the cloud, HTML5 fits the bill. Again, not pretty but works.
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.
HTML is unlikely to replace native platform development except in some areas where a "cloud based" app makes sense such as calendars, email and file storage... Or in other words where content is document oriented.
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.
Modern web basically limits client-side innovation to within HTML/JS. Why do I need to wait for some consortium to scratch once per decade and spit out an evolutionary version of same ol'? "Look we have this control you can draw on, we call it The Canvas! Innovation!".
"And now we've taken this canvas, and hooked it up to a modified version of OpenGL ES!" Only it turns out that neither Apple nor Microsoft trust their "superior" native drivers enough to let the open web talk to it, even through a completely type-safe and memory-managed interface.
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.
And what triple A games are even written in HTML/JS?
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.)
"Native code's benefits are overrated" is not the same as "HTML is superior!". Like I said, different constraints, different requirements.
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.
HTML5 sucks because he doesn't know about UTF-8? Yup, definitely a C programmer. I'll be over here, doing JS, not giving a shit about binary-safe strings.
Well you learn c, c++, java and all those fantastic languages for years and you mastered them. Now you come across javascript and you suck. There is only one thing to do. Learn it and stop complaining. This is a whole new game
"Javascript is so far removed from what most programming languages look like, that people who know almost any other modern language still require extensive education to understand Javascript."
Eh? Anyone who has ever programmed any functional language can grok JS very quickly.
HTML5 + CSS3 AND Js (SenchaTouch2) and PhoneGap is best... to developing webmobile and webapp for multi-platdorm, coding a single time and runs on all platforms, that it is future! ahahahaha
34 comments
[ 0.20 ms ] story [ 171 ms ] threadI 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
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.
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.
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.
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.
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.
Eh? Anyone who has ever programmed any functional language can grok JS very quickly.