It is documented that GWT converts java code ( a few extensions not supported ) to javascript which gets rendered. When does this conversion happen? I want to know the steps and the agents involved at each step.
Why do we need GWT plugins for each browser? What part of the conversion is handled by the library and what part is handled by the plugin?
I have read a lot of tutorials but this point is still vague.
It is important to understand about GWT that there's a big difference between production mode and development mode. You write Java code and for deployment, the GWT compiler compiles it to JavaScript which is then interpreted by the browser. So, in production, the conversion happens only one time, before you deploy your web app to a server. And in this case, no browser plugin is needed because modern browsers can interpret JavaScript without any help.
In development mode however, things are different. The Java code is interpreted by the GWT browser plugin directly, without an explicit compilation from Java into JavaScript. So you only need a browser plugin in development mode.
And then there's super dev mode, which is different from the scenarios above.
This page explains it all.
Related
I am looking for a JavaScript JavaScript debugger.
The situation is as follows: I am making a JS game engine. The AI scripts as well as various other actions are implemented in JS. It is possible, from the engine's developer mode, to edit this code from the browser itself (using Ace).
Now I want to add debugging capabilities. Mostly I am looking for breakpoints with step into/step over support.
I couldn't find any such library. The best I could find is the outdated debug-js project.
Note that this debugger is intended for developers who are building games using my engine. This happens from inside the browser. The engine is in JS. The debugger should be in JS as well. I want full control over these debugging features, so I can't just use the browser's debugger.
For example if you type the ID of a character in an AI script, I highlight this character. This is the kind of things I can't provide if I edit the scripts in the browser's debugger, but that I can do from Ace running in the page.
Esprima looks like an interesting starting point. It makes it possible to instrument JavaScript code. This JavaScript execution visualization looks particularly promising.
I installed Titanium from appcelerator and built the "KitchenSink" example application.
All works well, I'm just wondering where does the javascript code ends up in a built app.
I grep-ed the Xcode project and also the result application as I found it in Library/Application Support/iPhone Simulator/....KitchenSink.app, but I can't find any function names from .js files, not even string texts used within the application.
Nearest information I found is an answer here : How Does Appcelerator Titanium Mobile Work? but I do not understand clearly how the process works.
Is the javascript code being compiled into a binary code (what compiler is used then?), or is it just transformed in some special data-format and interpreted in a running application ?
Update:
This is what I can see in a build/android directory of KitchenSink:
michal:bin mac$ find . -name table_view_layout\*
./assets/Resources/examples/table_view_layout.js
./assets/Resources/examples/table_view_layout_2.js
./assets/Resources/examples/table_view_layout_3.js
./assets/Resources/examples/table_view_layout_4.js
./assets/Resources/examples/table_view_layout_5.js
./classes/org/appcelerator/generated/examples/table_view_layout.class
./classes/org/appcelerator/generated/examples/table_view_layout_2.class
./classes/org/appcelerator/generated/examples/table_view_layout_3.class
./classes/org/appcelerator/generated/examples/table_view_layout_4.class
./classes/org/appcelerator/generated/examples/table_view_layout_5.class
michal:bin mac$ unzip -t app.apk | grep table_view_layout
testing: assets/Resources/examples/table_view_layout.js OK
testing: assets/Resources/examples/table_view_layout_2.js OK
testing: assets/Resources/examples/table_view_layout_3.js OK
testing: assets/Resources/examples/table_view_layout_4.js OK
testing: assets/Resources/examples/table_view_layout_5.js OK
I didn't look into app.apk before, all I could see were these class files corresponding to each of the javascript files. Therefore I assumed that on Android javascript is being compiled for JVM. Why can't these be found in app.apk ?
Titanium is not a wrapper around a web view as stated before (though that accurately explains how Phonegap works). Jeff's answer, linked in the question, is a technically correct explanation of how Titanium works, but here's the best version I've heard so far, from Marshall Culpepper:
It's true that Titanium Mobile used the WebView (in both Android and iOS) in the pre-1.0 days. However, this is no longer true and hasn't been since our 1.0 release is March 2010.
Since 1.0, we've shipped two separate Javascript runtimes with our apps, and we are running the Javascript code directly without a WebView. Your entire app from start to finish is now controlled by JS, and we provide a comprehensive set of Native APIs that enable this. Everything from UI widgets (yes, including WebView), Core APIs like Networking, Filesystem, Database, all the way to OS-specific things like JS Activities in Android. On the JS runtime front, we're shipping a forked version of WebKit's JavaScriptCore in iOS and a snapshot of Rhino 1.7 R3 CVS for Android. What we actually do with your javascript source is dependent on the platform, but generally it breaks up like this:
Source is statically analyzed to find references to Titanium modules
Localization strings (strings.xml), App metadata (tiapp.xml), and density specific images all generate platform specific analogs.
In iOS:
An XCode project / configuration is generated
JS Source is base64'd and inlined as a variable into a generated C file
xcodebuild is used to generate the final binaries
provisioning profiles, signing keys etc are applied
iTunes and some other glue are used to send the IPA to your iOS device
In Android:
An Android / Eclipse project is generated
In "Development" mode, JS source is packaged as APK assets
In "Distribution" (production) mode, when you're ready to ship the app, we compile the JS to Java bytecode using the Rhino JSC compiler. You can also enable this during development mode by setting "ti.android.compilejs" to "true" in tiapp.xml, see: http://developer.appcelerator.com/question/100201/enable-android-byte-code-compile
dex, aapt, and other Android SDK tools are used to build and generate the final APK
adb and keytool are used for pushing the APK out to the emulator and/or device
There are many more details that I could dive into specifically on each of these points, but the point I wanted to drive home is that we no longer use the WebView as our Javascript engine. You can however still embed WebViews, and we provide some simple integration that allows you to call Titanium APIs from an embedded WebView.
What jhaynie is saying in your linked question is that Titanium interprets your JS code and converts it into something that is almost identical to Objective-C.
In a web application, the browser reads and interprets your Javascript and runs associated native code (perhaps C++) internally. For instance, the browser might say, "This script is executing getElementById(), so I'll run my own C++ methods to accomplish that." What Titanium is doing is figuring out what that JS->C++ (or in this case, JS->Objective-C) would be in advance, and compiling that. It still leaves an interpreter open where necessary for your dynamic code, but it will convert and compile what it can.
That means you won't find anything that looks similar to what you originally wrote in your script. Anything that must be left to an interpreter is still processed and converted, and your symbols will change (e.g. a call to myTestFunction() might be converted to A(), or 10001101001101 :P).
The usual use of Javascript is to have it interpreted real-time by a running program. That's not what's going on here, and that's why you can't see any trace of your script.
Javascript is pre-processed
Titanium performs the interpretation of your script as any other program would do (such as a web browser). It figures out what dependencies your script has on the Titanium API and sets that stuff up. It then maps your symbols directly into (in the case of the iPhone) Objective-C.
A program usually would read in your script (which is a simply a String), interprets it, and runs C code to accomplish what your script asked for. Titanium does this before-hand to figure out what C code should be run, and does the conversion in advance.
Code is compiled where possible
Based on the interpretation of your code and its dependencies on the Titanium API, Titanium figures out what code can be directly compiled, and what must not be compiled in order to allow for they full dynamics of Javascript. I don't know how it chooses what does and doesn't get compiled, but you could check out the source if you want to know that much detail.
Code that must still be interpretted (left as a script) is still converted into symbols that result in more efficient mapping to native code. So it's still an interpreted script, but that doesn't mean it's still Javascript. This means that these parts of your script will still run faster than usual Javascript.
For iPhone, the compilable C is compiled with GCC to create a native binary.
You have a runnable app*
Now you have an app that you can run on your mobile device. Your compilable code has been compiled and runs at lightning speed, while the rest is converted and still interpreted in a more efficient way which runs at near lightning speed. :P
I hope this makes sense now, because it's all I've got! :D
Are these all the languages/solutions you could use in frontend?
javascript+html+css
flash
java
silverlight (c#, ruby, python etc)
And what is a plugin for Safari and Firefox written in? Is it low-level languages like C++?
FireFox plugins use XUL, https://developer.mozilla.org/En/XUL, HTML, JavaScript and CSS;they are called chrome applications. In fact the browser itself is a chrome application. It also uses XPCOM for some things, https://developer.mozilla.org/en/XPCOM. From that link "XPCOM components be used and implemented in JavaScript, Java, and Python in addition to C++".
And if your curious, Microsoft's XAML was pretty much taken from XUL.
As far as I know for plugins in Safari/Chrome and other non-IE, they just use HTML, JavaScript CSS. For IE plugins, check this out, http://discuss.joelonsoftware.com/default.asp?design.4.423268.5
firefox: How to create extensions for firefox
plugins for chrome, you can write those in simple Html, javascript
Simply put (and as you probably well aware), and to use the long-standing terminology, there are two sides to a (say, web) experience, the client and the server:
Any language that can run without a
call to the web server in the client
(i.e. the web browser) is
client-side (Javascript is the
obvious example);
a language that runs on the server,
but produces content that the client
can request, is server-side (Ruby,
Python, Perl, etc.)
Plugins like Flash or Silverlight are a separate case. Although themselves written in languages functioning at a lower-level than client-side scripts, they nevertheless operate in a client browser with the plugin, and - once loaded - Actionscript (say) will run in the browser, client-side.
To complicate matters, HTML and Javascript can be used to write (e.g.) OS X widgets and Browser plugins and - although they may call on server functions for (say) data - they're still client-side.
Further, the ability of HTML5 to store data, and the rise of NoSQL solutions, mean that the division is no longer as clear-cut as it once was.
Front end is never limited to what languages/platforms, frameworks, APIs etc. that you could use. However, you could say that HTML, JavaScript (and its frameworks), CSS are the main platforms you are going to use while front-end developing. But you should keep in mind that complex issues require specific knowledge therefore, it's good to know other languages/platforms as well.
Regarding your second question, even though most of them use HTML, CSS and Javacript.
To learn more about what language and platforms mozilla uses check out this link and click on specific documentation:
https://blog.mozilla.org/addons/2014/06/05/how-to-develop-firefox-extension/
Checkout this tutorial on how to make a chrome extension:
https://developer.chrome.com/extensions/getstarted
Check out this tutorial on how to make a Safari extension:
https://code.tutsplus.com/tutorials/how-to-create-a-safari-extension-from-scratch--net-15050
I'm currently in the need of developing a Windows application. I want to keep things simple (in the spirit of uTorrent) and I would like the result program to be a single .exe file containing all that it needs.
The program is simple. It just needs some UI. It needs to run for a long period of time (lay there as a tray icon). It needs to do some routine tasks like simple I/O. It also needs to access the internet, specifically some web server.
Apart from these small requirements I would like to write all of it in JavaScript, as I feel more comfortable with it than any other language.
I know there's things like Windows Script Host that let you run JavaScript programs and interact with some Win32 API, but will I be able to do everything I need with Windows Script Host? Can I pack all of the Windows Script Host in a single .exe?
If not, what alternatives do I have for JavaScript?
I found that there's actually a JavaScript compiler that comes with the .NET framework called jsc.exe.
For more information:
http://www.phpied.com/make-your-javascript-a-windows-exe/
http://msdn.microsoft.com/en-us/library/7435xtz6(VS.80).aspx
I guess it's not really JavaScript since it introduces extra things like import and even some class syntax which is weird for me. But this works perfectly for me as I will just doing things as I am used to on the web.
Aside from Windows Script Host, there are
Windows Desktop Gadgets (Vista and Windows 7 only)
HTML Applications (HTAs)
Both are written with standard web technologies, HTML, JavaScript, Flash, etc. They can also be extended with COM objects/ActiveX controls such as FileSystemObject, WMI, WScript or even ones that you write yourself. Windows Desktop Gadgets have access to a separate API/namespace with various Win32-esque properties and methods.
It seems that nobody mentioned JSDB.
JSDB offers a command line environment which you can execute arbitrary javascript code. You can easily compile to a .exe file by using the command copy /b jsdb.exe+program.zip program.exe
It's important to know that you've got to call your main js file main.js within a standard zip file. Not sure if the name program.zip is required.
I haven't actually tried making GUI applications with this yet - although it seems to support various APIs like ActiveX.
It's possible that by using the copy /b command mentioned above, you could compile a script from the wscript.exe file - but I tried and couldn't get it working. Let me know if anybody tries and has success somehow.
I think you're looking for Adobe AIR
The Adobe® AIR® 2 runtime enables developers to use HTML, JavaScript, Adobe Flash® software, and ActionScript® to build web applications that run as standalone client applications without the constraints of a browser. ~ The AIR website
Internet Explorer introduced the concept of Hypertext Applications in IE 5. It never made a big breakthrough, so resources and documentation are scarce.
Mozilla-backed competitor Prism seems to be alive and well, though, and is definitely worth a look.
Prism is an application that lets users split web applications
out of their browser and run them directly on their desktop
I believe the best way to go is V8 JavaScript Engine provided by Google.
"V8 can run standalone, or can be embedded into any C++ application." - which I believe is perfect for your needs, because you can do most of the stuff in JavaScript and use provided interfaces to communicate with the system.
I'm not 100% but I believe WSH uses JScript or WScript, not JavaScript.
Color me crazy, but its only a short step form Javascript to Java or C#. I'd suggest C# as, on a windows machine, the libraries are already there. You can just copypaste your .exe and let 'er rip.
If you want a single .EXE, what runtimes are you okay if they are required pre-requisites?
If you're okay with requiring .NET runtime to be preinstalled, then you do all your work in JScript.NET
Chromium Embedded Framework (CEF) may give you some help. i have not clearly know how, but i realy found many Apps using this framework.
http://code.google.com/p/chromiumembedded/
Introduce for CEF are:
The Chromium Embedded Framework (CEF) is an open source project founded by Marshall Greenblatt in 2008 to develop a Web browser control based on the Google Chromium project. CEF currently supports a range of programming languages and operating systems and can be easily integrated into both new and existing applications. It was designed from the ground up with both performance and ease of use in mind. The base framework includes C and C++ programming interfaces exposed via native libraries that insulate the host application from Chromium and WebKit implementation details. It provides close integration between the browser control and the host application including support for custom plugins, protocols, JavaScript objects and JavaScript extensions. The host application can optionally control resource loading, navigation, context menus, printing and more, while taking advantage of the same performance and HTML5 technologies available in the Google Chrome Web browser.
Numerous individuals and organizations contribute time and resources to support CEF development, but more involvement from the community is always welcome. This includes support for both the core CEF project and external projects that integrate CEF with additional programming languages and frameworks (see the "External Projects" section below).
Why not use Rhino -- JavaScript on the JVM? You can even compile your scripts to .class files and package them into a JAR along with Rhino for easy distribution...
I am seeking your stories on how you have streamlined your client side development with Visual Studio. In particular, it seems that I need to build my site too often in order for changes to pushed down to IE effectively. What shortcuts or tools like FireBug, etc. do you use for your client side development? Do you avoid Visual Studio for debugging your client side apps all together?
We are developing the application which is building almost everything on javascript side, all the controls, webservice call (thru Ajax enabled javascript), grids and all kind of stuff.
We have created framework which includes ExtJs, and JQuery. It makes life easy to initialize and define all the controls in jQuery and make get data using webservice. We can use only ExtJs, however Jquery reduce the number of lines we need to define and set the controls. And of course its very light weight as javascript files are like <25-20 kb which needs to use this frameworks.
I've used the steps outlined by ScottGu here to get a better JS intellisense for VS 2008.
(As it is pointed out here, this patch is intended for all JavaScript files, not just jQuery.)
I use the vsdoc files to get intellisense working for jQuery.
lately, I had to work in a VS2005 + IE6 only environment. I've quickly got used to having Firefox for debugging with the tools I subjectively deemed essential: Firebug, PageSpeed, FireQuery.
I tried Aptana. (As of yet however, I didn't invest much time in getting to know it - you may find it familiar if you are equipped with some Eclipse knowledge, though...)
After all is well and done, I check pages in IE and use the built-in profiler in IE8 if there is some IE specific perf issue.
I use the "empty vsdoc" workaround when VS intellisense gives up.
At home, I use VS 2010 RC - and at all places I keep the API references of JS frameworks bookmarked and within reach, just in case.
Place Javascript code in separate JS files.
You might want to consider turning your related sets of functionality into a ScriptControl.
When you work on some JS file and want to avoid the time of rebuilding the whole project, do not make it an embedded scriptresource from the start. Package it in the assembly when it is stable enough.
If you are in doubt whether you get the latest version of your JS file, disable the browser cache. (It can be done from FireBug, or in the IE dev tools.)
Disclaimer: this list is really subjective and probably not complete at all.