Related
I have just begun giving JavaScript a try on a programmer friend's suggestion (though I have used it to some extent before with websites using jQuery without fully understanding the intricacies of the language itself) and was wondering how certain features work.
Question:
What other uses of JavaScript are there aside from websites (by itself and/or with jQuery framework)? Is there a difference between making a site interactive and an actual "web app"? I've heard the term and don't know the difference.
To add to my main question:
I've read and done some tutorials on prototyping and am not sure on its actual application (since what little I've dabbled in, by making a website more interactive, I've never seen them used). Can someone link a website with extensive deep/heavy JavaScript use so I can check it out?
Gist:
In essence, what I'm trying to understand is where heavy use of JavaScript comes into play because so far, all JavaScript I've experienced is superficial.
Appreciate in advance any advice/help in this matter!
What other uses of Javascript are there aside from websites (by itself and/or with jQuery framework)?
Check out node.js. It runs JavaScript programs not intended for web use. Node offers a bunch of imports for things like file system IO, socket IO and a bunch of others. I personally use it for a WebSocket server because I don't like my alternatives.
Further, JavaScript has native support in many operating systems, including all Windows versions after and including XP (not sure about before). Windows Script Host runs .js files as JScript and these can be used to achieve things like those node can. It's a convenient way to do things batch can't.
I'm trying to scrape and submit information to websites that heavily rely on Javascript to do most of its actions. The website won't even work when i disable Javascript in my browser.
I've searched for some solutions on Google and SO and there was someone who suggested i should reverse engineer the Javascript, but i have no idea how to do that.
So far i've been using Mechanize and it works on websites that don't require Javascript.
Is there any way to access websites that use Javascript by using urllib2 or something similar?
I'm also willing to learn Javascript, if that's what it takes.
I wrote a small tutorial on this subject, this might help:
http://koaning.io.s3-website.eu-west-2.amazonaws.com/dynamic-scraping-with-python.html
Basically what you do is you have the selenium library pretend that it is a firefox browser, the browser will wait until all javascript has loaded before it continues passing you the html string. Once you have this string, you can then parse it with beautifulsoup.
I've had exactly the same problem. It is not simple at all, but I finally found a great solution, using PyQt4.QtWebKit.
You will find the explanations on this webpage : http://blog.motane.lu/2009/07/07/downloading-a-pages-content-with-python-and-webkit/
I've tested it, I currently use it, and that's great !
Its great advantage is that it can run on a server, only using X, without a graphic environment.
You should look into using Ghost, a Python library that wraps the PyQt4 + WebKit hack.
This makes g the WebKit client:
import ghost
g = ghost.Ghost()
You can grab a page with g.open(url) and then g.content will evaluate to the document in its current state.
Ghost has other cool features, like injecting JS and some form filling methods, and you can pass the resulting document to BeautifulSoup and so on: soup = bs4.BeautifulSoup(g.content).
So far, Ghost is the only thing I've found that makes this kind of thing easy in Python. The only limitation I've come across is that you can't easily create more than one instance of the client object, ghost.Ghost, but you could work around that.
Check out crowbar. I haven't had any experience with it, but I was curious about the answer to your question so I started googling around. I'd like to know if this works out for you.
http://grep.codeconsult.ch/2007/02/24/crowbar-scrape-javascript-generated-pages-via-gecko-and-rest/
Maybe you could use Selenium Webdriver, which has python bindings I believe. I think it's mainly used as a tool for testing websites, but I guess it should be usable for scraping too.
I would actually suggest using Selenium. Its mainly designed for testing Web-Applications from a "user perspective however it is basically a "FireFox" driver. I've actually used it for this purpose ... although I was scraping an dynamic AJAX webpage. As long as the Javascript form has a recognizable "Anchor Text" that Selenium can "click" everything should sort itself out.
Hope that helps
I'm at a stage in which I did not learn internet scripting languages yet, but I do understand JavaScript enough to edit scripts I find on the web to suit my needs. Lately, I've been searching for an RSS to HTML converter, and was surprised to find out that it usually involves PHP. I don't see a reason for JavaScript to not be adequate for the task, so my question is- is it really not? And if so, why?
Also if you can show me some code examples I'll greatly appreciate it (I do plan to learn Javascript eventually, I'm not just leeching. I just lack the time at the moment).
I think the reason most examples use server side scripting is that, since the Javascript same domain policy means you have to request the RSS from your own server anyway, then you may as well transform it into 'display format' on the server side too. Also, if you're doing some sort of Ajaxy stuff then there are better ways of getting the data to the script in the browser than just handing off a full RSS feed.
Having said all that, there are ways to parse RSS and similar XML feeds on the client side. One option is to just style the RSS directly using CSS and/or XSLT. I don't think using CSS for this is too common in the real world because you have to use different methods in different browsers, but transforming XML with XSLT in Firefox is fairly straightforward and I'm fairly sure it's possible in IE and the other browsers too, but XSLT may be a bit beyond your comfort zone.
A good source for Javascript examples is the Google Data APIs as they use the Atom Publishing Protocol which is conceptually similar to RSS. For example, here is the Javascript documentation for the Analytics API.
JQuery has an XML parser built in. Here's a great tutorial that details the use of the built-in feature. :)
http://www.google.com/search?q=rss+parse+javascript
First result appears to be relevant, with source code:
http://www.captain.at/howto-ajax-parse-rss.php
Often I need to refer to code written in HTML/JavaScript/CSS, but it is a very awkward construction to constantly refer to the descriptive trio of 'HTML/JavaScript/CSS' code.
for example, Mozilla refers to its HTML/JavaScript/CSS JetPack code as 'a JetPack'.
Other than the defunct 'dHTML', what are some concise, generic and accurate terms I can use to collectively refer to applications written in HTML/JavaScript/CSS.
I'm going to have to say DHTML anyway. Why would you say it's "defunct"? It is the perfect answer to this question. See http://en.wikipedia.org/wiki/DHTML. DHTML means Dynamic HTML—which is exactly what the combination of HTML/JavaScript/CSS code is.
Unless you're dealing with someone who isn't impressed with terms that are less than a year or two old, or unless you aren't specifically talking about code, DHTML conveys exactly what you are talking about.
Web application is perhaps too loose of a term, but it's a start.
Let's break it down.
HTML is data, CSS is presentation, and JavaScript is code. These are web technologies.
These are usually brought together by a browser.
Something in a browser on the web is a website.
JavaScript suggests it is somewhat interactive, so it's not just a site, it's an application.
("Application" also suggests that it's more complex, like with a SQL backend or something, so you might sound even more talented. :)
I'm guessing that you had the term LAMP (Linux, Apache, MySQL, and PHP) in mind? To my knowledge there is no such abbreviation for HTML, CSS, and JavaScript. The easiest way to say it is to just say it.
Versus "Front end" – I think that term implies that you built something that customers used. "Web application" is nonspecific about who the users are, so it would apply to customer-facing applications as well as internal-use applications. The word "application" implies that it's not just a tool; there are users who are not the programmers. "Front end" is probably more impressive because a customer-facing application has to be nicer than an internal one.
If you are not using it in a browser, or it's not actually on the web, maybe just your intranet or an internally distributed application bundle, it's still an application developed with web technologies.
Given that the person you're trying to convey this message to knows you're talking about web-related stuff - Front-end or Front-end development has always worked for me.
"HTML5" is the answer I now believe to be correct to replace "HTML/JavaScript/CSS". Since I asked the question in January, HTML5 has gained a lot more recognition for its incredible capabilities and promise. "HTML5" also has significantly greater name recognition than 7 months ago, and clearly sets it apart from lesser HTML.
I think the reason there's no specific term is the same reason that dHTML fell into disrepute - all three scripts are so integral to frontend development that there ceases to be a need to refer to them specifically. If you code in HTML, you almost necessarily use CSS, and if you have any active content at all it will most probably be in JavaScript.
Frontend development is a bit vague, but something like HTML based frontend development should get your point across.
If you want to refer to an application - use Web Application.
And if you need to refer to some code - use simple JS (JavaScript) because most of your code (except for some ie css expressions if you use it) will be in JS, isn't it?
Web Suite
suite: a set of things belonging together, in particular.
thus you have:
Web Suite: the set of HTML/CSS/JavaScript, the basic technologies used to develop a web site or application.
example:
"I used the Web Suite to make a cool website to show off all my pictures of cats sitting in boxes."
"UX" (User Experience) or "Front-end Development."
Web Applications, and Web 2.0 are both big names. One name/acronym that I personally like to use is RIA, or Rich Internet Application. From the article:
Rich Internet Applications (RIAs) are
web applications that have most of the
characteristics of desktop
applications, typically delivered
either by way of a standards based web
browser, via a browser plug-in, or
independently via sandboxes or virtual
machines.1 Examples of RIA
frameworks include Ajax, Curl, GWT,
Adobe Flash/Adobe Flex/AIR,
Java/JavaFX,[2] Mozilla's XUL,
OpenLaszlo and Microsoft
Silverlight.[3]
Also, someone else mentioned "impressing the suits," which this title tends to do. After all, it's got "rich" right in the name ;)
Web code
I was just having to write "HTML/Javascript/CSS" in an email and thought, "Isn't there a better term for this?". Googling, I found this post. I'm going with "web code".
Some call it a JAM stack, which stands for Javascript, API and Markup. But I acknowledge that it's not as specific as LAMP or something like that.
https://en.wikipedia.org/wiki/Solution_stack
https://jamstack.org/
However uncool it might be, it is still DHTML to me.
They are standard web technologies for producing dynamic websites and web applications. The last thing we need is another vacuous moniker for something that is more than adequately described by DHTML.
An Alternative to this Source or Page Source.
The Context all depends but for me this seemed to be a good name. When I right-click and I see "view page source" it seems relevant. it contains all of this HTML/CSS/JS.
I like Web Application but my use case was page-specific, not app-wide.
I've been calling this the web stack (HTML, CSS, JavaScript). Exclude frameworks or other tools, just the base technologies of what the web is made.
With the increased power of JavaScript frameworks like YUI, JQuery, and Prototype, and debugging tools like Firebug, doing an application entirely in browser-side JavaScript looks like a great way to make simple applications like puzzle games and specialized calculators.
Is there any downside to this other than exposing your source code? How should you handle data storage for this kind of program?
Edit: yes, Gears and cookies can be used for local storage, but you can't easily get access to files and other objects the user already has around. You also can't save data to a file for a user without having them invoke some browser feature like printing to PDF or saving page as a file.
I've written several application in JS including a spreadsheet.
Upside:
great language
short code-run-review cycle
DOM manipulation is great for UI design
clients on every computer (and phone)
Downside:
differences between browsers (especially IE)
code base scalability (with no intrinsic support for namespaces and classes)
no good debuggers (especially, again, for IE)
performance (even though great progress has been made with FireFox and Safari)
You need to write some server code as well.
Bottom line: Go for it. I did.
Another option for developing simple desktop like applications or games in JavaScript is Adobe AIR. You can build your app code in either HTML + JavaScript or using Flash/Flex or a combination of both. It has the advantage of being cross-platform (actually cross-platform, Linux, OS X, and Windows. Not just Windows and OS X).
Heck, it may be the only time in your career as a developer that you can write a web page and ONLY target ONE browser.
SproutCore is a wholly JavaScript-hosted application framework, borrowing concepts particularly from Cocoa (such as KVO) and Ruby on Rails (such as using a CLI generator for your models, views and controllers). It includes Prototype, but builds plenty of stuff such as sophisticated controls on top of that. Its Photos demo is arguably impressive (especially in Safari 3.1).
Greg already pointed you to Gears; in addition, HTML 5 will come with a standardized means of local storage. Safari 3.1 ships with an implementation where you have a per-site SQLite database with user-settable size maximums, as well as a built-in database browser with SQL querying. Unfortunately, it will be a long time until we can expect broad browser support. Until then, Gears is indeed an alternative (but not for Safari… yet!). For simpler storage, there is of course always cookies.
The downside to this would be that you are at the mercy of them having js enabled. I'm not sure that this is a big deal now. Virtually every browser supports js and has it enabled by default.
Of course the other downside would be performance. You are again at the mercy of the client handling all the intensive work. This also may not be that big of a deal, and would be dependent on the type of app you are building.
I've never used Gears, but it looks like it is worth a shot. The backup plan would be to run some server side script through ajax that dumps your data somewhere.
Not completely client side, but oh well.
Nihilogic (not my site) does a lot of stuff with Javascript. They even have several games that they've made in Javascript.
I've also seen a neat roguelike game made in Javascript. Unfortunately, I can't remember what it was called...
If you want to write a standalone JavaScript application, look at XULrunner. It's what Firefox is built on, but it is also built so that you can distribute it as an application runtime. You will write some of the interface in JavaScript and use JavaScript for your code.
Gears might provide the client-side persistent data storage you need. There isn't a terribly good way of not exposing your source code, though. You could obfuscate it but that only helps somewhat.
I've done simple apps like this for stuff like a Sudoku solver.
You might run into performance issues given that you're completely at the mercy of the client's Javascript interpreter. Gears would be a nice way of data storage, but I don't think it has penetrated the market that much. You could just use cookies if you're not fussy about that kind of thing.
I'm with ScottKoon here, Adobe AIR is great. I've really only made one really nice (imho) widget thus far, but I did so using jQuery and Prototype.js, which floored in such wonderful ways because I didn't have to learn a whole new event model. Adobe AIR is really sweet, the memory foot print isn't too bad, upgrading to a new version is built into AIR so it's almost automatic, and best of all it's cross-platform...they even have an alpha-version for Linux, but it works pretty well already on my Eee.
Standalone games in GWT:
http://gpokr.com/
http://kdice.com/
In regard to saving files from a javascript application:
I am really excited about the possibilities of client-side applications. Flash 10 introduced the ability to create files for save right in the browser. I thought it was super cool, so I built a javascript+flash component to wrap the saving feature. Right now it only works for creating text based files (vcard, ical, xml, html, css, etc.)
Downloadify Home Page
Source Code & Documentation on Github
See It In Use at Starter for jQuery
I am looking to add support for non-text files soon, but this is a start.
My RSS feeds have served me well- I found that Javascript roguelike!
It's called The Tombs of Asciiroth.
Given that you're going to be writing some server code anyway, it makes sense to keep storage on the server for a lot of domains (address books, poker scores, gui configuration, etc.,.) For anything the size of what you'll get in Webkit or Gears, you can probably also keep it on your server.
The advantage of keeping it on your server is two-fold:
You can integrate it fairly simply as a Model layer in a typical MVC framework, and,
Users get a consistent view without being tied to their browser/PC, or in a less-than-ideal environment (Internet Cafés).
The server code for handling this can also be fairly trivial, particularly if it's written with this task in mind, so it's not a huge cognitive burden.
Go with qooxdoo. They recently realsed 1.0, although most users of it say it was ripe for 1.0 at least two versions ago.
I compared qooxdoo with YUI and ext, and I think qooxdoo is the way to go for programmers - YUI isn't that polished as qooxdoo, from a programmer's point of view and ext has a not so friendly licensing model.
A few of the strong points (for me) of qooxdoo are:
extremely clean code
the nicest OO programming model I've seen among Javascript frameworks
an extremely rich UI widget library
It also features a test runner for unit tests, an API doc generator and reader, a logging facility, and several useful features for debugging, grouped under something called Inspector.
The only downside is that there aren't readymade themes (something like skins) for qooxdoo. But creating your own theme is quite easy.