

HTML5 is the future of development, and it sucks - tylermenezes
http://blog.framebase.io/post/43496478876/html5-is-the-future-of-development-and-it-sucks

======
tulrin
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.

------
Skoofoo
> 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.

------
unconed
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.

------
PasserBy2
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!".

~~~
unconed
"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.

~~~
WayneDB
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.)

~~~
unconed
"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.

------
ibudiallo
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

------
general_failure
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.

~~~
PasserBy2
"Why would I want to write a cloud service front end 3 times..."

Because you want native platform look and feel? Will you have WP tiled layout
in your iOS app?

PS: you could use Mono.

------
puddlewitt
I too agree. Developing for the web is painful, as already stated the only
thing I like about it as a developer is the zero deploy.

------
macavity23
_"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.

------
WayneDB
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".

~~~
malandrew
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.

~~~
WayneDB
Here are a few big ones:

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.

~~~
ibudiallo
So what do you do when you have a user on Linux and another on Windows? That's
right you can't have rounded borders now do you?

~~~
dguaraglia
QT, Gtk and WxWidgets (among a crapload of other, not so mainstream portable
UI kits) would like to disagree.

~~~
ibudiallo
Now how would that differ from gender prefix in css. The point here being, you
will have to get some work done in order to have consistency .

~~~
dguaraglia
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.

In other words: meh.

