Firefox has a SpiderMonkey javascript engine. Chrome has V8 javascript engine.
Obviously those engines are a separate products and browsers utilize some kind of interface API to interact with them.
On the other hand programmers longed for a long time for their favorite language in browser. So much so, that we have products like GWT (for java), parenscript (for common lisp), HJScript (for haskell), and i'm sure many other libraries for many other languages that allow programmers stay with their favorite language and generate client side code as well.
The idea is so obvious that i am surprised that there's no implementation of it yet. Why not publish the interface API of browser to language engine and allow web sites to provide custom language engines as downloadable bundles. With current internet speeds 3-4 megabytes one time download is not a problem for majority of applications, even more so for intranet usage.
So where's our pluggable engines ?
You don't need pluggable engines really, just an agreed upon byte-code format. Google is going down that path now with NaCl and PNaCl which is based on LLVM. So any program that compiled down to a safe subset of LLVM byte-code could be run in the browser.
Browser vendors can't even agree on a common video format (see the html5 <video> debate) or on how the document DOM object should look like, and you want them to agree on a whole language interface?
Good luck.
I guess you forgot about applets and embed's. Both offer exactly what you want. And both suck for the very same reason.
We've been down this route in the past.
Older versions of IE supported VBScript as a scripting language in addition to JScript.
The result was a whole load of sites that only worked in IE.
This isn't what the web needs again. As a developer, I may desperately want to write code using my favourite language, but as a user I want to be able to browse all sites on the web without having to worry about which plug-ins I need for any given site, or whether my preferred browser can even use those plug-ins.
This is the problem that Microsoft's Silverlight has had. It might be a marvellous technology, but to the end user, why do I want another plug-in? Silverlight has managed to gain some market share thanks to the sheer power of Microsoft, but really not that much.
Now, if the code reaching the end user is consistent, regardless of the language it's written in, then the language doesn't matter. But this effectively means compiled code (or at least bytecode), which is a whole different kettle of fish to running a scripting language in the browser.
Related
Instead of having V8 compile JavaScript on the fly and then execute it, isn't it possible to just compile the JavaScript beforehand and then embed the machine code in the page instead of embedding JavaScript in the page?
There are two main problems with shipping machine code on the web:
Portability. No server can afford providing appropriate machine code for all possible system architectures out there (present and future). E.g., V8 already supports 10 different CPU architectures.
Security. No client can afford to run random machine code on their machine without knowing if it can be trusted.
To address (1) you'd generally need to cross-compile machine code, which is more difficult and costly than compiling down from a high-level language. To address (2), you'd need to validate the machine code you receive, which is more difficult and costly than compiling a high-level language.
Machine code also tends to be much larger than high-level code, so there is a bandwidth issue as well.
Now, JavaScript may not be a particularly great choice of high-level language. But it is what we are stuck with as the language of the web.
The way I understand it, the V8 JavaScript engine compiles to machine code anyway so why not just do it beforehand?
According to the W3C HTML5 Scripting specification, there's no standards-based reason why a browser couldn't support machine code with special type attributes (as Chrome does with the Dart language):
The following lists the MIME type strings that user agents must recognize, and the languages to which they refer:
"application/ecmascript"
"application/javascript"
...
User agents may support other MIME types for other languages...
Currently, no browser has implemented such a feature.
I suspect the primary shortcoming of such an approach is that each chip architecture would require a machine-code version of the script compiled for it specifically. This means that in order to support three architectures, a page would need to include a compiled script three times. (And it should be included a fourth time, as plain JavaScript, as a fallback for architectures that you didn't include, or for browsers that can't/don't support compiled code.) This could significantly bloat the size of the page with data that is mostly useless. The increase in load time would seem to significantly offset or completely outweigh whatever time you save on compilation.
An architecture-independent compromise solution like bytecode seems pretty poor: you still need to include the script twice (once for the bytecode, once normally for scripts that don't support it) and you need to do some kind of run-time processing on the bytecode to turn it into machine code.
The multiple-includes-with-fallback problem is exactly why other scripting languages have not made it into the Web environment: they would need coordinated cross-vendor support to be useful. Google is trying with Dart, but it remain to be seen what degree of success they see.
Note that Chrome does cache compiled versions of scripts so a script only needs to be compiled once and then the compiled code is cached for reuse when the user re-visits the page.
Is JavaScript the only language that can be run on the client side in a browser for client side scripting like DOM manipulation? I think VBS used to be available in older versions of internet explorer, but is no longer available?
With about a zillion server side languages, I have only really seen JavaScript on the client side. Sorry if this is a dumb question, but is it possible to use any other scripting language for client code? Do any browsers natively (or at least reasonably) allow for scripting in another language, or accessing the DOM directly in some other way? I am aware of using clever CSS3 for things like nested menu items, so not that.
More than JS or no JS, it's the HTML(5) and ECMAScript spec that matters. It really depends on browser to implement the specs. For example Google uses V8 for JS processing. For local storage Google and MS uses IndexedDB (for html5) while others uses different client db (like FF and Safari-SQL Lite - I think).
Not sure about VBS in IE anymore but it's not supported in any other browser anyway. And IE is sort of very much behind the curve.
JS is now de-facto standard in browser world and gaining popularity even in Server side with the help of node.js ...
To be more specific - there are other languages available for browsers and multiple efforts took place (and going on) to present a logical substitute for JS. Example - VBS, PERL, TCL, Python plugin in FF etc - but none became a viable option against JS (especially with multiple JS frameworks showing up almost everyday).
Other approach was Flex / Silverlight type environment which essentially provide a viewport on top of browser to overcome limitations of HTML. But with present HTML5 specification, the trend is reverse now - all are flocking around HTML5 and JS.
VBScript is supported by Internet Explorer. You can use ActionScript and Java Applet at the client side too.
It doesn't take long when surfing the web to observe the general consensus that Flash is an expected standard, that it's okay to say "If you don't have Flash, my website won't work." Yet in the same regard, JavaScript is expected to degrade peacefully if the user does not have it enabled.
I personally favor the "HTML5" approach, in opposition to Flash, due to the poor performance Flash brings to Mac OS X and Linux
The overall outlook of the Flash way vs. the JavaScript way seems like the biggest challenge to me in Steve Job's prediction of HTML5 overtaking Flash, and I personally haven't seen any sign of change.
Am I missing something?
HTML5 will probably not kill Flash. Although I'm an Actionscript 3 developer, I have little love for Adobe and if anyone is going to kill Flash, I believe it will be Adobe themselves by failing to adapt.
Web standards are great but inevitably changes take for ever.Solutions developed by smaller entities can implement changes and adapt faster. Look at how JQuery changed the perception of Javascript. Most people have already forgotten that until recently there was very little love for Javascript, which is probably where the degrade gracefully attitude comes from.
The consensus is now to complain about Flash , the real shame is what Adobe has done with it , or more to the point hasn't done to improve it. I agree with Steve Jobs on that one, Adobe are either lazy or misguided. In any case totally inefficient.
In my view there's nothing wrong with a plugin, provided it works as expected and with a penetration above 90% , Flash has/had the potential to become a standard itself... in another world that is.
You're talking about almost entirely different groups of people with very different worldviews. That's why they say two different things. Very few people are both gung-ho Flash fanatics and slavish adherents to progressive enhancement.
For the people who support Javascript, one of the big reasons many do so is that it's an open standard with free implementations that is accessible to anybody, not just those favored by Adobe. This feeling that Web content should be available to everybody on the Web also makes them hostile to Javascript that takes the same "My way or the highway" stance that led them to reject Flash.
It's not OK to say either of those, in the general case. However for some it's acceptable to give up on having a working site for some percentage of users.
It depends on the kind of project you are developing for.
It's only safe to assume the user will be able do interact only with the HTML (that's why it's a good idea to hijax your form instead of assuming the user will be able to run your ajax function)
As for FLASH I aways assume it will be unavailable to a small be considerable group of users (iphone, and ipad user won't be able to interact with your flash)
So basically, when developing a portal I assume that:
The user browser will be able to
display HTML
There's a great probability that the user's browser will be able to interpret javascript
There's a considerably smaller probability that the user will have the flash plugin
My rule of thumb is: If you have to have flash at all use it for non-important stuff. All important stuff should be able to work fine with just HTML
The reason is because Flash has a penetration of around 99% of all internet connected computers, and acts exactly the same across the board. Flash has many features which are not replaceable (until very recently, thanks to HTML5 and better JavaScript implementations) While JavaScript implementations are all incomplete as well as varying in between browsers.
I'm not a flash developer, but I'm guessing there would be different methodologies too. The whole mantra of modern web development is a sort of additive synthesis, so you start with something basic, then work up from there, building up features as you go along.
The real reason is that if you use flash on your website, you probably don't give a toss about things like accessibility and other minor concerns.
JavaScript developers are also much nicer people.
Typically JavaScript is used to support basic but important operations, and being important goes hand in hand with high usage frequency, large audience, possibly business critical. Thus it is important that they require "peaceful degradation".
Flash tends to be used for splashy stuff, like games, heavy UI apps (like paint style programs). These tend to be less important and so less reason for them to degrade peacefully.
For example, I can see the Flash part of Google's analytics site making way for HTML5 in the future. It is suited to it. But something like Google's street view I see no real reason to go down the HTML5 route for it (although I suspect they still might).
Are there any libraries or frameworks that provide the functionality of a browser, but do not need to actually render physically onto the screen?
I want to automate navigation on web pages (Mechanize does this, for example), but I want the full browser experience, including Javascript. Thus, I'd like to have a virtual browser of some sort, that I can use to "click on links" programmatically, have DOM elements and JS scripts render within it, and manipulate these elements.
Solution preferably in Python, but I can manage others.
PhantomJS and PyPhantomJS are what I use for tasks like these.
What it is, is a headless WebKit based browser which is fully controllable via JavaScript. There's a C++ implementation (PhantomJS) and a Python one (PyPhantomJS). I prefer the Python one though, because it has a plugin system which allows you to add functionality to the core without actually modifying any code, unlike the C++ one. :)
There is an absolute ton of free software technology now available: take your pick at http://wiki.python.org/moin/WebBrowserProgramming but if you have specific questions join pyjamas-dev on google groups and i'll be happy to give further details, there. brief answer: you can run pywebkitgtk "headless", or you can use xulrunner (via python-hulahop) again using pygtk without actually doing "browserwidget.show()", and there's also pykhtml. also you could use python COM to connect to MSHTML.DLL.
these are all "cheat" methods: using python bindings to a graphical web browser engine without actually firing up the graphical bit. if you really wanted to put some serious hard-core programming in, you could create a "port" of webkit which was not connected to a GUI toolkit: as an experienced webkit programmer i'd put it as around... 2 weeks of full-time effort to make such a "headless" version of webkit.
l.
Looks like http://watin.sourceforge.net/ might be a good way to go.
If you don't have to go pure Python, you could do IronPython since it's a C# project.
take a look at this little doosy on ajaxian
http://ajaxian.com/archives/server-side-rendering-with-yui-on-node-js
It also talks about Aptana Jaxer which I think runs on a headless firefox so is basically the Mozilla browser engine in all it's glory.
There is Kapow. Its pure Java and costs money:
http://kapowtech.com/
And there is Lixto: Its Eclipse based and uses Mozilla Gecko as rendering engine (unless they already changed it to WebKit, as they said they'll do years ago). Its very nice and also costs money:
http://www.lixto.com/?page_id=50
They are both graphical tools where you define the site navigation and what should be extracted by point and click. But you can also write xpath and regular expressions and even JavaScript that runs in the sites context.
I used them both in the lectures web data extraction and applied web data extraction at the technical university Vienna (Lixto is written by the Professor who held the lecture).
HTMLUnit in Java is very good. I think it's only the Java implementations of headless browsers that manage to provide Javascript support.
MaxQ, I read about here, sounds like it might be interesting: "written in Java, generates Jython scripts"
Try HtmlUnit !!!
Take a look at http://www.chromeexperiments.com/
I think JavaScript is very close to have everything that RIAs can offer.
What's missing from or for JavaScript to make it a viable RIA development alternative?
At the moment the only thing you really can't do in javascript/html is sound and video. This is changing with the HTML5 standards which includes sound and video as first class html elements.
The other thing Flash has going for it is a (slightly) more level ground between browsers. All browsers implement things slightly differently but a flash page renders pretty much the same across all.
Eventually (even now maybe) you will be able to do everything flash can in the browsers, the only question will be if and when all browsers support what you need.
While chromeexperiments.com has many neat technology demos, and I especially like some of the games there, it's still very much far off compared to what's being done with Adobe Flash/Air and Microsoft Silverlight.
I'm a long time web developer and I experienced the pain with browser in the early days, where none of the browsers cared much about standards. Today, it's very different. Not only do we have a lot more browsers, there are small incompatabilities in all of them which in some cases can be problematic. Normally applies when you're doing a pixel-perfect design, which you shouldn't do anyway ;-)
One of Silverlight (and WPFs) promisses are separation of concerns when it comes to delegating work between the developers and designers. While the tooling is not yet optimal, it's improving in every release of Visual Studio and Expression Blend. Being able to actually see what you're doing in a designer is helpful for a designer.
I have traditionally been a pro-web, it's more compatible, works everywhere, standards based and just the decent way to do things. It's only when you have benefits towards alternatives you should pick them, but normally they should be additions to an existing implementation built on web, this applies particulary to information systems, line of business, etc.
You don't want to get tied down to a specific version of a runtime or viewer, that will get us back to the problems we have today with far too many web-systems only compatible with Internet Explorer 6.0. It's a nightmare in many organizations today, their IT-systems doesn't work with anything other than IE6 so they are stuck, without any means of upgrading expect when they can afford replacing the existing systems.
If you develop a solution today, will your users be able to use it 3 years from now? What about 5 years? 10 years? Will they require a special-purpose-PC-setup that sits in the corner, running an old version of the OS and RIA/Viewer runtime? Sort of like how the IT-systems of the police runs all around the globe.
One project I'm currently working on (hobby-project) I initially started out with a desktop application, using Windows Forms and SQL Server Compact Edition for local storage. Then I figured I wanted to be more available to users, so I changed my plans to be an ASP.NET MVC project. Later on, I realized that it was about time to get more experience with Silverlight, so I ended up doing the whole thing with Silverlight 4 and Windows Azure. I'm amazed how productive you can be with Silverlight, though there is a pretty steep learning curve for someone who's traditionally built Windows Forms and Web Forms solutions.
What is missing from the HTML+JS technologies? Tools & Frameworks! One of the most important things for any developers is familiarities between projects. There shouldn't be a difference in the tools and frameworks you use if you want to develop a 3D game, Line-Of-Business Application or an interactive web banner. Reduced development time is another critical point, today's AJAX frameworks is way better than what we had to write ourselves back when XmlHttp first arrived with IE, so we're slowly getting to some place where we can do really cool RIA-solutions with nothing but web-technologies. I think HTML 5 is the beginning of something good, though it's still pretty far off compared to what we have today with Flash and Silverlight.
There is an adage that "anything that can be done in javascript, will eventually be done in javascript". Certainly, lack of a good designer for this sort of interactive app is one problem. It's important to note that javascript is just a scripting language, where silverlight and flash are frameworks that each include their own programming language. In fact, Silverlight 1.0 used javascript as it's language. So the real question is whether HTML+javascript will get to a point that Silverlight and Flash are not needed. I could see that happening in the post-HTML-5 timeframe, but that will be a while.
I don't think we are close to knowing the answer to this yet.
Personally I could argue either side pretty equally.
Javascript:
Pro - Almost universal. Newer phones even support it.
Con - Can be hard to manage. Still varies from browser to browser to some extent.
RIA:
Pro - Typically richer tools/better management.
Con - Not as close to universal. Flash is very widely deployed and Silverlight is gaining ground. More control for developer (I'm thinking of games, etc.)
Bottom line: either approach can be made to work. Each has strengths. Each has weaknesses. I don't expect a clear winner for a long time, since both sides will have proponents who won't want to switch camps.
Yes, of course.
jQuery+HTML5 makes it easy. jQ has animations, AJAX, keyboard and other stuff. HTML5 has canvas, audio and video. What else you need?
I think that there needs to be greater uniformity of the performance of JS engines across browsers. The cool things on chrome experiments are made possible by the super-fast performance of V8, the JS engine in Chrome. These things are not so exciting in many other browsers.
The advantage that is held by Flash/Silverlight is that they are browser extensions that do their work closer to the actual computer and are thus less constrained by the characteristics of the browser.
JS applications will be limited until all browsers have performance approximately the same as Chrome's.
I'm currently writing my first real application in Flash (Flex, actually) but it's only because i needed to have complex imagery from PDF, and PDF2SWF works much better than PDF2SVG.
so, in this particular case, it wasn't about the platform capabilities (neither of them could handle PDF), but about an accessory tool (transforming PDF to a usable vector format)
The benefit of Silverlight is that, with Silverlight 4, the same code base can be used to create a web hosted application and a full trust desktop application*. This is of great benefit to designers of Enterprise applications where the user must be constrained (to a certain extent) in what they can do and how they interact with the application.
So what you might see is that consumer websites go down the Javascript route, while Enterprise applications stick with Silverlight and Flash.
* I don't know about Flash and Adobe Air, but I would suspect that Adobe are working on this too.