We Keep Coding

Transforming a major website into a javascript application [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.
I would appreciate your opinions. I have been put in charge to redevelop a major site that does quite a bit of traffic. As of the past few months, I have been using Backbone.js to develop applications. I have been researching the last couple of weeks on whether Backbone would be a good fit for the redevelopment of the new site.
My initial concern was SEO. Found a great post here that talks about progressive enhancement and a bunch of stackoverflow questions that have helped to. I can't seem to shake the feeling that building a static site and enhancing it with Backbone is quite a feat and will take much more time.
Now my question is, have we not passed the stage where we have to build sites that have to work with javascript disabled? Is it essential that our site is still functional for screen-readers etc?
My idea was to serve the relevant meta seo information from the server into my main app.html file so search engines will still be able to crawl the different urls. The Backbone app will be launched from whatever url you visit that is relevant to the app.
I have just visited the new hulu.com, and cant seem to come up with a reason as to why not re-develop the website into a Backbone application. Most if not all websites I have visited, will not function without js. Go to hulu.com with js disabled and you will be able to see what I mean. So in closing is it safe to build a website that will not function without js and will the above suffice for SEO?
Thank you

I think there will be a lot of opinions on this. Here's mine.
As a default mind setting I always find backward-compatibility and graceful fallback important. I normally believe a site should be able to fulfill it's main purpose: delivering content (content sells).
However.. what if the purpose aka content is delivering some kind of functionality, like a online calculator or drawing application.. Then the user would already need and expect things like javascript to be enabled. In those cases I'll happily make design/layout things easer on me, using javascript. Think of a site like jsfiddle: who would care if this site didn't display it's ui properly because javascript was disabled.. Nobody.
As to SEO: I think there are a lot things that influence this. If you sell apples and you own the domain apples.com, your pretty much set anyway. Again, content sells, that is how most engines try to index.
Apart from that, in this (horrible) day and internet age, the most popular search-engines will both filter and rank the search-results to the user.. so if one wants to optimize a site for the search engine.. then for who's personal bubble (search results) do you try to optimize?!?.
I have more faith in something that was semantically coded, maintainable and has a pretty stable foreseeable future (instead of having to rebuild the same thing over and over again, every 6 months or so). Simpler put: make the core/base 'simple' enough to 'always' be rendered in a useful way and then add the spice using javascript and css-edge-technology to flavor the content.

Have you looked into node.js at all? Since your porting the view rendering to javascript anyways. It would be a little friendlier to have more components speaking the same language. Plus the asynchronous processing model releases a lot of server stress that threaded processes usually cause. Threaded processes spend a lot of time (and power) waiting to execute. But in javascript, folks usually set up callback methods. So instead of waiting for the previous process to finish, node just leaves behind a callback method to be executed when needed, meanwhile the rest of the application is still going full speed ahead.
node is really light too. You can use it along side other server side technologies and it wont take up much space. It has some pretty powerful features, but, personally, I find it best for view rendering (it's javascript after all). It also makes setting up servers and routing reeeaally easy. So setting up the stuff you mention in your 4th paragraph would be a sinch.
Anyways, that's my 2 cents.

Is there a rule of thumb size limit to the javascript libraries/plugins I want to include on my website pages? [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.
I often have the jquery library included for my page, roughly 75kb or so. Lately, I'm looking into the need to add more javascript libraries/plugins I found online, which I'm looking at adding another 25kb. In doing so, I would be concerned of adding sizes will increase the loading time for my site. Is there a 'rule of thumb' upper size limit I should be considering so I don't add any more unneeded loading time?

My rule has always been, use only what you need.
If you can achieve the goals of your application without something, don't use it. If an important feature set relies on a heavy library, use it.
Of course, no matter what, always make sure your JS files are gzip (or equivalent) compressed by your server, and use minified files as well.
Finally, it is important to keep your audience in mind. Good usage of analytics will reveal whether or not your users are tolerating your page load times.

No general rules I could suggest other than to keep it as small as is possible and don't link in libraries you don't intend to use.
If you are using common libraries, link your libraries from a common third party like the Google Libraries API. It is likely that many of your end users may already have the library versions you link from there cached in their browsers, improving their load times.

There is no limit to the size (You can have it 1GB if you wanted), but generally I'd keep it as very small as possible.
Some tips to optimize scripts:
Minify - This means shortening variable names, remove whitespaces and so on. Dean Edwards' /packer/ is an example. I'd suggest Google Closure Compiler also, but I'd reserve it for post-production phase since it will alter the code structure.
Merge - Compile your scripts so that they are contained, in the very least, only one file. This saves you a ton of HTTP requests later.
Use what you only need - If, for example, you only need a few parts of jQuery, they have an option to roll out your own jQuery (somewhere in the docs). Another example of this is jQueryUI, where you have an option to load selected UI features.

I'm not so sure about a 'rule of thumb' but you should certainly be asking yourself the following questions:
Are your scripts minified?
Are external scripts being linked externally?
Can these be linked from a CDN?
For example you're much better off letting someone else host a library like jQuery, as that lets your own server deal with only serving your content.
But most of all include only the absolute minimum you need for the functionality of your site.

It is difficult to make an estimation since we do not know what functionality your library offers. However you can compare it with jQuery. It offers so much cross browser functionality as a 30 kb file.
Every file you add to the page will take some time to transfer. It can be reduced by caching, minification,CDNs etc. Also there are approaches that bundles all JavaScript files into one. This significantly improves performance by reducing request number.

What architectural pattern(s) should I use for my RIA? [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.
I'm building a web application that interacts heavily with the DOM and need direction in making my code scalable and maintainable.
The application overview: Upon interaction, I have toolbars and overlays that guide the user to edit the page, I then send back the edited page to the server.
So far I've successfully built what I wanted but it's JQuery all tied together and I need help on how to rewrite my code to make it scalable and maintainable.
Research so far:
RequireJS - I've looked at RequireJS and thought this was a great starting point and got it all working.
JQuery - Can't get away from this awesome library.
Nicholas Zakas' presentation on Scalable JavaScript Application Architecture - Awesome idea, but how do I implement this? I'm fairly new to advanced JavaScript.
I will also need some kind of event pooling to manage all these events. If I use JQuery's built-in event pooling "bind", "trigger", will this not force me away from Zakas' idea that only my application core should have access to my JQuery library?
What type of framework should I be looking at to solve my problem?

You're actually asking more than one question. I am currently analyzing the "what framework should I use" question for our company. This entails a lot more than you think. Below is what I have so far, and as I get more details I will try to update this item.
In the meantime...
The question of architectural patterns is different from that of libraries or frameworks.
ARCHITECTURAL DESIGN PATTERNS are useful for many reasons. One reason would be to achieve loose coupling in your modules. A great example of how to achieve loose coupling is found in the Mediator Pattern.
The question of which framework to use has many decision points:
JavaScript Famework Usage
Google Trends
Comparison of JavaScript frameworks
Speed Tests:
Slick Speed
Task Speed
Write your own test like this guy did
These Are What I Consider FRAMEWORKS:
Dojo
jQuery: Is a framework only when 'umbrella' modules are included (can be used as a lone library)
YUI
Mootools
Prototype
I have decided to limit my FRAMEWORK CHOICES to:
Dojo: Toolkit, Desktop, Mobil, Graphics & Vectoring
YUI: Developer Tools, Infrastructure, Utilities, Widgets, gallery, Projects
jQuery: Core, UI, Mobil, Plugins, Graphing, Visualization
But...a breakdown of JavaScript LIBRARIES is also needed:
MVC is the most commonly used front-end pattern. However, my notes here are not yet complete. Even I am having trouble finding usage statistics on the items listed above.
Backbone.js (MVC)
Designed more toward consuming REST data. Backbone has its own event system, and thus, competes with jQuery functionality.
Spine.js (MVC)
JavaScriptMVC (MVC)
MVC integrated development tools; is used with jQuery; Highly modularized. Not yet sure if it can simply be considered a library or not...but daddy likey!
AngularJS (MVC)
Separation of concerns, loose coupling, and inversion of control. Two-way databinding
SproutCore (MVC)
YUILibrary (MVC)
This is really part of the overall YUI framework…but was listed in the original source article.
Broke.js (MVC)
Documentation is currently poor.
Fidel.js (MVC)
Sammy.js (MVC)
Designed more toward consuming REST data.
KnockoutJS (MVVM)
QUESTIONS:
Why are there so few outright MVVM implementations?
Is Two-Way Binding the same thing as MVVM?
If so, why do some of these libraries (that do two-way binding) consider themselves MVC?
MODULAR JAVASCRIPT: AMD, CommonJS and Promises-Based Implementations:
I am still outlining this area. However, below are some areas I am using for inspiration.
A previous question of mine
ARTICLE: Writing Modular JavaScript With AMD, CommonJS & ES Harmony
ARTICLE: My Thoughts on AMD
ARTICLE: Creating large-scale JavaScript Applications
PRESENTATION: AMD Patters by John Hann
Essential jQuery Plugin Patterns by Addy Osmoni
QUESTIONS:
Are there different 'flavors' of AMD (various articles seem to say yes)?
What does 'promises-based' mean?
CREATING WIDGETS & PLUGINS:
Once you decide on which flavor of AMD your modules should use you can actually begin writting something.
ARTICLE: Coding your First jQuery UI Plugin
ARTICLE: The jQuery UI Widget Factory
QUESTIONS:
What is the difference between a plugin and a widget?
GENERAL NOTES:
I would suggest looking at how each of your frameworks implement various modules. Look at the code it takes to accomplish something. Does it feel right? Does it feel clunky?
MY INITIAL FEELING:
Looking at the trends, usage, speed and vastness of community support options...jQuery is way ahead.
THE GOAL:
The final goal is to choose a framework, any/all libraries and define a general approach for loading and creating loosely-coupled JavaScript Modules.
Quantifying Cost by Risk:
Quantiying cost outright is difficult, but you can explain-away risk. In your final desicion, you should also take into account the trends listed above. But, in general, I would loosely break-up cost into 3 areas that define RISK:
Familiarity: What is your team most familiar with now?
Ramping Up: How much extra-effort would it take to get "ramped-up" on each framework and library?
Licensing: Are there any snags here?
Risk: Once assessed, you can rightfully explain WHY you might rank one option as low, medium or high.
#ErezCohen
We are an ASP.NET shop, so we use Web API for our RESTFUL backend. And since component-style JavaScript development is the future, we chose to use jQuery & RequireJS as a standard baseline on all our pages. Additionally, we make heavy use of Deferreds in our controllers.
As for client-side MVC, too many of the “frameworks” mentioned are more fads than anything else (and many have waned in use). Additionally, it made more sense to treat MVC/MVVM capabilities as a one-off add-on when requirements dictated rather than a standard. And, frankly, since we find making Ajax calls easy, brining-in vast frameworks to do simple data-binding seemed silly (the only real benefit is two-way binding for certain complex cases). Besides, think about what a pain it would be to decouple some of these frameworks once they are no longer popular.
Of course, we have the talent to do so on our own…you may not. If your crew isn’t very good with JavaScript, try Angular because it was developed for “designers” not programmers. Alternatively, if your team is capable of rolling-their-own and wants a framework for controllers then jQuery Widget Factory is useful. However, simple use of the Module Pattern for your controllers is fine too (that is what we do). And...it works great...and is VERY clean.

when a web app generate most markup by javascript ... [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 11 years ago.
I have seen a web app that generate most of a page's markup by javascript+ jquery. The server only generate a web page with just 1 DIV . The rest are done with create on client side via javascript+jquery+AJAX .
What are the pros and cons of this javascript centric approach ?

Pros:
You get a lot of flexibility when your entire front-end is in javascript. Everything is generated dynamically and it's easier to load data on demand. It also makes it easier to bind elements to data, which allows them to update automatically as things change on the server (without requiring the user to reload their browser!). Check out Backbone.js or Knockout.js for interesting approaches to building heavy javascript apps.
Going this route also allows you to keep your server very light weight. Typically, the server just has to implement a simple RESTful/JSON interface. In practice, the frontend is a single static file and it makes calls to your interface. Since you're doing these calls asynchronously while the user is on the site, it can feel much faster and more like a native app (i.e. GMail)
Another nice perk is that having the client side do more work can often decrease the load on your server. The client won't even notice the extra work, since it happens so fast, but your server might appreciate the savings. You'll also potentially use less bandwidth if you're smart about your server calls.
Cons:
Some people have javascript disabled (although in practice it's a fraction of a percent of users). Also, browser cross-compatibility can be more difficult in some edge cases (but jQuery makes this much more tolerable). The biggest con is that many web crawlers won't crawl anything on your site because crawlers generally don't execute javascript. They just parse html (Google might be an exception here?).
In my experience with building web apps, any public facing content (i.e. marketing material) should be static content so that web crawlers see it. Once the user logs into the app, I like everything to be 100% client-side with RESTful calls to my server.

Always aim to separate concerns:
Information in markup
Style in CSS
Behavior in Javascript
If you start doing everything in Javascript alone, you break that model. And the model's worked pretty well for the web so far.
That being said, do use javascript for progressive enhancement of a site. E.g. if you can display something via ajax instead a page reload, then go ahead, but a normal page request should also still work.
Check out github's repository browser for a great example of progressive enhancement. If you're using a brower that supports it, it'll load pages via ajax, and change the url in the address bar to match. Otherwise, it'll do what it's always done, and simply go to the page with a normal link. So there's javascript in there, and does some cool tricks, but everything works without it.

Con: very large javascript file
Con: if javascript turned off your site does not work
Con: harder to style
Con: large javascript file returned to client with potentially more
code than is needed
Con: possibly difficult to debug
What if your interface returns large lists, do you need to return that also and loop through that in JS and build your controls and add them?

Well, you're not exactly being quite clear when you say "generated from javascript with jquery+ajax". That could mean that flat HTML pages are just being loaded in, as opposed to requiring a browser refresh. There's no right or wrong way to structure dynamic versus static HTML; everything has to be taken in context.
jquerymobile uses this technique quite extensively.

The server should do the heavily lifting because that's what it is there for. The involvement of the client should me minimal. Client side development should focus on enhancing the UX and making sure things work nicely on many browsers. It should not be about tasks like restructuring the DOM to be a certain way, sorting and filtering through data, and so on - unless there is a compelling reason.
So offloading too much of the presentation logic on the client is probably a bad idea, in my humble opinion.

You are contrasting
Server produces data (usually JSON) -> Client-side Java Script creates HTML
Server produces data, server formats HTML -> Client renders HTML
An application can use some combination of those techniques, the former makes it easy to give dynamically updating pages with a rich user experience. You will notice that the former also offloads more work to the client (I assume that JSON is more terse than the resulting HTML) and hence in the long-term once the JavaScript is downloaded and cached the network bandwidth is reduced.
The JavaScript-centric approach is more complex and typically needs more effort to write.

What is a good book or resource for writing large ajax applications? [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.
I am very experienced in engineering large-scale systems, but I am still relatively new to ajax-based design. I know how to use the apis, and I am fairly comfortable using jquery and javascript as a whole, but I often find myself thinking way too hard about the overall architecture.
Right now, my current application just has javascript files sprinkled all over the place, all in a /js directory. Most of them use jQuery, but some use YUI or a combination between the two because the features weren't available in jQuery.
Some of my REST server methods accept normal GET methods with request parameters, but others needed much more complex POSTs to handle the incoming data (lists of lists of objects). The handling of all of my ajax stuff is a mix and mash of different methods as a result of the complexity of the data I'm dealing with.
What I'd really like is to read about how to design an ajax-based system that is very clean and elegant architecturally, and is consistent from the simplest to the most complex of cases. Does such a resource exist?
Also suggestions on naming conventions of javascript files and conventions for ajax endpoint directory/method names?
Also how to do with entering form data? Should you use get or post to do this?
Also about validation of form data when all the constraints are already on the server? How to make this very trivial to do so you're not doing it for each form?
What are the best ways to generate new page content when people click things and settings this up so that it's easy to do over and over.
How to deal with application-specific javascript files depending on each other and managing this nicely.
I am also using Spring and Spring-MVC, but I don't expect this to make much difference. My questions are purely browser related.

There's a TL;DR summary at the end.
I can't really point you to a good resource for this as I haven't found one myself. However, all is not lost. You already have experience in developing large-scale applications and taking this knowledge into the browser-space doesn't require a lot of re-thinking.
First of all, unless your application is really trivial, I wouldn't start refactoring the entire codebase straight away because there are bound to be endless cases you haven't thought of yet.
Design the core architecture of the system you want first. In your case you probably want all your AJAX requests to go through one point. Select the XHR interface from either jQuery or YUI and write a wrapper around it that takes an option hash. All the XHR calls you write for new code go through there. This allows you to switch out the framework performing the XHR calls at any time with another framework or your own.
Next up, harmonize the wire protocol. I'd recommend using JSON and POST requests (POST requests have the additional benefit for FORM submissions of not being cached). Make a list of the different types of request/responses you need. For each of these responses, make a JS object to encapsulate them. (E.g. the form submission response is returned to the caller as a FormReponse object which has accessor functions for the validation errors, etc). The JS overhead for this is totally trivial and makes it easy to change the JSON protocol itself without going through your widget code to change the access of the raw JSON.
If you're dealing with a lot of forms, make sure they all have the same structure so you can use a JS object to serialize them. Most frameworks seem to have various native functions to do this, but I'd recommend rolling your own so you don't have to deal with shortcomings.
The added business value at this point is of course zero because all you have is the start of a sane way of doing things and even more JS code to load into your app.
If you have new code to write, write it on the APIs you've just implemented. That's a good way to see if you're not doing anything really stupid. Keep the other JS as it is for now but once you have to fix a bug or add a feature there, refactor that code to use your new APIs. Over time you'll find that the important code is all running on your APIs and a lot of the other stuff will slowly become obsolete.
Don't go overboard with re-inventing the wheel, though. Keep this new structure limited to data interaction and the HTTP wire and use your primary JS framework for handling anything related to the DOM, browser quirks, etc.
Also set up a global logger object and don't use console directly. Have your logger object use console or a custom DOM logger or whatever you need in different environments. That makes it easy to build in custom log levels, log filters, etc. Obviously you have to set up your build environment to scrub that code out for production builds (you do have a build process for this, right?)
My personal favorite for relatively sane JS source-code layout and namespacing is the Dojo framework. Object definitions relative to their namespace have obvious relations to their location on disk, there's a build system in place for custom builds, third-party modules, etc. The Dojo dependency/build system depends on dojo.require and dojo.provide statements in the code. When running on source a dojo.require statement will trigger the blocking load of the resource in question. For production the build system follows these statements and inserts the resource into the final bundle at that location. The documentation is a bit sparse, but it's definitely a good start for inspiration.
The TL;DR answer is,
Have all XHR calls go through a single interface
Don't pass raw response data back to higher levels
Do gradual refactoring of existing code
Harmonize the wire protocol
Use the dynamic power of JS for building light-weight proxy code
Sane code structure and call graphs look the same in JS as they do in other languages

Ajax Patterns is a pretty awesome book/site: http://ajaxpatterns.org/
Otherwise you may want to check out Advanced Ajax Architecture Best Practices
How you go about designing your site should be based on the features and size of your app. I would keep your focus there as opposed to looking for a architecture that works for all cases.