In the field of RIAs, I've read tons of comments stated that the discussion about Silverlight vs JavaFX vs Flash vs HTML5 is outdated and the winner is HTML5.
Since I am a programmer (not a designer) but never used any of the technologies above and I have no time to learn all of them to compare, I want to ask the following:
1) With HTML5 we continue to only have interpreted JavaScript, or we can use more powerful languages that generates compiled code (some kind of MSIL or bytecode inside <object> ... </object> tags)?
2) Does HTML5 hide portions of our code from unwanted viewers (like Java applets and ActiveX did in the past) or the option "View - Source Code" continues to show all of our work?
3) HTML5 need some kind of runtime or all the work is done by the browser?
There is a bit of a fundamental problem with your question in that HTML5 is not really a thing. It's hard to compare it to Java or Flash, which are programming languages. It is possible to create interactive applications using HTML and JavaScript without using any of the features of HTML5. This seems to happen a lot, but for simplicity these are often referred to as HTML5 applications -- especially by non-technical people.
1) I would say that JavaScript can be as powerful as the other compiled languages you talk about even on a webpage -- especially with the power of <canvas>. You have found that HTML5 has won for a reason. In my opinion, it can do what the others can do and is simpler to implement.
There is nothing that forbids you from including Flash objects of Applets alongside JavaScript, though, and they can even interact.
2) There is nothing that prevents all of your HTML/JavaScript from being downloaded in the browser and viewed in plain text, although it can be obfuscated with tools such as Uglify.
It's also possible to download and decompile swfs and jars from a web interface, so compiling does not necessarily offer you a lot of protection anyway. Your code would be protected by Copyright (at least in the US) and you could use a license the MIT license too.
3) All the work is done by the browser. The client will only need a browser to run your code, but some browsers do not support some features you may want to use. This especially applies to older browsers.
There are a ton of frameworks and libraries out there for creating rich HTML/JavaScript applications, but these are just are mostly just JavaScript files.
HTML5 is a brand and trend. In silverlight/flash/html battle HTML must be the winner. Because browsers can't progress fragmentary. Is it true then some part of features developing in browser plugins, some part in browsers. For strong and fast progress always, at the start, needs the vector. In redefining web in our life such vector is HTML5. HTML5 is not a language, it is the set of capabilities, such video, music, webgl, geolocation, semantic essences and more and more only from browser. And we can't speek here about HTML5 like a language.
All your questions are about javascript.
Want bytecode inside <object> ... </object>? Use Chrome Native Client.
Want to hide your code? Use any obfuscator.
Modern javascript engines has just-in-time compilation. And there is the "subset" of javascript like asm.js which is just 2x slower then C++.
Related
I want to make an application for J2ME phones.
In that application I want to use HTML5,
how I can do this?
I worked on LWUIT. Does LWUIT support HTML5?
Or give me any other browser info.
LWUIT/Codename One support HTML5 but not on J2ME.
There's no built-in HTML5 (or any HTML version, for that matter) parser or renderer in J2ME. There's some sort of HTML viewer support in the LWUIT library, but I suspect it is reasonably limited in general, and also in particular regarding specifically HTML5 support. In any case, research LWUIT and see if it is enough for your needs or not (hard to say without knowing your real/actual requirements).
It is also not very practical to write your own HTML parser and renderer (especially if you also need to be able to handle CSS and JavaScript). In essence, you'd have to write your own complete web browser in J2ME.
You can, of course, use platformRequest() to launch the default browser, but not that many mobile phones have HTML5 support yet.
If you also manage the server-side (where the HTML5 pages come from), and all you really need is the data, then write the server code to return/send the data to your J2ME MIDlet as either XML or JSON, which are much easier to handle.
The codebases for modern web browsers like Chrome, Firefox, and Safari (WebKit) are quite large. I am curious about what specifically makes their implementations so non-trivial that they require vast amounts of code.
As a corollary question, if a hypothetical browser only supported strict HTML5 and JavaScript, to avoid compatibility hacks, would the codebase be significantly smaller?
For your first question, consider the things a modern browser needs to implement (some browsers push some of this work out to operating system services):
Several parsers: XML, HTML, JavaScript, CSS, at least.
At least four separate layout systems (CSS box model, flexbox, SVG, MathML).
At least one graphics library; for cross-platform browsers this needs per-platform backends (IE9+ just uses the system Direct2D library; Safari on Mac just uses Quartz as far as I know).
A high-performance virtual machine with a JIT, a garbage collector, a bit of a standard library (growing all the time; see typed arrays and various other recent JavaScript features).
A DOM implementation, including various things like the HTML-specific and SVG-specific DOM interfaces and so forth.
Audio and video processing facilities (again Safari on Mac and IE offload these to the operating system).
Image processing facilities, with support for at least JPG/GIF/PNG. Again, some browsers may be able to offload parts of this to the operating system.
A library for converting byte streams to Unicode characters. Again, sometimes this can be offloaded to the operating system and sometimes not.
For cross-platform browsers, some sort of portability layer that abstracts away the platform-specific bits.
An HTML editor with transactions and a programmable API; think contenteditable.
A plaintext editor for textareas. Some of this can be shared with the HTML editor, maybe.
A spellchecker, which may or may not be offloaded to the OS.
A network library supporting HTTP, maybe SPDY, probably FTP, and maybe a few other protocols. Again, this may or may not be offloaded to the OS.
A cryptographic library to handle SSL and various other cryptography needs. Again, this may or may not be offloaded to the OS.
At least one database implementation (sqlite seems to be popular).
Various code for the actual user interface and whatnot.
Glue code to handle interactions between all these: code that manages calls back and forth between JavaScript and the DOM, code that manages recomputing style and layout information when the DOM changes, code that handles things like document.write injecting strings from JavaScript into the parser's input stream, and so forth. Note that the amount of glue code is generally quadratic in the number of interacting modules.
I'm probably missing a few things, but that's off the top of my head.
In addition to this at least Gecko and WebKit have template libraries for things like strings and arrays (because the C++ standard library ones have various drawbacks).
For the rest... at this point a lot of the "compatibility hacks" are actually part of web standards. So you can't exactly avoid them. Your scenario talks about JavaScript and HTML but not SVG or MathML or CSS. If you really just mean HTML and JavaScript but not CSS or the rest, then you could obviously cut out a bunch of code. If you include all of those, plus the audio and video capabilities of HTML5 and want your browser to perform well, then I doubt you can make it much smaller.
I think modern web browsers are complicated apps. Mainly, they have rendering engines which have to handle different kinds of HTML, ability to deal with not HTML formats (like XML, RSS etc.), CSS handlers, Javascript engines sometimes with a JIT.
Apart from that, they have plugin architectures and APIs, parts to abstract differences between platforms and are usually built using components that other apps use.
This makes them quite non-trivial. As for your collorary, I think so. Lynx is quite small and doesn't support Javascript or fancy HTML.
I know very little HTML or web dev, but I would like to write an
HTML5 app with a fairly complex UI. Is there a framework that stands
out among the rest for this type of job? Do I need a framework; or can
I just do everything in straight HTML+CSS+JS? And what about GWT?
Thanks!
As a general HTML5 starting template, Boilerplate is always a good choice.
It will optimize and chain all your scripts and CSS files, as well as your HTML code and images, it also comes with useful tools like Modernizr.
If you are looking for JavaScript libraries, YUI is a very good library when it comes to UI, though maybe a little more complicated than jQuery or jQuery UI at first. I found it better than jQuery UI, and can work together with jQuery anyway.
EDIT
You may also be interested in Ext JS. Looking at the demo it provides, seems really like a powerful library with many ready to use UI widgets. Never used it though, and looks like it only offers a commercial license.
I suggest you to use Html5-boilerplate.
Download from github
Video Tutorials from author :
http://www.youtube.com/watch?v=qyM37XKkmKQ
http://www.youtube.com/watch?v=OXpCB3U_4Ig
GWT is a good way to go for a complex web application, particularly if you're familiar with java but not javascript. GWT now provides support for HTML5 features such as offline storage, canvas, audio, and video, although it's possible to use any HTML5 features whether GWT provides specific Java classes to support them or not (I implemented the offline storage feature in one of my apps before it was part of GWT). Using GWT will mitigate many of the browser compatibility problems you will encounter with straight HTML+CSS+JS. Although you write in Java, it's still important to be familiar with HTML, CSS and JS, since the java is compiled to js.
How many client-side scripting language implementations did you see except JavaScript and VBScript? Like: type="text/C++Script", text/CSharpScript, text/oberonScript, etc.
How can I learn if my browser supports those languages?
The only languages I have ever seen supported by web browsers in <script> elements are:
JavaScript / JScript (which is ubiquitous)
Webassembly (which is less of a language than a different target other languages can be compiled to) is well supported today)
VBScript (IE 10 and lower only)
PerlScript (IE with a plugin from ActiveState only)
Dart (in a nonstandard build of Chromium) which is not intended for production use.
The HTML 4 specification gives examples of Tcl, but I've never heard of a browser that implemented this.
In any practical sense (for WWW development), JavaScript and Webassembly is the only (not really a) choice.
There are also various languages (e.g. Dart, TypeScript, ES6/7) which have translators to convert programs to (ES5 flavoured) JavaScript which can then run in browsers.
Is already answered above.
If you want to learn if browser supports languages that you already know the best is to embed their small snippets into page or inject using innerHTML from JavaScript. These scripts should then set some global property like window['scripts']['oberon']=true; this way you will learn that language type was detected indeed.
Why HTML/JavaScript/CSS are not becoming compiled languages (or maybe even merge into a single compiled language)? What if browsers were running "Browser Virtual Machine" and html/javascript/css sources could by compiled to a "browser bytecode". Wouldn't it help developers and users a lot?
I can see a few challenges:
What to do with zillions of existing pages? Make this compilation optional, so if you want you can use plain old html. If you want to feed a browser with a compiled page just use .chtml for example.
How search providers would index pages? Make a decompiler that would decompile bytecode into exact original sources (for example like flash can be decompiled). Or search providers can use the same virtual machine and get data they need from there.
How to make it compatible with all browsers? Have one centralized developer (lets say w3c) to develop this virtual machine and then each browser would embed it.
But what about benefits:
Speed.
Size.
No more "loose" and "half-correct" html. It is either correct or won't compile.
Looks the same in every (supported) browser.
If not a bytecode then at least have some native compression going on, html probably is not the most efficient way of data storing. I know there is gzip but why to compress pages every time on a server and decompress in a browser if we can compress it once and feed it to a browser?
So what stops us from taking this road (well, besides a huge amount of effort to make it all happen)?
Ah, but Javascript IS becoming a compiled language. Check out Firefox 3.5 with TraceMonkey. It's insanely fast compared to um you-know-who's browser. It's true that JS will never be C, but it's a much more dynamic language than C is, and in many ways that makes it more expressive and powerful.
As far as HTML goes, I don't think that the lack of validity of HTML is a huge detriment to speed. I think the engines that put together the visual representation and manipulate the DOM need to get a lot better (um, IE, I'm looking in your general direction...). CSS compliance needs to get better, and CSS itself needs to get more powerful. (Get on the bus with CSS 3 people!)
But I do think that speed is going to get better on Firefox and Chrome to such an extent that people really ARE going to start using it for mainstream application development. It's funny. Adobe seems to be selling Flash as their platform for dynamic web content, MSFT is selling Silverlight for dynamic web content, and Google just wants to really improve HTML and Javascript to display dynamic web content. And Google's doing pretty well at it so far, I must say...
Your ideas have validity when they are applied to JavaScript. As others have noted, to one degree or another several vendors are trying to apply those principles to JS even now. Another big step in this area will likely be the Chrome OS Google has announced. However, when it comes to (X)HTML and CSS I think your ideas may be missing the point.
The world wide web is not a buggy and inconsistent application platform but a massive and unprecedented collection of interconnected documents. The power of the web is in the abstraction of the data from the often rigid (and breakable) visual layouts and increasingly complex in-page functionality largely provided via JavaScript. Encoding these pages in (X)HTML is ideal for making them accessible to the widest possible audience both in terms of browsers and in terms of technical knowledge required to author a page.
More and more the web is being used as an application platform - which is a powerful and exciting use of this technology - but we cannot lose sight of the fact that these Ajax-driven "web 2.0" apps are merely documents with extended functionality. Compilation doesn't make sense for a document and compression is already happening (via gzip and the like).
On a more practical note, the W3C moves at a glacier's pace and browser vendors take turns between jumping-the-gun supporting experimental features in unfinished specs and taking their sweet time supporting other specs which have been on the table and in common usage for years. The whole processes is like herding cats. I wouldn't hold my breath for them to make the kind of radical changes you're proposing any time soon.
Since HTML and CSS aren't code they can't be compiled. Google Chrome's V8 engine does actually convert JS into byte code, expect other rendering engines to follow suit!
http://code.google.com/apis/v8/design.html
We recently reworked a php template system I've helped create to use minify to compress multiple JS and CSS into one file each, seeing our file sizes drop to about 20% of the origial combined sizes. Minify also does gzip and caching so it's really amazing for speeding up websites.
http://code.google.com/p/minify/
In short you can't compile non-code, which HTML and CSS are. JS can be compiled and is starting to be, but all depends on what browsers feel like doing.
Browsers just need to be on the ball regarding supporting web standards. The more browsers do this, the less headache us web developers have. I was quite happy with YouTube's very public drop of support for IE6. We need more action like that for the web to move forward.
The V8 javascript engine (also embedded in Google Chrome, but it's open-source and liberally licensed so you're welcome to use it in the next browser you write!) does compile Javascript to native machine code -- of course, it does it "just in time" (like most modern compilers -- Java, C#, etc!), not "ahead of time" (like Fortran did in 1954 when computers were just too weak to handle compilation in the midst of execution). I'd be surprised if other good JS engines, like those in the very latest Firefox and Safari, didn't do the same.
Looks like you're not advocating "javascript as a compiled language" (since it obviously already IS compiled, if you're using a good JS engine), but rather "ahead-of-time" compilation for it (just when most modern languages are essentially abandoning ahead-of-time compilation). Pushing machine code rather than compilable code down the wire sounds like a mostly horrible idea -- much larger size, difficulties in supporting one CPU vs another, security nightmares in properly sandboxing it, etc, etc) with not much in term of compensating benefits.
That said, if you're really keen on pushing machine code to the client, try out nativeclient (as long as the client is an x86 machine - forget every smart phone on the planet, many netbooks, good old macs, etc) -- at least it promises a fix to the security nightmares. If and when you're happy with nativeclient, transforming a just-in-time compiler into an ahead-of-time one is a far easier technical challenge (if you want to keep using Javascript for the sources rather than other languages, of course).
See here for a previous discussion on the matter
Not all of the reasons given are necessarily valid, but one important one is that, unless you're Google, server-side CPU cycles are a lot more valuable than client-side cycles: so it's easier to have the client compile/optimize what is quite often dynamically generated HTML/JavaScript, rather than the server.
Ken
Speed.
You're assuming that it takes significant time to parse HTML. However it might be that that time is insignificant compared to the time required for something else, e.g. the time required to layout the text on the end-user's window.
No more "loose" and "half-correct" html. It is either correct or won't compile.
You already get that, using [X]HTML.
Looks the same in every (supported) browser.
You seem to be saying that there should only be one browser, or that all browsers would support it equally.
Internet standards don't happen by having a single body (the w3c) implementing something and declaring it a standard. Instead, internet standards happen by having multiple independent bodies creating multiple implementations. A consequence is:
Some people have developed something that isn't standard yet (i.e. they're ahead of the standard)
Some people haven't yet developed something that is standard (i.e. they're behind of the standard)
I think your idea is sound, however there's still no way to enforce a standard. Thus if there was a non-supported feature, there's a good chance the entire page would simply not display anything. In the current setup, critical information can still be passed.
Google V8, which is one of many new-generation javascript engines 'compiles' javascript into pseudocode, much like .NET 'compiles' c# on the fly. Nothing magical here. Expect more of it esp. as webapps get heavier and more demanding
HTML
HTML is pretty much XML. DTD'd exist for various versions and developers can check against that at any time.
CSS
CSS is not a programming language, however I do agree that "compiled" CSS could work seeing as compilation would compress it. However with the support that CSS has and with the number of essential hacks any CSS needs to have, you'd never manage to compile it without errors.
JS
As others have mentioned, JS IS becoming a compiled language except the browser compiles it for you and not you yourself.