6 ms·

Issues I have with HTML5: - Javascript - Javascript - Javascript - Fragmentation like no other - Lack of APIs - Sandboxed environment - A bunch of morons

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.

michaelmior 14y ago
I'm confused about the no sockets (WebSockets) and no threads (Web workers) points. These standards may be immature, but they do exist.
kcbanner 14y ago
Sockets exist, work, and are used by lots of people.
- Ryan_Shmotkin 14y ago
  And work on all browser for all people. Or wait.. they don't for most http://caniuse.com/websockets http://caniuse.com/websockets
  - mikeryan 14y ago
    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 http://socket.io/#browser-support
- flatline3 14y ago
  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.
amix 14y ago
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 14y ago
  The story of the web up until now: It sucks because browser X doesn't support technology Y correctly.
- randomdata 14y ago
  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.
williamcotton 14y ago
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 14y ago
  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...
user24 14y ago
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 14y ago
  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".
  - rlf 14y ago
    Oh, c'mon. JavaScript is a shit language that's been foisted on us. I don't know anyone that truly likes it. Rather they say they like it because it's the only game in town. But syntactically, it's ugly as hell.
  - user24 14y ago
    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.

michaelmior 14y ago

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

kcbanner 14y ago

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

Ryan_Shmotkin 14y ago
And work on all browser for all people. Or wait.. they don't for most http://caniuse.com/websockets http://caniuse.com/websockets
- mikeryan 14y ago
  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 http://socket.io/#browser-support
flatline3 14y ago
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.

amix 14y ago

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 14y ago
The story of the web up until now: It sucks because browser X doesn't support technology Y correctly.
randomdata 14y ago
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.

williamcotton 14y ago

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 14y ago
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...

user24 14y ago

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 14y ago
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".
- rlf 14y ago
  Oh, c'mon. JavaScript is a shit language that's been foisted on us. I don't know anyone that truly likes it. Rather they say they like it because it's the only game in town. But syntactically, it's ugly as hell.
- user24 14y ago
  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.