Hacker News new | past | comments | ask | show | jobs | submit login
The Most Important Parts of HTML5 (n01se.net)
39 points by falava on Aug 11, 2012 | hide | past | favorite | 36 comments



1. Faster Javascript Engines

2. WebSockets

3. Binary Data Types (Typed Arrays and Blobs)

4. Web Audio API

5. Canvas 2D Context

6. CSS3 and WOFF

7. Local Storage, Offline Applications and the File APIs

8. Web Workers

9. SVG 1.1/2.0

10. WebGL

11. All the Rest


A second-system replacement for the <audio> tag is more important than being able to render graphics or store data locally? Questionable ranking.

Decent summary of important stuff in/related to HTML5, though.


> A second-system replacement for the <audio> tag

I don't believe it's intended as a replacement for the <audio> tag. The audio tag exists to embed (pre-existing) recordings and their metadata (e.g. transcripts). The purpose of the audio API is generated sounds (music sequencer & the like) and low-latency sounds (for video games).

While you could probably re-implement <audio> on top of the web audio API, that's not very useful.


Is there a no noise version of this. Trying to read it on mobile device is near impossible (hangover and screaming kid - unrelated - not helping)


Oh wow, that background is painful. Just use a mobilizer link - here is the instapaper version: http://www.instapaper.com/text?u=http%3A%2F%2Fblog.n01se.net...



Cheers


I'm always really surprised when I read posts like these and they don't mention Web Components/Shadow DOM.

The ability to encapsulate markup, style, and behavior into a single unit with a clean API is an enormous improvement. Of all the new HTML5 features, I think Web Components have the highest potential to relieve a huge pain point for developers.

Image an online repository with all kinds of widgets -- range sliders, date-pickers, sortable lists, etc. But instead of a collections of inconsistent jQuery plugins with CSS dependencies, you get a single, self-contained module that can be interacted with as if it were a native DOM node.


> But instead of a collections of inconsistent jQuery plugins with CSS dependencies

You get a collection of inconsistent web components?

> you get a single, self-contained module that can be interacted with as if it were a native DOM node.

Right, because the one thing I always think when I'm using third-party code is "I'd like this thing to be way more opaque, I'd like to have way less control over it, and I definitely don't want to be able to introspect it."


Web Components sounds great but doesn't seem to be supported anywhere. Once people can use them, they will start making lists like this.


Apropos WebGL: Why are web browsers so picky regarding WebGL? There are PCs out there which are perfectly fine running applications like Blender (uses OpenGL for the GUI and everything) but Firefox won't let you use WebGL on it.


Blender is trying its best to work with you; crashes are seen as rare bugs that Blender needs to work around.

Arbitrary web pages can run arbitrary GL commands and if they can cause your GPU drivers to crash (e.g. lock your whole system) than any link you click has the potential of ruining your day.

Unfortunately, nobody's yet figured out how to let a browser only run the pages that don't make it crash.


The dominant factor is not the graphics hardware but the graphics driver. If it has security, stability or conformance issues, it gets blacklisted.

http://www.khronos.org/webgl/wiki/BlacklistsAndWhitelists


Web browsers have a much higher standard of quality here. It's ok if a local app like Blender uses an OpenGL driver that has security exploits - it's a local app and almost always running trusted content. It's also not so bad if Blender crashes rarely due to a buggy GL driver or has rendering glitches because of it.

In a web browser though, you need to be sure of security - you are running arbitrary content from the web - as well as stability and consistency. So WebGL-powered browsers blacklist drivers known to be problematic.

You can override the blacklists if you dare, but it is very dangerous.


This makes WebGL in itself very dangerous, because you have to rely on blacklists/whitelists instead of real security measures.


So lets compare the most important features that HTML5 might bring to what flash offers:

1. Faster Javascript Engines

AS3 in Flash Player 9 (2006) has about the same speed Javascript has now. There are about as many benchmarks showing AS3 beeing faster, then there are the ones showing Javascript beeing faster. Speed seems to be about the same

2. WebSockets

Has been in Flash since 2006

3. Binary Data Types (Typed Arrays and Blobs)

Has been in Flash since 2006

4. Web Audio API

Has been in Flash way longer

5. Canvas 2D Context

Has been in Flash since like forever ago

6. CSS3 and WOFF

Nothing really specific but Flash has most all of that since years

7. Local Storage, Offline Applications and the File APIs

Since 2006/2008

8. Web Workers

Will come with Flash 11.4 soon.

9. SVG 1.1/2.0

Vectors are at the core of Flash

10. WebGL

Stage3D is in Flash since 2011

So just stop hatin Flash and love the browser independent possibilities.


11. A multi-vendor international standard.

In Flash since...never.

12. Runs great on iOS and Android.

In Flash since...never.


#11 could've turned out differently I think, but Adobe dragged their feet too long. They dropped any licensing restrictions on third-party implementations in 2009 along with releasing full specs for the format. After that happened, even woefully underfunded/understaffed projects like GNU Gnash actually made pretty good progress on implementing it. If they had dropped the restrictions earlier and someone with more funding than Gnash (like Apple) had wanted to build a third-party implementation of the spec directly in the browser (rather than as a plugin), I think it would've been possible.

On the other hand, it's possible HTML5 is better thought out technically. I don't have a strong opinion on that. I do think the Adobe approach of "rich internet applications", which was once shunned by the HTML/hypertext community, is winning after all, just not in Adobe's format.


Flash also dropped Linux. Together with Mobile, that makes 2 of my favorite platforms it doesn't support, making it useless.


On the other hand, the flash player has been regularly crashing on me, whether on Windows, OSX, Linux or FreeBSD since.. well.. always. And there has been zero improvement over the years, except for the fact that browser made themselves resistant to these crashes. I don't miss the times when a player crash meant I'd lose my whole browser session.

Features are irrelevant. The problem with flash is that it's painful for the user because it just doesn't work.


Flash has WebSockets?

No. Flash has raw TCP sockets and they are not nice, and unlike WebSockets don't pass through firewalls and proxies well.


You can 100% emulate Websockets in Flash if you wanted, essentially librarys like socket.io use a flash fallback that does that. If you do a flash only game/app you probably just avoid the websocket overhead for faster development and better bandwith.

Raw sockets pass through firewalls and proxies exactly as good as websockets.


Not on corporate/school/etc networks they don't.

And avoiding WS and using normal sockets, god no. So much code for error handling and parsing and so on. Message passing is much nicer.


Flash fails at much more fundamental issues, before these spiffy new features are even relevant.


Like what?


Use the browser search function, middle click links and have it respect your settings, use the browser's spellchecker on a textbox, increasing the text size with reflowing, using screen readers, etc.

(Oh, and anything that Flash technically supports but doesn't do by default unlike HTML/CSS/JS is essentially the same as not having it, since we all know 90% of developers won't care).

Oh, and more recently, use new versions on Linux outside of Chrome: http://news.ycombinator.com/item?id=3780368


> Oh, and more recently, use new versions on Linux outside of Chrome

Or OSX. and use it at all for starters, still pegs my CPU doing trivial shit under OSX, even in Chrome.


Relative positioning. Floats. Fonts (dynamic of course; particularly targeting 9 and below - functional, but pretty buggy). Hardware accelerated transforms.

For games (and certainly banners)? I still think there's long way to go to catch up to Flash, even older Flash. http://news.ycombinator.com/item?id=680284


Like working flawlessly on all operating systems.


In my opinion, being able to code and make things without the use of proprietary software will usually become more popular in the long run. With JS if necessary I can pull up any text editor if I had to and edit any file, with Flash there's a higher gateway to entry and a higher learner curve of sorts. It seems the the crowds will adopt the way of open in the long run. To me HTML5/JS just seems more natural and a prettier way of doing things.


You dont need any proprietary software to code and make flash. Just use the flex compiler and code in any text editor. The flex compiler can do flash apps without flex also and has some pretty nice sintactical sugar things like two way databinding if you want it.


Other than the fact that the only way to test, run, and debug your applications involves using the closed source Flash Player...


> 1. Faster Javascript Engines

> AS3 in Flash Player 9 (2006) has about the same speed Javascript has now. There are about as many benchmarks showing AS3 beeing faster, then there are the ones showing Javascript beeing faster. Speed seems to be about the same

Links to back that up?


thanks for spreading some love for flash. despite being hated on, despite having a terrible IDE and despite being closed source, there are actually quite marvellous things you could do with flash, that you can't even do with javascript today. example: http://www.6minutestomidnight.com/ not saying I would ever write something in flash again, but it really deserves a better reputation.


Shameless plug, for more info on WebSocket, here's a brief intro:

http://websocket.us/


change the background ..




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: