6

Well..I am learning java now and I am curious to know will this yield a noticeable performance increase ? And If many developers are following similar methodology for windows programming ( C++ back end and Java UI ) or other languages are used like python?

*this : C++ back end and other languages for UI instead of using the other language to write the whole program .

Ahmed
  • 3,398
  • 12
  • 45
  • 64
  • 24
    There's a tremendous difference between **Java** and **Javascript** - they are **completely** different languages. – Pointy Sep 27 '10 at 18:40
  • What do you mean by "will this yield a noticeable performance increase?". Do you mean that Java will be a performance increase over X other language in your specific use or what? You might want to be a bit more specific in your question. – Tommy Andersen Sep 27 '10 at 18:41
  • 3
    I'll assume that there's a bit of a language problem, but you are asking three separate questions, none of which is a complete thought. (When you say "will this yield a noticeable...", what is "this"?) – James Curran Sep 27 '10 at 18:43
  • I thought Javascript is a part of Java . – Ahmed Sep 27 '10 at 18:44
  • 7
    You thought wrong. They share nothing in common except a C-like syntax and the first four letters of their name. – Tyler McHenry Sep 27 '10 at 18:45
  • Well ... I have to answer why is it called Javascript then but that should be answered in another topic . – Ahmed Sep 27 '10 at 18:46
  • *Why* they have the first 4 letters in common is a different story... I heard it was so JavaScript could ride the Java marketing wave/hype, but I have no way of backing that story up. – FrustratedWithFormsDesigner Sep 27 '10 at 18:47
  • 2
    Brand recognigion, marketing, plain and simple. It was originally called LiveScript, but changed the first part to Java since Java was the big thing in the mid to late 90s. There are other reasons for sure, but that one is the most commonly stated. – MooGoo Sep 27 '10 at 18:48
  • You can blame Netscape for that. They changed the name from "LiveScript" around 1995 in order to capitalize on the popularity of Java, which was at that time the coolest buzzword on the web. – Tyler McHenry Sep 27 '10 at 18:48
  • 3
    Also see [What's the difference between JavaScript and Java?](http://stackoverflow.com/q/245062/258127) – Marcel Korpel Sep 27 '10 at 18:57

2 Answers2

24

Firstly, Java and JavaScript are completely different and unrelated languages. Firefox uses JavaScript; it does not use Java at all.

Secondly, this was not done for performance reasons, it was done to make it simpler to write add-ons and extensions that can be used with Firefox on any platform. C++ code needs to be compiled, and once compiled will only run on the platform that it was compiled for. JavaScript is an interpreted language which runs in an interpreter embedded in the browser, and so the same extensions can generally run on MacOS, Linux, or Windows (or anything else that Firefox runs on).

And yes, there are other programs that use scripting languages for this sort of purpose (to allow easy customization and extension). For example, Civilization IV's UI and game logic is written entirely with Python and XML for this reason, while the performance-intensive graphics code is still in C++.

Tyler McHenry
  • 74,820
  • 18
  • 121
  • 166
  • 5
    Civ 4 was notorious for running really slowly and eating scads of memory, though. – Crashworks Sep 27 '10 at 18:43
  • 6
    Well doesn't that just back up the point that it's *not* done for performance reasons? ;) – Tyler McHenry Sep 27 '10 at 18:44
  • So the use of Javascript just for easy customization ? What If I am a writing a windows program that doesn't require much addons like a PDF reader for example Is it better to use C++ for the whole program or check other options for the UI ? – Ahmed Sep 27 '10 at 18:49
  • 1
    If you don't plan on having anyone else customize or enhance your program, there's not usually much point in including an embedded scripting language, since you as the developer can always just change the original source code. – Tyler McHenry Sep 27 '10 at 18:51
  • 1
    This is a somewhat backward way to look at why the **Mozilla Platform** is the way it is. Gecko, the engine behind Firefox which renders web pages and the UI, was designed from the beginning to be a cross-platform application framework. And that is what it is. While Firefox is *by far* the most prominent example of an application built on top of Gecko, other's do exist. See [XULRunner](http://en.wikipedia.org/wiki/XULRunner). The platform never really took off, for a variety of reasons. One is the general perceived "bloat" of Gecko, but I've also found XUL documentation to be severely lacking. – MooGoo Sep 27 '10 at 18:59
  • 1
    It's not just about add-ons. It's much easier and faster to write (and avoid memory safety issues) the core application code in JS than in C++. – Nickolay Sep 27 '10 at 20:02
  • @Nickolay: Have you tried? I've built one of those rare XulRunner apps. Trust me, C++ beats JS hands down. As for (memory) safety? We track errors in the field. Firmly at #1: "object is null" from the JS side. The most common error from C++ side seems to be a disk I/O error that's improperly handled. – MSalters Sep 28 '10 at 08:39
  • @MSalters: yes I have, both in Mozilla code and otherwise. In Mozilla's C++ I spend ages waiting for the linker and writing 3-5x the number of lines I'd write in JS. In general it's not as bad, but still *I* wouldn't say C++ code is easier to write (unless you're proficient in C++ and don't know JS). I don't want to get into a heated discussion in SO comments; my original comment intended just to state the reason Mozilla is moving code not critical to performance to JS. Just as one example, see https://bugzilla.mozilla.org/show_bug.cgi?id=374723 – Nickolay Sep 29 '10 at 19:02
  • Actually, a 'cross-platformness' of the XUL+JS mix is under the question in the whole Mozilla paradigm. You simply and just CAN'T - as far as I know - make an inteface part on pure JS without creating a dot-XUL file... The XUL engine is good, but why isolate it from JS? It breaks portability, not adds it. – Alexey Vesnin May 18 '15 at 18:56
4

This question really doesn't make any sense unless you're really asking whether you should implement your applications as XUL applications. Javascript by itself doesn't give you anything with which to build a user interface. A tremendous amount of the code in Firefox is C++ code to provide the Javascript components with a UI framework.

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • +1 This is an important point that I missed. The JavaScript in Firefox (and Python in Civ IV, etc.) doesn't *create* the UI, it allows third-parties to *customize* and *modify* the UI. – Tyler McHenry Sep 27 '10 at 18:56
  • 2
    I am a beginner . I am not supposed to know all this or I wouldn't have asked at the first place ! – Ahmed Sep 27 '10 at 18:58
  • 1
    @Ahmed I'm not blaming you for not knowing - I'm simply telling you the truth. Javascript is simply not a way to build a UI for *anything* outside of a browser, or something else (like Firefox itself) that *does* provide a UI framework. Also, you should probably learn what downvotes are really for. – Pointy Sep 27 '10 at 19:03
  • Javascript defines the behavior of the UI in Firefox, exactly as it would in HTML, so I would say in that respect it *does* create it. The tremendous ability to change virtually anything in Firefox exists because the UI is built in the same way extensions are (XUL/CSS/JS). With a UI hard coded in C++ you end up with an extensions system like in Chrome which offers barely more power than a Greasemonkey script. Web browsers that use the Gecko engine for HTML rendering but native API's for the UI, such as K-meleon and Camino are similarly limited in the extension capability department. – MooGoo Sep 27 '10 at 19:14
  • Well yes the Javascript code tells the UI code what to do, but my point is that just by linking V8 into your C++ code, you really don't have much more of a UI framework than you did previously. Sure, it may be a good idea *if* you want a lot of future flexibility or a plugin/add-on architecture or whatever, but on the way there you're *also* going to need to identify an actual UI toolkit to draw lines and boxes and circles and hamsters and text. – Pointy Sep 27 '10 at 20:01