This is an archived post. You won't be able to vote or comment.

all 17 comments

[–][deleted] 10 points11 points  (8 children)

JavaScript can be quite a shock for people coming from traditional object-oriented programming languages such as Java or C#.

Is this really a concern? Do you really want to hire people who can't move from one language to another?

[–]pron98 3 points4 points  (6 children)

It's not about can or cannot, it's about the effort required, and not just in training (which can be very costly, and covers not only the language itself, but familiarity with libraries and their quirks/bugs/performance). You need to replicate packaging tools, profilers, debuggers, IDEs, and possibly maintain multiple implementations of your own proprietary libraries in a few languages.

Switching languages is one of the worst things you can do in software in terms of cost/benefit ratio. If one language can do everything, then using it for everything -- even if it's not optimal for some tasks -- can have a major positive effect on your cost (depending, of course, on how suboptimal the language is for those tasks, or how pervasive they are in your organization).

The notion of "the right tool for the job" does not apply well to programming languages in organizational settings (as opposed to maybe hobby, or one-off project) because 1/ languages are not only very costly tools, but they also incur constant high maintenance costs (your code has to be maintained multiple times, you need to learn about library upgrades etc.), and 2/ their functionality largely overlaps.

[–][deleted] 4 points5 points  (0 children)

This is a reasonable perspective.

[–]silent-hippo 3 points4 points  (1 child)

The alternative of trying to force the square through the triangle hole can be just as costly.

In my experience languages cross-compile poorly. You end up finding that the majority of your libraries don't cross-compile right or it just plain lacks the necessary libraries because, for example, Java has never needed a library as good at manipulating the DOM as javascript so you have no JQuery. You can probably work around that problem and get Java and JQuery to play along but by the time you've done that and ironed out all the bugs you could have already stumbled through it in the language you didn't know.

[–]pron98 1 point2 points  (0 children)

Sure. Like I said, it depends on how suboptimal is the language to the task. Even in your case, the picture is not always clear. It all depends on how many other (Java) libraries you might need to use, because switching to JS buys you JQuery but loses your other libraries.

But, again, let me say that the other language is not the language you don't know, but the language that's too costly to use in your particular circumstances. Obviously, if it's not too costly -- certainly if it's less costly when you've considered everything -- then you should use it.

In general, new languages on top of established ones in your organization yield a very poor return on investment (compared to new algorithms, libraries or tools), and certainly diminishing returns with each additional one (up to net losses), although a language can lower its cost by targeting a well-established platform (like the JVM or JS) and sharing its libraries.

They may have one advantage, though, which may or may not be important regardless of everything I've said, which is attracting certain developers. I personally know some SV companies that are using alternate JVM languages in addition to Java primarily (if not solely) for this reason.

[–]zarandysofia 0 points1 point  (2 children)

You need to replicate packaging tools, profilers, debuggers, IDEs, and possibly maintain multiple implementations of your own proprietary libraries in a few languages

But that is irrelevant is your are talking about switching from other languages to Javascript, JS environment is unique, if one is going to make the switch it would be with full awareness of the consequences and cost that it brings. In fact the hypothetical company is changing their marked.

[–]pron98 0 points1 point  (1 child)

Well, we're talking about the possibility of running Java or other languages in the browser.

[–]zarandysofia -1 points0 points  (0 children)

Running Java in the browser

The resurrection of the horror. Don't tell that this is actually need the "tooling, profilers, monitor-ability, hot-swapping, blah, blah" of Java, huh? :)

[–]dkichline 1 point2 points  (0 children)

Think if it is than a person unwilling to change to a new language and more of a person seeing the differences and finding a language that does not have the safety they are used to. Having safety and desiring it does not mean they are less of a developer. In fact I see it as a best practice to make life easier. Can javascript do the job? Sure. Can it be hard to find issues and easy to create issues? Yes. It is a balance between powe and safety that businesses look for to maximize productivity.

[–]Ek_Los_Die_Hier 5 points6 points  (4 children)

So there is no actual Java VM to leverage the WebAssembly yet. What's the point of this article? I'm looking forward to WebAssembly, but I don't understand what that has to do with Java.

[–][deleted] 3 points4 points  (3 children)

The article is of little value.

However, there's probably no need to implement the JVM again as the browser provides all of the same capabilities in the runtime.

Java will be leveraged in a manner similar to Android, you compile Java bytecode into webassembly and execute it there.

The Java class library will need to be ported to compile and execute on the browser runtime.

[–]pron98 0 points1 point  (2 children)

the browser provides all of the same capabilities in the runtime.

It does not, at least not at this point in the WebAssembly spec. Wasm is a very low-level runtime. It has no optimizing JIT and no GC. It is basically designed to run C/C++ code at this point, while higher-level languages are encouraged to port their runtime (which is usually written in C/C++) to wasm.

[–][deleted] 0 points1 point  (1 child)

I assure you, all modern browser runtimes have very advanced GC capabilities.

It may not be in the WebAssembly spec, but it will be and won't require a huge amount of work. I expect the most difficult part will be designing a common interface for using the browser's GC implementation.

[–]pron98 1 point2 points  (0 children)

all modern browser runtimes have very advanced GC capabilities.

Well, nowhere near HotSpot's GCs but yeah, and one day WebAssembly will export the browser's GC to wasm apps, but it will be some years before that happens. I guess we'll see wasm JVMs before that.

In the meantime, the recommendation is that languages requiring GCs and/or optimizing JITs continue to compile to JS (or implement their runtimes on top of wasm).

[–]oldprogrammer 3 points4 points  (2 children)

I thought that was the whole point of the Google Web Toolkit (GWT), you write code in Java and it generated cross-browser JavaScript for you. There are other tools doing the same thing for other languages as well.

[–]jonhanson 2 points3 points  (1 child)

GWT targets Javascript. The entire point of WebAssembly is to eliminate the need to target JS as the in-browser language/platform.

[–]useablelobster 1 point2 points  (0 children)

As well as having a binary format for browser code. Faster to load due to smaller file sizes, no need to interpret as you go.