Does javascript coding work better with any particular server language?
No. Client Side JavaScript is unaffected by the language used to code the server side processing.
If you are planning to do any kind of XML/"AJAX" stuff, make sure that your language of choice on the server side has robust XML and JSON libraries. If you aren't using it in this manner, it shouldn't make any difference. Having proper libraries will save you a lot of headache later on since you won't be forced to build your own.
The short answer is no.
The long answer is that, no, but you should still simplify the interface between your server-side code and JavaScript:
Use a standardized data serialization format (XML or JSON being the most popular forms). Make sure your serializers and parsers are symmetric; i.e. that you can freely read and generate data on both sides. Do not assume you will always be reading on the client and writing on the server.
Limit manually crafting JavaScript on the server side to a minimum. Try not to dump JavaScript functions with inline script blocks. Try attaching event listeners to elements with JavaScript instead of using onclick or href="javascript:".
No, but there is better integration in certain situations, where server-side code will generate javaScript automatically, such as the .NET framework and the Google Web Toolkit.
Presuming that you mean client-side JavaScript, no. By the time that JavaScript is executing, it's in an environment where server-side code isn't visible. In fact, it would be tricky for JavaScript to even determine what server-size environment created the document it's acting on. All it sees is the output.
Client Side javascript is bound to the browser and not to any specific language. It is all based on the actual output of your server to the clients browser.
Perhaps the question should be - how or why would the server language make a difference. In the end text is being spit out which is possible regardless of language/platform.
If you have javascript on the serverside, you can share code- For instance by doing client side form validation, and using the same validation code on the server before submitting it to a database.
Related
I'm looking into using Backbone.js and node.js to write a small web app. Sharing code between the client and sever is attractive.
I can't figure out how clients without JS (and search engines) should interact with the site. How should form validations and rendering work with no client-side JavaScript work?
Of course, I'd like to do this without code duplication. Seems to me the point of Backbone.js and other server-side js is that you can have the same form validations and template/view generation on the server AND client.
If you have your view coded with javascript, search engines are buggered as they conform to a more traditional web (one url, one state, one page) and don't understand javascript.
You need to use graceful up-gradation if you want to provide a rich experience and support search engines.
With graceful up-gradation, you code your website with no client side javascript, get it all working nice a nifty. Then you use javascript to upgrade the experience. In most cases this is actually easier, as the upgrade process can be automated. See https://github.com/browserstate/ajaxify
Validating the form data on the client side is a good practice because it saves a user from potentially having to re-enter what was written if it does not validate on the server. Validating on the client side does not remove the need to validate on the server, as your question helps point out, because there is no guarantee JavaScript will be running or even that the form used is the one on your server.
I have to develop a website for mobile phones and I am using html5 and javascript. Can I access/insert into server database using html5 and javascript only without using asp, php or any other server side language.
Yes it is. You will however need a backend database with a HTTP interface. One of which is MongoDB which has a REST interface.
More info here http://www.mongodb.org/display/DOCS/Mongo+Extended+JSON
No, you can't, and if you could then you would be insane to do so as it would allow everybody to make arbitrary SQL queries.
Html and Javascript are the Front end side languages, it not advisable to use those languages features to connect to database. Later it would be very tough to maintain it and enhance it.
ALWAYS THINK IN FUTURE PERSPECTIVE, else your code becomes obsolete
instead you can use any scripting language like php to connect to database.
Since you wanted to create a website, obviously PHP and mysal will be always available to you at NO COST.
Use javascript and maybe you may not want to connect to mysql... Try .csv formats and excel... It's good if you are not storing sensitive information.
There is a great bookmarklet script that takes a HTML document and, using javascript, strips out the main article content (like Instapaper, but better).
I want to know the most efficient way to use this same javascript script on the server side with Rails 3.
Is it even possible? The ideal would be to be able to request a URL from the server (in Rails) and then parse the response using the javascript, and return the processed text (and then persist it to a db).
I was thinking of just adapting the script in Ruby, but this seems silly, especially since jQuery and javascript itself have a bunch of built-in functions for parsing a DOM. On the other hand, the script uses DOM constructions from the browser, so it might require a server-side browser?
Any suggestions?
We actually do this very thing in one of our webapps. If you want to implement this functionality server-side in your Ruby on Rails application, your best bet is to use a Ruby HTML/XML parsing library, such as Nokogiri.
I wrote an article specifically explaining how to strip out the important information from a linked webpage, like Instapaper does, using Ruby + Nokogiri.
Create a Printable Format for Any Webpage with Ruby and Nokogiri
Maybe run the script in something like Rhino Shell and capture the output?
Node.js comes to mind when speaking about server-side Javascript.
I think the Javascript stuff of readability could also be translated into Ruby but this would probably require some serious amount of work.
Is the use of server side javascript prevalent? Why would one use it as opposed the any other server side scripting? Is there a specific use case(s) that makes it better than other server side languages?
Also, confused on how to get started experimenting with it, I'm on freeBSD, what would I need installed in order to run server side javascript?
It goes like this:
Servers are expensive, but users will give you processing time in their browsers for free. Therefore, server-side code is relatively expensive compared to client-side code on any site big enough to need to run more than one server. However, there are some things you can't leave to the client, like data validation and retrieval. You'd like to do them on the client, because it means faster response times for the users and less server infrastructure for yourself, but security and accessibility concerns mean server-side code is required.
What typically happens is you do both. You write server-side logic because you have to, but you also write the same logic in javascript in hopes of providing faster responses to the user and saving your servers a little extra work in some situations. This is especially effective for validation code; a failed validation check in a browser can save an entire http request/response pair on the server.
Since we're all (mostly) programmers here we should immediately spot the new problem. There's not only the extra work involved in developing two sets of the same logic, but also the work involved in maintaining it, the inevitable bugs resulting from platforms don't match up well, and the bugs introduced as the implementations drift apart over time.
Enter server-side javascript. The idea is you can write code once, so the same code runs on both server and client. This would appear to solve most of the issue: you get the full set of both server and client logic done all at once, there's no drifting, and no double maintenance. It's also nice when your developers only need to know one language for both server and client work.
Unfortunately, in the real world it doesn't work out so well. The problem is four-fold:
The server view of a page is still very different from the client view of a page. The server needs to be able to do things like talk directly to a database that just shouldn't be done from the browser. The browser needs to do things like manipulate a DOM that doesn't match up with the server.
You don't control the javascript engine of the client, meaning there will still be important language differences between your server code and your client code.
The database is normally a bigger bottleneck than the web server, so savings and performance benefit ends up less than expected.
While just about everyone knows a little javascript, not many developers really know and understand javascript well.
These aren't completely unassailable technical problems: you constrain the server-supported language to a sub-set of javascript that's well supported across most browsers, provide an IDE that knows this subset and the server-side extensions, make some rules about page structure to minimize DOM issues, and provide some boiler-plate javascript for inclusion on the client to make the platform a little nicer to use. The result is something like Aptana Studio/Jaxer, or more recently Node.js, which can be pretty nice.
But not perfect. In my opinion, there are just too many pitfalls and little compatibility issues to make this really shine. Ultimately, additional servers are still cheap compared to developer time, and most programmers are able to be much more productive using something other than javascript.
What I'd really like to see is partial server-side javascript. When a page is requested or a form submitted the server platform does request validation in javascript, perhaps as a plugin to the web server that's completely independent from the rest of it, but the response is built using the platform of your choice.
I think a really cool use of server-side Javascript that isn't used nearly often enough is for data validation. With it, you can write one javascript file to validate a form, check it on the client side, then check it again on the server side because we shouldn't trust anything on the client side. It lets you keep your validation rules DRY. Quite handy.
Also see:
Will server-side Javascript take off? Which implementation is most stable?
When and how do you use server side JavaScript?
Javascript is just a language. Because it is just a language, you can use it anywhere you want... in your browser, on the server, embedded in other applications, stand-alone applications, etc.
That being said, I don't know that there is a lot of new development happening with "Server-Side Javascript"
Javascript is a perfectly good language with a self / scheme prototype style base and a C style syntax. There are some problems, see Javascript the Good Parts, but in general it's a first rate language. The problem is that most javascript programmers are terrible programmers because it's very accessible to get started.
One team at google built out Rhino on Rails, which is an MVC framework like Ruby on Rails which is written in javascript and runs on Rhino a javascript interpreter for the Java VM. In this case they had a requirement to use the Java VM, but wanted to get a language which was fast (javascript is fast), supported duck typing, and was flexible.
Another example is something like CouchDB, a document oriented database which uses json as it's transport format and javascript as it's query & index language. They wanted the database to be as web native as possible.
Javascript is good at string and dom (xml) manipulation, being sandboxed, networking, extending itself, etc... Those kind of features are the thing you often do when developing web applications.
All that said, i don't actually develop server side javascript. It's not a bad idea, but definitely less common.
We use javascript on the client because it is there, not because from a list of languages it was our choice. I wouldn't choose it for any chore on the server.
You can run any language you like on the server, in fact, as many as you like.
javascript is reliable and easy to use, but it is just too labor intensive for common tasks on the server.
I have used both Javascript (NodeJS) and compiled languages (such as Java or C#.NET). There are huge discussions on the internet about which is preferable. This question is very old (2009). Since then the Javascript world has changed considerably, whereas honestly the Java world has not changed much (relatively).
There have been huge advancements in the Javascript world with Typescript, amazing frameworks (such as Next.JS), reactive programming, functional programming, GraphQL, SSR etc.
When I look at compiled code, especially Java code it all still seems to be the same old tools - Spring (maybe SpringBoot) and Jackson. .NET has advanced server side, but not to the extent of the JS world.
Sure my list there can be used with several languages, but I believe Javascript has improved the software engineering world considerably.
Server side development with Javascript, Typescript and NodeJs is engaging, fun and productive. Use it and enjoy it. Like millions are today.
I was looking into GWT. It seems nice, but our software have the must work without JS requirement. Is it possible?
No, it isn't. GWT provides a windowing toolkit that is specifically designed to run on the client, not on the server. Degraded (e.g. non-javascript) code would need to deliver complete HTML to the browser, which GWT simply does not do. It compiles your java code to a javascript file that is delivered to the client and builds the UI by DOM-manipulation on the client. Then there's some code to talk back to the server, some implicit, some written by you yourself. This model does not lend itself well to degrading gracefully.
The only way to degrade somewhat gracefully is to provide a second, non-javascript UI or use another toolkit that doesn't render the frontend on the client but delivers HTML. Sorry.
You could degrade gracefully by creating an html structure that is just 'good enough' (with form posts, linked menus, etc) and then have GWT attach to each part of that structure, augmenting its behavior. For example, make an HTML drop down dynamic, replace a link to another page with a component that opens a lightbox, or replace a link to another page with an XML http request to do the same thing (e.g. cast a vote).
I've done this a number of times for clients.
It's the opposite way that most GWT gets developed, but it can work.
I was looking at this issue myself when designing my website. GWT isn't really any better than just writing Javascript files in that their syntax is almost identical. The true benefit comes when you share client and server libraries. Hopefully you've resolved this issue in the last two years, but at any rate here are a couple examples that you may find useful.
Creating Gmail: With GWT, you can create an EmailFormatter in a shared package that does the email listing markup so that your server doesn't have to. You could then add support for legacy browsers ("older version") by using the same EmailFormatter class on the server side.
Form verification: While is is absolutely necessary from a security perspective to validate user input server side, it is more convenient for most users to have Javascript check a form before it is submitted. You can use the same Java code with GWT to do this.