Is there an implementation or emulation of the DOM which is purely javascript?
There is env.js, but that requires Rhino.
There's jsdom, but that requires Node.
Is there a solution that works in most any javascript interpreter, such as v8, without being tied to any particular interpreter or engine? That is, is there any DOM implementation in JS that without any set up or shims can be dropped into a javascript interpreter and just run?
In addition to the ones you have listed, I have heard good things about dom.js. It requires limited ES6 features such as const, WeakMap, and Proxy, so it will work in V8 and SpiderMonkey (Rhino) but not JavaScriptCore, Chakra, or others.
It's hard to guess at exactly what you're trying to do, here, but I'll take a stab at it, just to keep the conversation going:
If you're trying to manipulate a DOM from within a browser, can't you just use Jquery?
If you're trying to get a "headless browser", I'd check out PhantomJS.
I guess it's hard to imagine how you'd even run Javascript code without a browser, or Rhino, or Node, or PhantomJS, or some other JS interpreter environment...
Related
I want to analyze a large and confusing JS code. The code is heavily obfuscated and even tools like JStillery cannot work with it.
I would like to somehow build one of the open JS-interpreters, run it outside the browser and debug in more traditional ways, if necessary, applying patches inside the interpreter.
Unfortunately, the code uses DOM and cannot be executed without a browser.
The question is: are there any known techniques to take any external engine (such as V7, V8, DukTape, JerryScript, MuJS, quad-wheel, QuickJS, tiny-js, ...) and run code inside them that contains calls to DOM and other browser parts?
There are pure-JavaScript implementations of the DOM, such as https://github.com/jsdom/jsdom. Not sure how useful that is for your use case, but it does address your primary question: it allows you to run JavaScript that assumes a browser environment outside the browser environment.
I believe jsdom is fairly accurate in its implementation; there are other implementations out there that are more mock-like. Either way, there are probably some remaining differences, so heavily obfuscated code may well include mechanisms to detect emulated environments...
When I learned Perl and Python, my "development environment" consisted of vim and a shell. I would simply write the program in vim, then execute it from the command line. I am aware that the spidermonkey engine is available as a standalone interpreter, but I'm not sure how practical it is.
The "intuitive" way with JS would be to incorporate the script into a web page and view it in different browsers, but that seems cumbersome. I have seen some recommendations for Firebug, but I couldn't quite get the hang of it.
I know there are several JS-oriented plugins for vim, but again I don't know how practical any are.
I basically want to write a script, and check it for syntax and output, quickly. I am also interested to know how actual JS developers go about testing their code.
I use Node.js a lot, so my answer will be biased by that, but...
For learning the language, Node.js gives you an easy-to-use (like Python, Ruby, et al) REPL by just typing node at the command line.
Validation of your website is nicely done with Zombie, a headless browser implemented in Node.js. If your Javascript is syntactically wrong, as soon as you try to load the page you'll get an error. If your Javascript is semantically wrong (bad logic), then the tests you write to verify proper behavior of the code will fail.
You'll eventually have to test in Firefox, IE, etc, but not really in Chrome because they both use the same V8 engine (you might want to do a cursory glance, of course). IE, as you probably know, has the greatest number of deviations from the other browsers by not implementing features or giving them a different name. Firefox, surprisingly, is also quite deviant, but not in missing features but in having many extra features in the Javascript language that no other browser has (they proposed as part of the ECMAScript standard but were rejected) so it's actually a good idea not to start from there if you want your code to run on every interpreter.
With Node.js you'll also have one of the faster server-side interpreters at your command (faster than Python and Ruby, roughly equal to Lua, and sometimes up to Java's level, and somehow V8 has the fastest RegEx engine in the world), and then server-side code matches client-side code, which makes things like RPC layers much nicer to work with.
I want to program my xhtml Web Applications without javascript.
What are the alternatives for creating interactive xhtml web applications?
Perhaps java applets which do the tasks of javascript?
Or is there another way?
Thanks for any help!
Javascript is hard to debug, is dynamically typed, strange OOP, could be replaced by any other language when that language will be cut to work at a browser.
I would also like some typesafety in my code what can discover many bugs before running the code.
--EDIT 2--
Have a look at http://www.scala-js.org/.
---EDIT---
So for now there is no real alternative to javascript what is as flexible, widespread and applicable.
What i think is applicable are frameworks/tools who compile one language to another like GWT or coffescript.
Thank you for the detailed answers. The reason for my question was, that web development is getting more complex every day. I prefer languages like Java for stable error outlining and type safety. JavaScript on the other hand is (in my opinion) mysterious in its ways and hard to debug (browser incompatibilities, silent errors, unintuitive operands, dynamic typing,....). I developed Websites with JS for years now and it feels horrible to me due to such debugging problems and code management. Yet the libraries are quite powerful and ease much of the work.
To have an interactive site you need something that can execute code on the client machine.
This is (at the moment) usually JavaScript. In the past this would have also included Flash or Silverlight (both of which are now on the wane).
JavaScript has a big advantage in that it can easily manipulate the HTML elements directly. While it is possible to do that with Silverlight it's not as easy as Silverlight is designed primarily to build self-contained objects.
Google Web Toolkit GWT lets you write java code which compiles to client-side xhtml+javascript. It relinquishes the page-based standard web approach for a more desktop-like interaction (if I remember correctly the API is somewhat similar to many desktop windowing toolkits).
You may (but don't have to) also develop the (java) server logic and have some client-server communication baked in for you by the compiler.
Have a look at http://code.google.com/intl/it-IT/webtoolkit/
Some JavaScript alternatives:
Flash
Silverlight
Java applets
This is not a recommendation, just a list.
If you're really that allergic to JavaScript, there are a number of frameworks that let you write server-side code which generates the JS for you, as other answers mention.
Check out Google Dart - it has reached 1.0 recently, and has started standardization process few days ago (ECMA TC52). It also compatible with currently available browser via highly optimizing dart2js translator, so you can start using it right now :). Much more sane language than JavaScript, IMO.
More can find more information on the official page here: https://www.dartlang.org/ (tools, documentation, sample code, tutorials), and there is also nice introductory video on the YouTube: http://www.youtube.com/watch?v=FqsU3TbUw_s.
As well as applets you have Adobe Flash, Microsoft Silverlight, shortly Chrome NACL. None of these interact with the HTML DOM as seamlessly as JavaScript though.
One thing you can do is simply have the server-side code do all of the processing. You limit yourself to having only CSS available for interactivity, but you can still do just about everything by loading a new page.
If you're considering java applets, then I guess it's necessary to mention Flash and Silverlight (*).
Of course, there are "interactive" web applications that don't use javascript... they use postback. But I don't think this is what you mean.
If you want to target just Internet Explorer, you can use VBScript (Microsoft's proprietary javascript) or even ActiveX. But I doubt that's what you mean, too.
So the onus is on you to answer — why not javascript?
(*) I guess.
I'd be very interested to know what your reasons are for not wanting to use Javascript? The answer to that question will make a big difference to how your question should be answered.
The Javascript language is actually quite powerful. Yes, it does have some quirks, but so do all other languages. A lot of the perceived "problems" with Javascript development in the browser are actually people having issues with the DOM rather than Javascript itself. The DOM, on the other hand is where a lot of the shortcomings and the cross browser issues crop up.
If this is where your problems lie, then you may be better off using a Javascript library such as JQuery, which abstracts away a lot of the direct access to the DOM, and resolves a lot of the cross-browser issues.
If you're using the latest browsers, a lot of the simple effects that previously required Javascript can now be done using CSS. drop-down menus, tabsets, fading, rotation and transition effects. All of this can be done with CSS. However most of them are quite new, and not available in all browsers currently in common use, so you would be better off sticking to Javascript for at least some of them for the time being. Even when they are ready for mainstream use, you'll still need some Javascript to hook them all together.
If you do really have a burning desire to develop using a language other than Javascript, then as you already pointed out, there are other options for programming on the web, such as Java applets. There's also ActiveX controls, Flash and Silverlight, and a few others. However none of them are universally available to all users in the way that Javascript is.
All of them require browser plug-ins of one sort or another, and all of them have issues with users who don't want to install them or corporate environments that don't allow them to be installed. In the case of technologies like ActiveX, they may only be available on certain browsers and operating systems, and (again like ActiveX) they often have security issues.
The only real reason that most of these other technologies existed in the first place was to fill a gap in the capabilities of the browsers at the time. All of these capability issues have now been resolved -- with HTML5 and related technologies driven by Javascript, Flash and Silverlight have been rendered obsolete; ActiveX controls were considered obsolete long ago; and when was the last time you saw a Java applet in mainstream use?
The bottom line is that the browser world is moving very rapidly away from any client-side code other than Javascript, and there are very good reasons for that.
Use pyjamas (google it), you can write normal python code and have it compiled as javascript so you get the best of both worlds, the power and expressiveness of python and the ubiquity of javascript.
Also keep an eye on the Falcon project by Adobe, it's an experimental compiler which translates actionscript 3 (a very powerful language compared to plain javascript) and the flex framework to javascript.
You can also try GWT by Google, where java is used as the client side building code (and yes, it also gets compiled to native javascript).
If it runs on the client's computer and can modify the DOM, it can work. JavaScript is the most widely supported so it'll work out-of-the-box for many people.
Basically, anything which functions like JavaScript can replace it.
Flash can perform basically everything that JavaScript can (graphically, but it can't modify the DOM), but if the user doesn't have Flash Player installed, you're out of luck.
Java can also work, but the same concept applies: if the user doesn't have JRE (or a similar machine)
Silverlight is similar to Flash, but much less supported (I can barely get it to work on my Linux box)
Just curious: why are you looking to replace JavaScript with something else?
This may seem inane, but I actually like using jQuery much better than JavaScript. It makes event handling and Ajax very simple.
My team's current project involves re-writing retrieval libraries in JavaScript. We are basically looking for a setup which enables us to apply test-driven development methods.
So far we plan to use Vim to write the code, no fancy IDE. For generating output we would use Spidermonkey's shell environment. JSLint could serve as a moderate syntax checking tool.
The essential question remains: How do you develop JavaScript (browser-independent) programs?
If we are already on the right track, then maybe you can supply us with a few tips and tricks.
You can test your code in Spidermonkey or Rhino (an older JS interpreter in Java), but you won't really know which browsers it works in until you test your scripts in them!
I agree with the earlier poster, using a browser-independent library like jQuery is probably a good idea.
I have not used Spidermonkey, but I know Rhino has a good debugging GUI, allowing the usual: setting breakpoints, watches, and stepping through code.
Only testing you'll make your JavaScript code browser-independent.
If you have the chance to rewrite it all, you might consider jQuery.
It's essentially browser agnostic. Or at least it requires much less object sniffing than plain javascript.
Yes,I'm using the same environment to develop standalone JS apps (vim + SpiderMonkey). I only would add up, that I've made small in-browser IDE for reading/writing/launching JS scripts on the server-side. Sometimes it's very helpful. Also, I'm looking for using WXJavascript project, which seems to be very promising.
There are lots of widgets provided by sites that are effectively bits of JavaScript that generate HTML through DOM manipulation or document.write(). Rather than slow the browser down even more with additional requests and trust yet another provider to be fast, reliable and not change the widget output, I want to execute* the JavaScript to generate the rendered HTML, and then save that HTML source.
Things I've looked into that seem unworkable or way too difficult:
The Links Browser (not lynx!)
Headless use of Xvfb plus Firefox plus Greasemonkey (yikes)
The all-Java browser toolkit Cobra (the best bet!)
Any ideas?
** Obviously you can't really execute the JavaScript completely, as it doesn't necessarily have an exit path, but you get the idea.
Wikipedia's "Server-side JavaScript" article lists numerous implementations, many of which are based on Mozilla's Rhino JavaScript-to-Java converter, or its cousin SpiderMonkey (the same engine as found in Firefox and other Gecko-based browsers). In particular, something simple like mod_js for Apache may suit your needs.
If you're just using plain JS, Rhino should do the trick. But if the JS code is actually calling DOM methods and so on, you're going to need a full-blown browser. Crowbar might help you.
Is this really going to make things faster for users without causing compatibility issues?
There's John Resig's project Bringing the Browser to the Server: "browser/DOM environment, written in JavaScript, that runs on top of Rhino; capable of running jQuery, Prototype, and MochiKit (at the very least)."