Develop Reference

What is involved in using Scala.js for non-web, non-Node.js applications?

I've used Scala.js, and enjoyed it, for writing web page functionality.
I wrote some graphics-related functions that draw pictures on the Canvas, for instance. I'm interested in porting some of that code to Adobe Illustrator and Photoshop. They offer scripting in three languages: (1) AppleScript, (2) JavaScript, and (3) Visual Basic. Of course the API is quite different than the Canvas and will offer many specific, powerful functions that I would like to take advantage of.
My program will be rewritten and expanded considerably, so development will continue. What I wonder is whether I can continue to develop in Scala and if Scala.js can be used to write code for Adobe software, or really any software that scripts with JavaScript.
I figure that I have to create some kind of interface to the Adobe API. What would that involve? Would that code be written in Scala? Would it be a plugin to sbt? How much would I have to learn about the internals of the Scala compiler?
Is it worth doing this, or should I choose instead to develop in JavaScript? (I don't really want to write in JavaScript directly because I've had bad experiences with it in the browser, but I can't say I'm an expert in it.)
(Note that I'm not familiar with much of the Adobe API yet... I'm just investigating now.)

Should be pretty straightforward. The key is that you'll need to build facades -- strongly-typed Scala descriptions -- for the APIs you care about in Illustrator and Photoshop. This isn't particularly hard: you only have to worry about the functions you actually want to call, and you describe the function signatures in Scala. With a little practice, this becomes pretty easy -- it typically takes a minute or less per function once you have the hang of it. (I maintain the jQuery facade, which is one of the larger ones, and banged out most of it in an afternoon once I was in practice.)
Assuming that they are using reasonable standard JavaScript, that's probably most of it -- you define those facades, write Scala.js code to use them, and plug the compiled JavaScript into the tools...

Generating modern js-based rich client from server side?

I am working on a intra-net project, which uses javascript for client side effects/widgets, like tree, grid, dragging. We are thinking about to use jquery/backbone plus some jquery ui.
The problem is, with great flexibility of jquery/backbone, our low experienced developers are almost certained to make code MESSY. And I hate that.
To reduce the chance they can make code messy, I am going to build a server-side program to parse xml (those developer will write xml instead of javascript when possible) and generate javascript at runtime. By doing this, I can force restriction on the xml. And xml tends to be less messy.
But before jumping into that, I want to ask is there any similar existing framework? Preferably the javascript generated also make use of model/view/controller pattern.
Or what else can I do to prevent the project from being messy?
ps: I want to educate the developer. But that is a long term job. Not really helpful for current project.
Thank you guys/girls.
Alright, a terrible idea I think. So besides training my developers (for long term), what else can I do? Especially in short term because the project is rolling on?

I like your goal but I think that trying to enforce coding standards in a programmatic way is over-solutionising the problem. The following steps help to steer you in the right direction though:
Use a version control system such as SVN or Git. Not only does this allow you to pinpoint who is messing up your code and educate them, but it gives you the option to roll back changes that completely break your project. It shouldn't be seen as a "blaming" mechanism, but is certainly a reliable way to identify the culprit. You may also find that your developers are less likely to commit code that isn't up to scratch after they realise their work is open to such scrutiny.
Documentation - and I don't necessarily mean having a 300 page wiki on how your project is organised and how functions should be written. But even something as simple as commenting every function will often encourage others to do the same. The important thing is that the developer sees the standard of work they are expected to deliver in your work. Developers with potential will take their cues from you.
Paired programming - get into the habit of sitting with your developers while they code. Not 100% of the time, but often enough that you are aware of their strengths and weaknesses. Teach them the way you want them to code.
If all else fails, resort to tools that help developers with their standards, such as the Resharper plugin for Visual Studio. While this is primarily designed for C# usage, it also provides code hints etc. for Javascript that will help inexperienced developers adopt a set of practices that should improve the readability of their code.
I don't think there is any substitute for a good tutor, and providing any sort of automated solution is likely to cause a lot of headaches for you without ever really improving the skills of those you are hoping to teach.

Is Processing.js worth it?

I am holding back on seriously pursuing ProcessingJS pieces mostly due to the bloat of the library. I have found that pieces like Ball Droppings do not use the library's Processing syntax parser, which is good, since I imagine it would slow down the page more, especially adding to the initial load and setup time. Still, I am wondering if it's worthwhile to use it basically as a big utility library like UnderscoreJS. For example, how good is its implementation with SVG compared with the other libraries out there today like RaphaelJS? Has anyone gone through the implementation of the Processing API extensively enough? When I skim through the I see a lot of boilerplate I don't really need, as well as a couple instances of questionable coding practices. But the library still seems to perform decently, at least on the ProcessingJS homepage, although the examples are set to run at 15fps, and not the (in my opinion) minimally acceptable 24fps.

I think it strongly depends on the project you are working on and the background knowledge you have with the processing library.
Processing.js is a great choice if you already have learned the original processing api (java) and want to leverage your existing knowledge in the web environment. It might be the only choice if you want to port an existing project to the web - actually this is probably the best time to use it.
If you are a JavaScript programmer and don't know much about processing you probably will dislike to write Java syntax in the browser and everything becomes even more problematic if you have to mix it with js. The API doesn't feel like JavaScript and there is a lot of code that could be written more elegantly.
Regarding performance it is not a bad choice, actually most projects run smoothly and I can definitely recommend using processing.js on circumstances like those explained above.
Here is great list of various javascript engines out there:
Javascript Graphic/Game Engines
It is hard to recommend a single library, as the requirements are specific to each project.
For simple graphics/diagrams: RaphaelJs is really nice and performs decently

how good is its implementation with SVG compared with the other libraries out there today like RaphaelJS
Processingjs doesn't use SVG as far as i know, it only uses canvas. Raphaeljs only SVG. There's an interesting read here and also at wikipedia about the difference. The main difference is SVG stores the vector data of objects so you can easily change position, colour, etc... of stuff but also provides mouseover events. Canvas - and processingjs - does no such thing, it draws to the canvas and forgets everything so you have to do more work. Don't know about performance difference between the two.
As far as the processingjs API is concerned, I don't have any clue as how it is implemented but since John Resig of jQuery is involved it can't be that bad to say the least.
I agree with user hlfcoding that writing java in browser feels weird. I am too looking for a cleaner solution for my future canvas experiments.
I fail to see how re-rendering for each frame in JavaScript can be seen as performant.
That's exactly how canvas works, you have to calculate and render every frame in js, it's not processingjs specific. I don't think that's such a performance hit, behind the scene a browser running SVG does the same anyway.

Why Haven't GWT- and Script#-style Frameworks Become Dominant?

With GWT, we can write code in Java and have it translated to JavaScript code.
With Script#, we can write code in C# and have it translated to JavaScript code.
It sounds GWT and Script# will save web developers from suffering javascript pains. Then, why these tools haven't been dominant? Why still people dedicated to write javascript code?

Multiple reasons, and which one is most important differs from developer to deverloper. Here are two:
Because JavaScript is a more nice/flexible/powerful/(insert adjective of choice here) language than Java/C#
People don't trust the output generated by GWT/Script#

I can speak for only GWT, but here's the things that I think are holding it back:
compile time (GWT takes a long time to compile, javascript changes are instant)
learning new language (a lot of web developers don't know how to code java)
FUD over leaky abstractions and compiler. People fear a compiler making javascript for them and the leaky abstractions thing. Both are just FUD in my opinion, but that's doesn't make it any less of a reason.
people often don't understand where and how to use GWT and are put off by it because they try to wedge it into the wrong holes.
There's a perception that GWT was created to allow back end developers to code javascript, but it's not the case at all.
The whole idea of using VerticalPanels, HorizontalPanels, FlowPanels and FlexTables is foreign to people who have already learned how to lay things out in HTML.
Google is bad at marketing. No offence GWT guys, but if it was marketed/showed off a bit better it would have taken off like hotcakes
Lack of great widget libraries for GWT. The widgets that come with it by default are good, but we need a bit more. Libraries like GWT-ext aren't helping in my opinion, because they are just attempts to wrap javascript libraries in GWT, and don't take advantage of the power of coding in Java.
Steep learning curve for web developers, because it's framework is more Swing like than HTML like.
I still use it in my day to day coding, but I've long accepted that it's not about to take off.

For UI development, working in JavaScript is significantly less painful that Java. Would you use a framework which translated assembler to Java to write your Java apps?
Most of the 'pain' with JavaScript was due to browser incompatibilities, which has changed due to large JavaScript libraries (eg dojo), and improvements in the browsers themselves.

Because of Leaky abstractions and because Javascript is a much more elegant and suitable language for ui than Java or C#.

because GWT ist not a one-size-fits-all solution.
GWT ist great and saves a lot of time for java developers who are writing rich internet applications.
BUT!
for my unserstanding, it is quite hard to write a GWT site Seo-friendly.
its impossible to have a non-javascript fallback.
it is not truly optimized for loading speed.

One way to look at (x)HTML, CSS, and Javascript is as the worlds most flexible UI system. Systems like GWT trade some of that flexibility for stability (note: I'm not super familiar with GWT outside the basic premise). There are a lot of software and/or service oriented shops that use the flexibility that (x)HTML, CSS and Javascript provide to differentiate themselves in the marketplace.
Imaginary conversation.
Client: I like the UI you built, but can we make this 20 pixels wider, change the hue slightly, and have an additional floating prompt when you rollover this half of it.
GWT Shop: Yeah, unfortunately the GWT framework doesn't support anything like that without major hacking and/or a lot of extra work that you don't want to pay for.
(x)HTML/CSS/Javascript Shop: Yeah, we can do that without too much trouble, here's an estimate.
I'm not arguing pro/con here and it's certainly more complicated that the imaginary conversation implies, but there are shops who, if forced to adopt a GWT like approach, would loose a competitive business advantage, so they're not going to do it.

The problem with JavaScript isn't the language itself, which is quiet good in my opinion, it is, because JS is misunderstood and people don't take it seriously and don't learn it, but copy & paste crappy scripts without understanding the code.
Secondly, InternetExplorer, JScript and the messed up DOM implementation ruined the image of the language.
But the main Problem is, you have to understand how the DOM and JavaScript works to write GWT code. It's the same as in JSF development, where you have to understand HTML and CSS. It is not like writing Java, where you don't have to understand the whole bytecode.

If your a jave programmer and dont want to learn jave script or care about how IE version deal with Js then GWT is the way to go!

Should I learn/become proficient in Javascript?

I am a .NET webdev using ASP.NET, C# etc... I "learned" javascript in college 5+ years ago and can do basic jobs with it. But I wonder if it is useful to become proficient in it.
Why should I learn Javascript?
Is it more advantageous then learning JQuery or a different library?

Yes, definitely learn Javascript before you learn one of the libraries about. It's the whole walk-before-you-can-run thing.

Make sure you add these sites to your bookmarks:
Mozilla's developer site: This contains the reference to the Javascript API in Mozilla. This will help you make sure you're writing code that Firefox understands.
IE's site in Microsoft Developer Network: The same, for IE.
W3's reference of DOM for HTML: In most web applications today, the Javascript code manipulates the DOM, which is an internal keeping track of the objects displayed on screen (but you already knew that, right ?) This is the reference to the DOM API. It is language neutral, which means it does not target Javascript, but these methods exist in Javascript too.
Douglas Crockford' site: Doug Crockford is THE MAN when it comes down to Javascript. The articles in his page are a must read. Because Javascript has closures and first-class functions, he believes it is closer to Lisp and Scheme than to other languages. And he teaches you how to greatly improve your code with these language features.
Yahoo Developer network: You may also want to check this. I'm not a regular visitor to this site, though, so I can't really say much about it.

Yes, absolutely you should learn JavaScript if you are doing web development. I highly recommend JavaScript: The Good Parts, by Doug Crockford. And, JQuery is a great framework to use (this site uses it) -- it kind of depends on what you are trying to do -- YUI and ExtJS are also very nice.

The answer is simple.

Hands down yes. There's a reason that Google have made such a big fuss about the V8 JS engine for Chrome, why Mozilla are working on TraceMonkey for Firefox and why Webkit have been working on Squirrelfish for a while (now Squirrelfish extreme). It's because JS is becoming more popular by the day.

Javascript is one of those languages that spending a few hours learning will probably teach you 99% of what you will ever really use. I would imagine you are at the point in your learning of javascript that you know more than enough now and just learn one or more of the frameworks now.

I would recommend brushing up on your non-frameworked javascript first. Refreshing/learning basic concepts of dom manipulation and what not. Like learning how to build a linked list, stack or queue in C++ before learning how to use the STL (standard template libraries).
In addition to brushing up on straight javascript, it might be good to get into a framework that doesn't abstract and change the way things work so much, for instance Prototype. You code with it very much the same way you code with straight javascript. Read through the Prototype code, learn how to make classes, and do some fancy stuff. From experience, I can say reading through the Prototype.js helped me learn alot.
After messing around a bit, then I'd say go for jQuery. If jQuery didn't, literally, change the way you write code I'd say go for it first, but learning how to build classes and js inheritance and what not can be a very important lesson for someone who wants to become fluent in JS.

Learning javascript is recommended for any web application developer. Why?
You will better understand the possibilities, limitations and dangers related to developing a web application
It is a boost for your career, if you are working on a web application that has a user interface.
However, learning javascript is usually a trade-off between a programming language and another. You should consider whether javascript is relevant for your career or project.

Unless you want to really get into javascript, I think you'd be better off learning enough JS to leverage one of the tried and tested javascript libraries out there.

One thing nice about JavaScript is that it is quite different from mainstream languages such as C#, VB.NET or Java. Learning it, especially if you have occasions to use it, will give you another insight on programming, and that's always good. I think it's worth learning it.

If you are doing web development then at some point you are going to get exposed to Javascript or ECMAScript at some point in your career for any one of a number of reasons. At a minimum you should know enough Javascript to be able to be able to validate user input; however, the web is moving in the direction of using more an more Ajax so you should also know enough Javascript to properly leverage one of the major libraries out there such as jQuery.
As some of the other users have noted, you can learn most of what you need of Javascript on a day to day basis in a single day or a couple of afternoons. If you want to get more advanced with Javascript then you are going to have to invest much more time in learning the language but odds are that unless you seek out this type of work that you are not going to encounter something that a preexisting library doesn't already exist for.

If all you want is to do some simple UI-effects and the like, I suggest you just pick a library and go for it!
Using libraries eliminates all the flawed implementations of JavaScript and provides you with an API which is the same across all browsers. And if you're working together with others it is also a great way of implementing code-standards and best practices.

Learning a second programming language is always good.
By the sound of it, JavaScript is a language that you use, to it will be of practical use too. As a web dev, it has been recommended to me in a review that i learn at least basic JavaScript.
A library such as jQuery is essential for web development thse days, so you could learn that too.

I don't think a lot of deliberate learning makes sense (but of course you need some basic knowledge), but I also think after some years of web development you'll become pretty proficient in the language anyway :)

If you are a webdev then yes, you should be proficient with Javascript. Javascript is a major part of making web apps as interactive as desktop apps.
With that being said, learn to use one of the cross-browser compatible libraries like JQuery, Prototype, etc. We do not need to have any more single browser crud created using Javascript, just because any real man/woman rolls their own.
A few things to learn in Javascript:
1. Basic syntax
2. The various flavours of function declaration.
3. Passing functions around and how to use passed in functions.

I recommend Jeremy Keith's books: DOM Scripting and Bulletproof Ajax. After you become more fluent in JS I would recommend a JS library(I use jQuery, but that is not important).
JS is important to learn. You cannot use a framework without the proper understanding of how it works. That is doing things backwards.

i thing you should have a good knoloedge base of language specification and DOM (Document Object Model). it means,you shoud know how find/create "page object" an edit properties. Also you should have an idea of "object oriented" javascript tecniques, which the starting point of a lot of framework. you don't need learn specific framework if you don't use it. simple keep in mind generic base concept!

I'll go with the opposite answer most are putting out there. Learning javascript as a developer these days is almost pointless. The language is similar enough to java/C# that it's syntax and semantics shouldn't be lost on you.
What you should learn is jQuery.
As you use jQuery you'll pick up the most common things you'll ever need from javascript anyway.

If you're involved with the Web in anyway then the answer is "Yes, always". Maybe an embedded or system's programmer could get by without JavaScript, but not a webdev.
Most of the libraries are designed to alleviate some of the pain of interacting with a multitude of browsers. They will not abstract away core JavaScript functionality.

Yes, you should learn JavaScript. Sooner or later you will need to use it!