[gubatron]

Issues I have with HTML5:

- Javascript

- Javascript

- Javascript

- Fragmentation like no other

- Lack of APIs

- Sandboxed environment

- A bunch of morons writing "frameworks" without a clue of computer science (same thing as many popular Wordpress PHP plugins written by people who have no clue of even how memory allocation is supposed to work)

- A bunch of other morons copying and pasting the work of other morons.

- No real memory management

- No real anything or poor support at anything (no sockets, no primitive types, no threads, cross domain BS)

- Internet Explorer

- Javascript

- Internet Explorer

- Javascript

...

It's just not what the foundation was meant for.

It only took Steve Jobs talking about how bad flash was and closing the endless array of development options that we have outside Objective-C and HTML5 to make the world try to reinvent the wheel in javascript, all the while ignoring the fact we have more powerful desktop computers than ever, all the while putting more money in the pockets of those that run cloud infrastructure.

I hope more guys like Zuck come out on the record and let the world know this is ludacris, that all these decades working on out of this world compiler optimizations and technology that's light years away from the browser can't be forgotten.

Yes, we need to be in the browser, but give me a break, Javascript?

It's just sad seeing the turn of events of our industry going in this direction, I'm glad of this whole "App" revolution and Zuckerberg saying this at his first appearance after the IPO, I hope it sobers up a bunch of decision makers.

[amix]

I can't believe this biased and unintelligent rant is being upvoted. HTML5 does not suck because of JavaScript, or because of using greedy algorithms, or because people allocate too much memory. It sucks because browser support isn't there and Apple/Google/MS does not give a damn about HTML5. And if you think about it, it makes sense, it's much better for Apple/Google/MS that developers develop exclusively for their platforms and not for HTML5 (a platform that could be run on any OS).

What we need is an independent browser vendor (Opera, Mozilla) to do an amazing HTML5 experience.

[mirsadm]

The story of the web up until now: It sucks because browser X doesn't support technology Y correctly.

[randomdata]

The thing about HTML5 is that it does not enforce any real design patterns, so if you are not very careful with the design of your application, it will quickly become a horrible mess. I expect that is where the parent's disdain is coming from.

Interestingly, when you do introduce design patterns in your HTML5 app, it starts to very closely resemble a native application. At that point, there is little advantage to using HTML5 over native environments from a developer's perspective. The only real win from HTML5 being its ubiquity.

[user24]

JavaScript:

There's nothing wrong with JavaScript. It's a beautiful, powerful language if you know it.

Fragmentation:

Seriously? One code-base with a few cross-device tweaks is, in my opinion, infinitely better than n native apps. Just because n is currently 2 does not make it scaleable.

Lack of APIs:

I don't know what you mean by this.

Sandboxes:

That's a feature not a bug

Morons:

You get that everywhere.

Memory management:

Ditto.

Poor support:

That's really just a rant against JS again isn't it? Cross domain "BS" is easily solved with allow-origin, and if you don't own the 3rd party server then you really shouldn't be programatically accessing it.

IE:

Meh, it's not as bad as it was. Nor is it popular enough to make it worth worrying about for lots of people.

[kbolino]

There's nothing wrong with JavaScript. It's a beautiful, powerful language if you know it.

All numbers are 64-bit double-precision floating-point. Interacting with binary protocols or cryptographic libraries is painful.

All strings are UCS-2, not true UTF-16. Characters outside the BMP are second-class citizens.

Those are two issues that I can think of in JavaScript-the-language. The most common use of JavaScript-the-stack, providing interactive functionality in a web browser, is riddled with gotchas like bizarre inconsistencies and arcane corner cases.

That's not to say that you can't do great things with JavaScript (plenty of evidence for that), or that the situation isn't changing (Mozilla added arrays of all the various integral types, but the individual elements still get treated as floating-point when extracted). But you have to be very careful (or use a framework made by someone who was careful), which IMHO makes it anything but "beautiful".

[user24]

All good points - "nothing wrong" was overstating it. I still say it's not a reason to dismiss HTML5 though, JS is far from unfit for purpose.

[rdtsc]

> There's nothing wrong with JavaScript.

"Beautiful if you it" know also means "this is the only thing I know and the only thing that is viable so I might as well like it".

Was it hailed as a beautiful language when it came out? Why not? I don't remember accolades written about it. Oh because it is the only thing that runs on the browser. Those two things are orthogonal and one doesn't follow from the other no matter how much we try to make it that way.

> Seriously? One code-base with a few cross-device tweaks is, in my opinion, infinitely better than n native apps.

Users don't care how many languages or how many tweaks your product code has. If it is slow to render, it flickers, if it takes forever to do its job, it is shit and it gets thrown away, regardless if it is written in Backbone.js or Ember.js, Haskell, or COBOL. It doesn't matter. That was the point.

[user24]

> Was it hailed as a beautiful language when it came out? Why not?

Short-sightedness? Confusion between JS and the DOM API? I don't see why you're bringing up "when it came out" either.

> "Beautiful if you know it" know also means "this is the only thing I know"

I don't see how that follows either.

I said that because many developers have a prejudiced impression of JS from the ie/netscape/image rollover days when it was hastily dismissed as a toy. If you spend some time looking at it seriously you can appreciate just how good "the good parts" are.

[ianstormtaylor]

To be fair it wasn't hated "when it came out" because of it's ugliness. The part that made it unusable was browser fragmentation. But, you no longer have to write ridiculously complicated switch-riddled code because of better browser support, standardization and libraries that do it for you.

[rdtsc]

True browser fragmentation was a big problem and however I still don't remember (maybe I was just not aware) of anyone praising the language itself. That is sort of the argument -- it is a beautiful and great language. So regardless of implementation those qualities should have been there.

[michaelmior]

I'm confused about the no sockets (WebSockets) and no threads (Web workers) points. These standards may be immature, but they do exist.

[williamcotton]

There is a world of interesting opportunities available in an ecosystem where code is pushed, interpreted, and executed on the client.

For example, when I'm working with audio software I frequently use VST audio plugins in my projects. Unfortunately, my projects aren't very portable because they require the same plugins to be installed on another machine in order to open that project. When you can't control the dependencies that may or may not exist on someone's machine, you have a really annoying ecosystem. Most professional software environments suffer from this.

If instead, my DAW software was running based completely on sandboxed code executed locally but being served up remotely, then I can move from machine to machine effortlessly and collaborate incredibly easily with other producers and musicians. Of course, this is not the only use case.

Also, the browser and JavaScript don't HAVE to be the way forward, but there is a massive amount of momentum and very few competitors with any sort of traction.

Also, read up, son: Websockets, Web Workers, CORS, WebGL, Web Audio API, WebRTC, MediaStream API, DataStream API.

The approach is to maintain the sandbox and therefore allow arbitrary code to be run while increasing the number of hardware accelerated interfaces to the machine.

[jrabone]

If instead, my DAW software was running based completely on sandboxed code executed locally but being served up remotely, then I can move from machine to machine effortlessly and collaborate incredibly easily with other producers and musicians. Of course, this is not the only use case.

But isn't that really licensing requirements, rather than technical requirements? Or the 20+GB sample libraries that things like Superior Drummer haul around? I don't see how you could remote-serve that kind of content, any more than you could, say, Skyrim. Now, remote rendering MIDI data and streaming back the audio might work, but I use many VST plugins as real-time processors (amp sims etc.) Knowing how much effort I've sunk into optimising everything on this computer for real-time playable latencies without glitching, I'm having a hard time believing that the Web Audio API is going to cut it for my use case, unless it's basically just ASIO. There simply isn't much opportunity for any buffering at 5ms latency, so that "sandbox" might end up sharing memory rather a lot...

[kcbanner]

Sockets exist, work, and are used by lots of people.

[Ryan_Shmotkin]

And work on all browser for all people.

Or wait.. they don't for most

http://caniuse.com/websockets

[mikeryan]

Pretty much every modern websockets Javascript library you use these days will provide fallback mechanisms to flash or long polling to provide the same features. Take a look at the supported browsers for Socket.io and its a much larger list then the one you've provided.

http://socket.io/#browser-support

[flatline3]

They're not sockets, they're WebSockets, and they require a custom HTTP server setup just to open a socket connection to a service.

This means that I can't do something that should be really simple -- like open a VNC connection to a remote server -- without first configuring an HTTP WebSocket proxy.