Will server-side JavaScript take off? Which implementation is most stable? [closed] - javascript

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone see server-side JavaScript taking off? There are a couple of implementations out there, but it all seems to be a bit of a stretch (as in, "doing it BECAUSE WE CAN" type of attitude).
I'm curious to know if anyone actually writes JavaScript for the server-side and what their experiences with it have been to date.
Also, which implementation is generally seen as the most stable?

I like to read Googler Steve Yegge's blog, and recently I came across this article of his where he argues that Mozilla Rhino is a good solution for server-side JS. It's a somewhat sloppy transcript, you might prefer to watch the video of the talk. It also offers a little bit of insight on why he thinks server-side JS is a good idea in the first place (or rather, why he thinks that it's a good idea to use a dynamic language to script Java). I thought the points he makes were convincing, so you might want to check it out.
A while earlier, he also posted something about dynamic languages in general (he's a big fan of them), just in case you were wondering why to use JS at all.

Why would you want to process
something in Javascript when you can
process it in PHP or ASP.NET which are
designed specifically for this task?
Perhaps because JavaScript is a more powerful programming language than those two? For example, it has functions as first-class data types and support for closures.
Steve Yegge has blogged about porting Ruby on Rails to server-side JavaScript as an internal project within Google ("Rhino on Rails"). He did it because he likes Rails but using Ruby isn't allowed within Google.

Before it was acquired by Google, JotSpot used server-side JavaScript to let you query their database and display your pages. They used Rhino to do it. CouchDB uses server-side JavaScript to create views of their database.
As you can see from these examples, a great way to use JavaScript on the server is for plugins. One of the reasons it's used is that you can create a very isolated sandbox for people to run their code in. Also, because of the way that JavaScript as a language works, you can provide a user tooling specifically honed to the tasks your users need to complete. If you do this right, users don't need to learn a new language to complete their tasks, a quick glance at your API and examples is enough to get them on their way. Compare this to many of the other languages and you can see why using server-side JavaScript to provide a plugin architecture is so enticing.
A secondary popular solution, one which can be seen through a project like Jaxer, is that a common problem of web applications that do client-side validation is that, since JavaScript is easily bypassed in the browser, validation has to be run once again on the server. A system like Jaxer allows you to write some validation functionality that is reusable between both server and client.

Support for JS on the server has been getting stronger and the number of frameworks is getting bigger even faster.
Just recently the serversideJS group was founded. They have a lot of smart people that have been working on serverside JS for years (some of them more then 10).
The goal for this project is to create
a standard library that will
ultimately allow web developers to
choose among any number of web
frameworks and tools and run that code
on the platform that makes the most
sense for their application.
to the people who say "why would you choose JS over java or any other language?" - you should read this Re-Introduction by Crockford and forget about the DOM - the DOM is superugly, but that's not JS fault and JS is not the DOM.

I've never even heard of this, but it strikes me as using the wrong tool for the job. Since programming languages are just tools designed to help us solve some problem.
Why would you want to process something in Javascript when you can process it in PHP or ASP.NET which are designed specifically for this task?
Sure you can pound a nail in with a screw driver, but a hammer works much better because it was actually designed for it...
So no, I don't see it taking off.

Well, plain ol' ASP supported JavaScript server-side years ago and everyone onad their dog used VBShiate instead. But I have to agree with the others: JS does not seem to be the right tool here - and I love to do client-side JS :)

I personally did a whole site in server side JavaScript using ASP. I found it quite enjoyable because I was able to have some good code reuse. This included:
validation of parameters
object modeling
object transport
Coupled with a higher-level modeling tool and code gen, I had fun with that project.
I have no numbers on perf unfortunately, since it is used only on an intranet. However, I have to assume performance is on par with VBScript backed ASP sites.

It seems like most of you are put off by this idea because of how unpleasant the various client-side implementations of Javascript have been. I would check out existing solutions before passing judgment, though, because remember that no particular SS/JS solution is tied to the JS implementations currently being used in browsers. Javascript is based on ECMAScript, remember, a spec that is currently in a fairly mature state. I suspect that a SS/JS solution that supports more recent ECMA specs would be no more cumbersome than using other scripting languages for the task. Remember, Ruby wasn't written to be a "web language" originally, either.

Does anyone see Server-side Javascript
taking off?
Try looking at http://www.appjet.com a startup doing hosted JavaScript applications to get a feel for what you can do. I especially like the learning process which gently nudges the user to build things with a minimal overhead ~ http://appjet.com/learn-to-program/lessons/intro
Now it might seem a weird idea at the moment to use JavaScript but think back when PC's started coming out. Every nerd I knew of was typing away at their new Trash-80's, Commodore64's, Apple ]['s typing in games or simple apps in BASIC.
Where is todays basic for the younger hacker?
It is just possible that JavaScript could do for Web based server side apps as BASIC did for the PC.

XChat can run Javascript plugins.
I've some accounting software completely written in Javascript.
There's this interesting IO library for V8: http://tinyclouds.org/node/
CouchDB is a document database with 'queries' written in Javascript (TraceMonkey).
Considering this, i believe, server-side Javascript did take off.

Server-side programming has been around for a lot longer than client side, and has lots of good solutions already.
JavaScript has survived and become popular purely because developers have very little choice in the matter - it's the only language that can interact with a DOM. Its only competition on the client side is from things like Flash and Silverlight which have a very different model.
This is also why JavaScript has received so much effort to smart it up and add modern features. If it were possible for the whole browser market to drop JavaScript and replace it with something designed properly for the task, I'm sure they would. As it stands Javascript has strange prototype-based objects, a few neat functional programming features, limited and quirky collections and very few libraries.
For small scripts it's fine, but it's a horrible language for writing large complicated systems. That things like Firefox and Gmail are (partly) written in it is a heroic accomplishment on their part, not a sign that the language is ready for real application development.

Flash Media Server is scripted by using Server Side Action Script, which is really just javascript (ECMAScript). So, I do it a lot. In fact, most of my day was dealing with SSAS.
And I hate it. Though to be fair, a bunch of that is more related to the (not so great) codebase I inherited than the actual language.

I think server-side Javascript is guarenteed to take off. Its only a matter of time.
Mozilla, Google, and Adobe have so much vested interest for Javascript that it would take a miracle to dislodge it from the browser world. The next logical step is to move this into the server-side.
This is a step towards moving away from the hodge podge of Internet technology that usually includes all of these
HTML
CSS
Javascript
Serverside Language J2EE/ASP/Ruby/Python/PHP
SQL
I haven't heard much about the current state of Javascript Server frameworks, except that they are mostly incomplete.

I see server-side js will offer considerable advantages in future applications. Why? Web apps that can go offline, client-side db store, google gears, etc...
Following this trend, more and more logic are moving into the client-side. Use an ORM that works for client-side, and use another on server-side (be it PHP / Ruby / whatever), write your synchronization logic twice in two different languages, write your business logic twice in two different languages?
How about use js on the client AND the server side and write the code once?
Convincing?

Personaly i've been developing and using my own JavaScript framework for about 4 years
now.
The good thing about JS on serverside is that implemented in ASP Classic you don't need
any other plugin or software installed, besides i'm also using my javascript (client)
framework on my server, that allows me to enjoy of the same functionality and proven
performance of my functions at both environments client and serverside.
Not only for data validation, but also lets say HTML or CSS dynamic constructions
can be done client or serverside, at least with my framework.
So far it works fast, i have nothing to complain or regret except its great usability
and scalability that i have been enjoying during this past 4 years, until the point
that i'm changing my ASP Classic code to javascript code.
You can see it in pratice at http://www.laferia.com.do

Node.js has taken off and proven that server-side JavaScript is here to stay =)

I can't see most developers getting over their distaste for client-side JavaScript programming. I'd rather go to Java for server-side stuff before choosing JavaScript.

Related

JavaScript framework for client [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
My team consists of more java guys and limited experience with JavaScript. I know this question have been asked several times, but just to get my facts right, I need to clarify few things as my experience in client side technologies are very limited. We've decided to build our solution using GWT instead of pure JavaScript framework (given there are more java experience).
These were the facts to back my decision.
100% written in java
Requires basic java skills (Java SE not Java EE)
OOPHM – Out of process hosted mode – Define your browser & version. Browser compatibility no longer our problem
Debugging – debug your GWT apps just like any other Java application, using your IDE's debugger
Optimized JavaScript - GWT writes faster and more compact JavaScript than you
But some of my application function needs to use external js libraries.
For e.g. Let's say I need make use of some specific js library to draw some stuffs on a particular page. (actually that js files written in dojos).
Can above requirement be accommodated with GWT?
Do you think the decision to go with GWT is wise or do have any other recommendation?
We've found sencha gxt has the best widget library around( I'm aware its commercial, at least i found all widgets what we need). Do you think it's a wise idea to use wrapper library over core GWT ?
Thanks in advance.
Can above requirement be accommodated with GWT?
Yes (see #Andrey Kapelchik's answer).
Do you think the decision to go with GWT is wise or do have any other recommendation?
Given your background and the points you mentioned, I think it is a very good decision. I have built apps with JavaScript, jQuery etc., but for anything that's larger than 1000 lines of code, I wouldn't want to build a JavaScript app "manually" again. The points that are decisive for me:
With GWT, I can re-use parts of the code both on the server and client side. For example, I can validate on the client side to give immediate feedback, then validate again on the server for security, using the same code.
I find my way much easier in large GWT projects. While it's certainly possible to arrange even large JavaScript code in a clear way, it always tends to get unwieldy.
I make intense use of IDE features all the time (refactoring, finding write access to fields, ...), and IDE support for JavaScript is too limited for me.
You will still need a tiny bit of JavaScript knowledge here and there. Your team definitely should learn CSS, and I'd recommend to learn it thoroughly - no matter which client side framework you choose.
We've found sencha gxt has the best widget library around( I'm aware its commercial, at least i found all widgets what we need). Do you think it's a wise idea to use wrapper library over core GWT ?
In a few projects I'm working on, we're using GXT, because that decision was made a few years ago. Here's my opinion: If you need to build something that looks very much like a desktop app, GXT may be perfect, otherwise I wouldn't recommend basing the app on GXT.
You get the best performance with pure GWT, and if you know CSS, it's much more flexible. GXT has some nice features, but working around its limitations, significant performance issues (and sometimes its bugs) can be quite time-consuming. If you really need a special GXT widget, you can still build a pure GWT app, and then add just that one GXT/SmartGWT widget.
I suppose GWT is perfect for the requirements and objectives of your described project. GWT has JavaScript Native Interface to use native JavaScript. JSNI allows integrating GWT with existing JavaScript or with a external JS library. It solves these issues by allowing you to integrate JavaScript directly into application's Java source code.
My team really struggled with this issue after many false starts we determined that JavaScript can not really be avoided and it is not as bad to master as I feared it would be. The time it would take to ramp up on GWT would be around the same as it would take to ramp up on client side JS MVC framework.
We did consider GWT but dropped it because it will be harder to maintain in the long run for the following reasons.
What if the developers of GWT loose interest in maintaining it, it takes a really sophisticated skill set to maintain something like GWT.
Widgets that we might want might be available for something other GWT and porting to GWT might be more work than we want to do.
Modern JavaScript MVC frameworks are getting really mature with a lot of really cool features that make it easy to develop complex one page apps.
Browser will get better, JS frameworks will get better, it will be easier to higher front end developers ... etc.
We also evaluated dojo and dumped it because we felt that customizing it was going to be too hard for our team. Here is what we ended up with.
Twitter Bootstarp for a CSS / widget framework
A bunch of different jquery plugins wrangled up form various places online
JQuery, Backbone, Handlebars for the client side MVC framework.
If i was starting the project again today, I would go with AngularJS from Google, it really is an amazing approach for building client side web apps. Especially because of the clever use of Dependency injection in JavaScript and the two way biding and a bunch of other stuff. I was at a Throne of JS conference and the google AngularJS guys were saying that they ported a 17,000 line GWT app to 2500 line angularJS app.

What are some advantages to using a Javascript-based server over a non-Javascript server?

Disclaimer: This question will be a bit open-ended. I also expect replies to be partly based off of developer preference.
I've been doing some research lately on Express.js (coupled via Node.js) and I'm struggling to find how I would fit either of these technologies into my current workflow for developing websites. Lately I've been working in either Wordpress or Ruby on Rails, the prior will run on Apache, the latter will run on it's own proprietary server (I assume).
Now perhaps I'm just not understanding something, but I fail to see the advantages to enlisting the support of a Javascript-based framework/server. If there are clear cut advantages to making this part of my workflow, what would they be? I haven't been able to find any ways to fit this into (per say) a Rails application or a Wordpress site. Could someone point me in the direction of some better help of implementing these technologies on top of ones I already use?
One last question, what happens if someone has Javascript disabled in their browser? How would a Javascript-based server react (if at all)?
There are two big differences:
Event loop
Node.js is a bit different from the usual Apache concept, because of the way it handles connections. Instead of having synchronous connections, Node uses an event loop to have non-blocking operations. Note that this is not unique to Javascript and there are C and Python based frameworks that also enable a similar event loop approach, however in Javascript it's probably the most natural feeling since this is how JS has worked since it was introduced.
Supposedly, this should enable you to handle more concurrent clients. However, it hasn't had as much real world exposure as the regular blocking solutions so this approach isn't as mature as most current implementations. The actual performance difference is questionable as it depends on the exact requirements for the application.
Code Sharing
This point is much less controversial than the previous difference, but in essence if you have the same language on both the client and the server, you can reuse a lot of the code, instead of having to rewrite your data structures etc in multiple languages, saving you a lot of development time. However, you have to understand that the concepts of server side JS are different from what you know on the browser, such as you don't have dynamic JS with jQuery or Prototype, but it's result and use-cases are more similar to what PHP is widely used for.
The primary advantage of having Javascript as your server-side language is that you're writing your whole system in a single language.
This has advantages in terms of:
Learning curve and mental context switching for the developer
and also in provides some possibility for sharing code between the two environments.
However, this last point is less helpful than it sounds, for a number of reasons, and this is where the disadvantages come in:
Not much code can actually be shared, because of the differences in what the two environments are actually doing. Maybe a bit of validation code, so you know that you're doing the same checks on both client and server, and maybe a few utility functions, but that's about it.
The libraries you use will be completely different between the two as well: jQuery only works on the client, and Node has libraries that are server-specific.
So as a developer, you still need to mentally context switch between environments, because the two environments are different. They may share a language, but their modes of operation are different, and what they do is different. In fact, sharing the language between the two can actually make it harder to context switch, and this can lead to errors.
Finally, it's worth bearing in mind that while Node is getting lots of attention from the developer community, it is still new and evolving quickly: if you're a business considering a it as a development platform, it's probably not quite yet stable enough to base a major project on.

JavaScript on the server-side like PHP

I'm now thinking to establish my server-side code in JavaScript, and begin to do all on it, but I want to know about its security and flexibility compared to PHP.
I want to know too, if it can be successfully used to develop things like forum boards, full web-sites and things like this, as PHP does.
Javascript is just now starting to get some presence on the server, with things like ServerJS and nodeJS, but right now, you would probably be best off using PHP for your server side code, and javascript for client-side beautification.
The question is very, very broad. Interpreting it as "can I use Javascript on the server":
Fundamentally, sure, Javascript is a very powerful language and so you can do development in it server-side just like you can client-side (and if you do client-side scripting as well, you get some definite reuse benefits using Javascript on the server).
For Apache systems, there's the v8cgi project (a FastCGI Javascript plug-in with connectors, using Google's freaky-fast V8 engine).
On Microsoft-based systems, IIS supports Javascript (JScript) on the server out of the box (I use that all the time), which has access to all of the ActiveX stuff (e.g., for talking to databases, dealing with the file system, etc.).
If your server framework is JVM-based, there's Rhino, which is Javascript for the Java platform and has access to all (or nearly all) of the libraries available for Java — e.g., a huge ecosystem of libraries and plug-ins.
Aside from v8cgi, there are a couple of other projects built on Google's V8 engine.
There's a place that does a full stack for you called chromeserver (I don't know what their backend is; I'm not going to infer from the name).
Paul mentioned ServerJS and NodeJS.
There's the whole CommonJS project.
Etc. etc. etc. There's quite a list on Wikipedia.
Arguing against, there's a very rich ecosystem built around PHP. Unless you're using something like Rhino for the Java platform or JScript on IIS (because of the ecosystems they leverage), you may find that you don't have nearly that ecosystem available to you when developing in Javascript for the server. I mean, if you're looking for pre-built forum or wiki software (for example), let's just say you can't swing a dead cat without finding one based on PHP, and the same cannot be said of Javascript on the server.
The way they are usually used, PHP and JavaScript run in entirely different worlds, and are not really comparable. (There is a server-side version of JavaScript but it's fair to say it's not especially widespread yet, and doesn't run on standard web hosting.)
The security issues you are going to encounter in JavaScript (on the browser) side are very different from what you have to look out for in PHP.
I want to know too, if it can be sucessfully used to develop things like forum boards, full web-sites and things like this, as PHP does.
No, not with client-side Javascript. For dynamic applications, you will always need some server-side language backing it, be it PHP or some other language like ASP, Python, Ruby, Perl....
To replace PHP with Javascript, you need server-side Javascript and there is a lot happening on that front. Mozilla’s Rhino runs Javascript atop the JVM and it seems Google is also working on its own server side Javascript framework. The most popular in-production implementations are:
Helma: Several active projects are using it, runs on Jetty & Rhino and lets developers leverage the power of JVM, has its own object-oriented MVC framework
Project Phobos: runs on Glassfish & Rhino and lets developers leverage the power of JVM, includes plug-ins for NetBeans and integrates with jMaki Web UI framework
JSSP: A very simple server side framework, a lot like classic ASP, JSP and PHP
Aptana’s Jaxer showed a lot of promise, especially by bringing the DOM to the server side, but the project seems dead now. From what I understand, node.js is not a server-side Javascript framework in the same sense as Helma and Phobos. Instead it can be used for writing event-driven servers in Javascript (for example: writing your own web server).
Yes, my site is written by node.js
Using websvr, it's Java style have filter and handlers, hosting on debian OS.
This is slightly off-topic, but it may actually get to the core of your question:
if you want to use only one language for web applications, you may wanna have a look at Haxe.
It is a cross-platform language, that (among other targets) compiles to JavaScript and PHP source as well as NekoVM bytecode. For server-side JavaScript, there are NodeJS bindings.
This way you are not bound to a specific platform. The neko and PHP APIs are largely compatible, so you can deploy on both platforms, having the option to choose neko's speed and persistency or PHP's ease of deployment. Please note however, the PHP output has a little overhead although common optimizers as eaccelerator will make this barely noticeable.
Haxe is significantly less forgiving than both JavaScript and PHP. This makes it harder to learn, but a much safer, robust and in the end more productive tool.
In a word: no. Javascript is a client-side language. In order to do the things that you are describing, you need a server-side language such as PHP.
EDIT: OK, technically it is possible to implement Javascript in other areas besides the browser, but this is not very common.
5 YEAR EDIT: Well, 5 years later, this answer obviously is not accurate, with the popularity of things like node.js. Let that be a testament to how quickly things can change!
PHP and JavaScript are two different languages that do two different things. One cannot replace the other. You are most likely going to use a combination of the two. JavaScript for client-side stuff. PHP for server-side stuff.

Questions about capability of Javascript

Many years back, I was told that Javascript was harmful, and I remember being annoyed with endless popup when I right-clicked an image to download it.
Now it seems suddenly that Javascript is great, and you can do a lot of things with it to let users have native-like web application experience.
I admit I have missed 6-7 years of Javascript literature, so I hope to start anew with SO kickstarting me to understand the following:
Is Javascript mainly concerned about user interface i.e. smoothen interaction between application and users and not about logic processing, number crunching or form processing etc.?
Can Javascript write to local hard drive (besides cookies)?
Can Javascript web application run with Javascript capabilities in browsers turned off? (I would think outright no, but an article on Adaptive Path said 'maybe')
Is AJAX illegal to use due to Eolas patent claim? Is it worth it spending effort learning it when the future is not secure? (I know AJAX is not Javascript)
Thanks. Hoping for enlightenment.
Yes. JavaSscript is usually used to enhance the user's experience and make the site easier to use. It is also possible to delegate validation tasks and the like to JavaScript, however (though this should never absolve the server of its responsibility to check input).
No.
That depends on how the application is written. If it's done properly, then the JavaScript will merely enhance the interface, and the application will still work without it; this is called progressive enhancement.
Not at all. AJAX is used extensively on this very site!
One reason for the resurgence of popularity for JavaScript lately is the emergence of several frameworks. These make the process of writing JavaScript much, much easier, allowing tasks that would previously have been horribly complex to be implemented with minimal time and effort. The most popular of these is jQuery, which is a good place to start if you're intending to get in on the action.
Overall, JavaScript is a very powerful tool that allows you to create very rich interfaces. Well worth learning.
Yes, Javascript is all about client side processing, but also about AJAX where it calls back to the server asynchronously so that users do not see pages reloading.
No
No, but there are ways to gracefully degrade the experience for non javascript users. It requires carefult planning however.
No, that lawsuit was just about the browser technology that enables it. As a developer you dont have to worry about that.
Can Javascript write to local hard drive (besides cookies)?
Not really. However, as HTML5 support becomes more widespread you'll be able to use things like Web Storage and Web SQL. You won't be able to write arbitrary files on the user's hard drive, but using those two technologies you'll be able to persistently store and access data.
Can Javascript web application run
with Javascript capabilities in
browsers turned off? (I would think
outright no, but an article on
Adaptive Path said 'maybe')
It really depends on how you define "web application." You can write web apps without using Javascript for anything but UI candy, in which case you can degrade gracefully without without it. However, it's also possible to write web apps that rely heavily (entirely, even) on Javascript, which will utterly fail without it.
Is AJAX illegal to use due to Eolas
patent claim? Is it worth it spending
effort learning it when the future is
not secure?
I'm not a lawyer, but I'd agree with the other answers -- you shouldn't worry about it. I'm certainly still writing AJAX stuff :)
Is Javascript mainly concerned about
user interface i.e. smoothen
interaction between application and
users and not about logic processing,
number crunching or form processing
etc.?
It's about both. And more than that.
Javascript has really come into its own in the past few years. Browsers have gotten a lot faster at executing it quickly, and people have been figuring out new ways to use the language itself to its full potential. You can really start using Javascript like a full-out application programming language, and not just to write little scripts that animate something or validate input.
If you're just getting back into the language and haven't read Crockford yet, I would highly recommend it. It's a great starting point to realizing the full potential of Javascript.
Edit: Some good Crockford Links
Javascript: The World's Most Misunderstood Programming Language
Javascript: The Good Parts (This is a presentation. Crockford also wrote a book by the same name that I haven't read myself, but I hear it's quite excellent.)
It's mainly for UI, but it can be used to save server-time on some operations (for example, Mathoverflow uses it to render LaTeX) and it's becoming popular to do so. But when you do this, you need to be respectful of the end-users time, because JavaScript can hold up some browsers, while it runs. But in general, it's a good and interesting idea.
Not without permission
If it's written correctly, it can. It's called "Graceful degredation" (some other variant terms exist, but the idea is the same). The basic idea is that you have it such that the JavaScript fails 'gracefully', and links that would normally get handled via JavaScript (i.e. to do some inline next-paging) will navigate to a 'backup' page that shows the relevant content.
I don't know about that, but AJAX can be implemented in different ways, XMLHTTPRequest is just one of them :) (And the most common, and suitable). Generally you like a library do this for you anyway (jQuery, or otherwise) but you can do it yourself for fun.
Yes, in my experience JavaScript is generally used to create a streamlined interface and relays information from the client to a server application for processing.
Yes, if the browser is configured to allow this (most aren't by default since this can be very dangerous).
No, JavaScript will not run if the browser is configured to have JavaScript disabled.
I wouldn't forgo learning JavaScript for this reason - as for the legality of the whole thing I wouldn't feel comfortable advising you about this. Still I think JavaScript is worth learning in spite of this situation.
The Eolas patent covers the embedding of objects in a HTML document (see US patent 5,838,906 titled "Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document") ... this scope would not seem to include AJAX as a suite of technologies (being essentially scripting in a document to load content elements).
Partial answers:
I think all the security vulnerabilities associated with javascript have been fixed? IIRC the problems weren't with javascript, they were with particular browser's implementation of javascript.
I wouldn't worry about any patent claims on the AJAX technology. Patent sueing and counter-sueing is common place in the software world and invariably ends up with the affected parties licencing each other's technology. AJAX is not going anywhere :)

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!

Categories

Resources