Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Developer Center > What web development tools do you use?

What web development tools do you use?
Thread Tools
besson3c
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 3, 2009, 08:29 PM
 
This is a thread for advanced web programmers/developers. Sorry to be exclusionary, but I just don't want this thread to get into iWeb, Dreamweaver, ImageReady, Rapidweaver, and the like... There are other threads for these sorts of more entry level tools, and general graphic design threads too.

It's a pretty exciting time to be a web developer, but it's also pretty overwhelming. There is just so much stuff out there, so much fragmentation, different tools and techniques we employ. I always encourage people to document like crazy, because the chances of finding somebody with the same precise skill set as you and the same coding styles and practices is slim to none. There are too many different toolkits, commenting and code structuring approaches, organizational techniques, version control systems, layout and templating techniques, CMSes, etc. to count on this. Thus, I always try to set aside time to learn some new and easier ways to do things, and would like to think that I could step in and be useful in most places providing things were documented. What sorts of techniques and practices help you get through picking up somebody else's project where the code was lacking and/or incomplete?

I'm also wondering what sorts of tools you guys like using... For me, I'm kind of dialed into:

- Prototype
- Scriptaculous
- JSON
- WordPress
- Modalbox
- TinyMCE (although the rich text editor provided by Yahoo's YUI libs looks pretty good too)
- use of background sprites
- separation of code from layout (external event listeners, no inline stuff, semantic markup, etc.)
- object oriented PHP and Javascript
- Git
- FreeBSD
- font embedding
- Mediawiki for organizing stuff
- RT for tracking time spent
- the Yahoo CSS reset library
- Actionscript

I'm starting to get into Yahoo's YUI, there is a lot of cool stuff there. Some day I will have to take a better look at Ruby on Rails, jQuery, extjs, perhaps a different CMS such as Expression Engine.

What are some of your favorite tools? I'd be happy to post examples of some my utilization of these tools if anybody cares, but feel free to do the same where you've done so in a creative way, something that really saved you a lot of extra work, something cool and unusual that would entice me to want to try the tools you use
( Last edited by besson3c; Aug 4, 2009 at 03:09 AM. )
     
shifuimam
Addicted to MacNN
Join Date: Aug 2006
Location: Somewhere in the Pacific Northwest
Status: Offline
Reply With Quote
Aug 4, 2009, 02:14 AM
 
Dreamweaver isn't necessarily just for noobs. At my current job, we do stuff primarily in ColdFusion, and it's simply much, much faster to write CF in Dreamweaver because it has auto tag completion and brings up the properties of CF tags automagically, much like how Visual Studio does with C#, VB, etc. I never touch the graphical stuff in Dreamweaver. I use it solely for writing source code manually.

Mediawiki can be pretty painfully slow...there are smaller wiki packages out there that might be worth considering, depending on your needs. Likewise, TinyMCE can be a real bitch to work with, because the markup it creates is horribly messy (and completely not standards-compliant). I know that there are some other JavaScript WYSIWYG text editors out there, although I haven't really looked into them much yet.

I think there are problems with the way web development and design is currently done. People are overly concerned with doing things that are super sexy or super JavaScript (AJAX is quite popular these days). The result is that you end up with sites that are less accessible to disabled users and don't work in some browser situations (mobile platforms, older browsers, etc.). It also can really slow things down - too much JavaScript in older versions of Firefox slow it to a crawl. Gmail's design changed significantly, and it now takes longer for your inbox to load. It's just annoying and generally unnecessary.

Some of the stuff you've mentioned really has little to do with development. The stuff one accomplishes with large JS frameworks is almost entirely on the design side. Things like Wordpress and Mediawiki aren't really developer tools; anyone can install either one in about fifteen seconds if the permissions on the site directory are set up correctly, and you never have to know a lick of PHP or MySQL to administer them.
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 4, 2009, 03:08 AM
 
Originally Posted by shifuimam View Post
Dreamweaver isn't necessarily just for noobs. At my current job, we do stuff primarily in ColdFusion, and it's simply much, much faster to write CF in Dreamweaver because it has auto tag completion and brings up the properties of CF tags automagically, much like how Visual Studio does with C#, VB, etc. I never touch the graphical stuff in Dreamweaver. I use it solely for writing source code manually.
I hear you, but I just don't understand how it is smart to shell out the bucks for a text editor so that you can have auto tag completion. You can get this in other less pricey and/or free editors.

I was referring to the WYSIWYG stuff that Dreamweaver was originally built for though...

Mediawiki can be pretty painfully slow...there are smaller wiki packages out there that might be worth considering, depending on your needs. Likewise, TinyMCE can be a real bitch to work with, because the markup it creates is horribly messy (and completely not standards-compliant). I know that there are some other JavaScript WYSIWYG text editors out there, although I haven't really looked into them much yet.
Messy, yes... I've seen a lot of <strong></strong> sort of stuff, but non standards compliant, not so much, not with recent versions anyway. What versions have you been using?

I think there are problems with the way web development and design is currently done. People are overly concerned with doing things that are super sexy or super JavaScript (AJAX is quite popular these days). The result is that you end up with sites that are less accessible to disabled users and don't work in some browser situations (mobile platforms, older browsers, etc.). It also can really slow things down - too much JavaScript in older versions of Firefox slow it to a crawl. Gmail's design changed significantly, and it now takes longer for your inbox to load. It's just annoying and generally unnecessary.
I think that we haven't really figured out how to write good AJAX apps yet, but we're getting there. With dynamic loading of libraries (something that Yahoo YUI does a good job of), and caching of AJAX requests you can actually do stuff much faster than reloading the entire page, it just depends on how the page is designed. You can also delay the loading of images so that they load after your content is loaded, which can also boost responsiveness a great deal when applied appropriately.

As far as people with disabilities and older browsers and stuff, yes, that is always a challenge AJAX or no, as is SEO friendly content. There are ways around this though. All in all, the net gains of AJAX applications outweigh the cons, IMHO. Really, the way I see things going we could do away with complete page loads, and replacing it with loading pieces dynamically via AJAX. As our tools mature I anticipate this is exactly where we will go. It may be that we need some sort of new protocol though, as AJAX is really sort of a hack to work around the fact that http was designed to fetch complete pages.

Some of the stuff you've mentioned really has little to do with development. The stuff one accomplishes with large JS frameworks is almost entirely on the design side. Things like Wordpress and Mediawiki aren't really developer tools; anyone can install either one in about fifteen seconds if the permissions on the site directory are set up correctly, and you never have to know a lick of PHP or MySQL to administer them.
They fit into my overall workflow though, which is what I was getting at. If you consider Prototype a large JS framework, it is very much utilized on the coding side. I probably write more Prototype API code than pure Javascript these days for event listeners, working with JSON (another technology I should have added to my original list), modifying DOM nodes dynamically, etc.
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Aug 4, 2009, 04:17 AM
 
I don't have much to add to the discussion as of now, but for CMSs I have become a believer in ExpressionEngine.

Besson, I think your comment on moving away from HTTP makes sense because the web isn't static anymore and pages shouldn't be treated as such. What would a replacement for HTTP look like?

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Aug 4, 2009, 04:26 AM
 
HTTP wasn't meant to fetch complete pages — it's a general protocol for loading arbitrary resources. Whether that resource is a page, a page fragment or even something far removed from being a Web page (take a look at CouchDB for example), it doesn't make a difference from the standpoint of HTTP. So I don't see why it's insufficient.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 4, 2009, 05:33 AM
 
Big Mac and Chuckit: I don't think we need to replace anything, we just need to rethink Javascript. Pure Javascript is quite burdensome, most apps barely speak pure Javascript now, it's usually jQuery or Prototype or something like it. With these toolkits we can make making AJAX calls really simple, but some of this ought to be reworked into the next major iteration of Javascript so that we can standardize on syntax.

Javascript needs some of these very standard DOM manipulation and inspection techniques built in, these are immensely useful. As well, it should handle page caching, making cross browser AJAX requests, creating external event observers, AJAX browser history, and JSON parsing. The rest - animation, creating modal dialogs, etc. can be handled by third party Javascript toolkits since everybody is going to want to do theses sorts of things a little differently, but the basic utilitarian stuff I've listed that every app needs should probably eventually become a part of Javascript.

The problem, as of now, is that toolkits like Prototype, jQuery, YUI, extjs, etc. each want to do some of this stuff differently with a different syntax, a different namespacing, and just a different style overall. Prototype, for instance, is very Ruby-esque. There is also Actionscript to consider too, which is fairly Javascript-like.

Fortunately you can have multiple toolkits loaded simultaneously without creating conflicts, but then you have some wheel recreation going on.

So, just make plain vanilla Javascript more useful and I think you'll have taken care of this problem. Like I said, in a matter of time we'll probably be able to ditch our refresh buttons. We'll just load the first page in its entirety and load everything else dynamically.
     
shifuimam
Addicted to MacNN
Join Date: Aug 2006
Location: Somewhere in the Pacific Northwest
Status: Offline
Reply With Quote
Aug 4, 2009, 02:22 PM
 
Part of the issue I have with JavaScript frameworks is that they've become the new Flash - people use them because it's sexier and slicker, even when it's completely unnecessary.

For instance, I've seen sites that rely on JavaScript for the site navigation. This is a horrible use of JS. The browser navigation (back button, history, etc.) doesn't work reliably, and sometimes the site just quits working entirely (this happened with OKCupid all too frequently until they fixed it). In fact, OKC is a great example of JS frameworks gone horribly, horribly wrong. That site uses JS for everything, and it's a really bad thing. It hurts the general usability of the site.

Designers seem to think that users seeing a page load at all is now poor design. This is just a poor way of looking at things. Sometimes, you're better off reloading the page, or directing the user to a new page, or whatever else. I've found AJAX to be handy for realtime form validation - for instance, in many of the web applications I create at work, the end user will have to put in the user ID of a university student, faculty member, or employee. I can use AJAX to validate that the user ID exists and that it belongs to the person the user thinks it belongs to.

On the other hand, relying on JavaScript for things like navigation is just shitty design.

Not only that, but the current frameworks are huge, and many times you don't need 90% of the frameworks' functionality. I'd like to see a modular framework that allows you to easily enable or disable JavaScript files that provide certain functionality. If I'm only using a framework to add and remove form elements, I don't need all the other crap. Admittedly, using these frameworks does streamline parts of the development process, but I think it also ends up creating lazy devs who don't actually know how to use JavaScript anymore. I could use Prototype or JQuery (we use JQuery at work, btw) to enable toggling the visibility of an element on the page, or I can write a very small script myself to do it. If that's the only JS functionality I need, using a framework is just hardcore overkill.
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Aug 4, 2009, 02:53 PM
 
Shifuimam, check out MooTools. It lets you download components a la carte. The core library is 4 KB. The Request class (for AJAX) and its dependencies add up to 34 KB.

Personally, even in cases where Jquery is hardcore overkill, if it's overkill that saves me time, screw it — I'm using Jquery.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Aug 4, 2009, 03:05 PM
 
Do Prototype and Jquery serve different purposes, or do they overlap? This is the first time I've heard of them admittedly.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Aug 4, 2009, 03:32 PM
 
They overlap a lot. The difference is more how you use them than what you use them for. It's kind of like Python and Ruby — they're incredibly similar and share a lot of the same strengths, but there's a big enough philosophical difference between them that they each have their own fans.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 4, 2009, 03:52 PM
 
Originally Posted by shifuimam View Post
Part of the issue I have with JavaScript frameworks is that they've become the new Flash - people use them because it's sexier and slicker, even when it's completely unnecessary.

For instance, I've seen sites that rely on JavaScript for the site navigation. This is a horrible use of JS. The browser navigation (back button, history, etc.) doesn't work reliably, and sometimes the site just quits working entirely (this happened with OKCupid all too frequently until they fixed it). In fact, OKC is a great example of JS frameworks gone horribly, horribly wrong. That site uses JS for everything, and it's a really bad thing. It hurts the general usability of the site.
No, it's a *fantastic* use of Flash, with all due respect. Whatever problems existed were likely to do their implementation.

Using Javascript for navigation provides faster loading of content (once you've loaded the first page), the ability to cache, progress bars/feedback, and the ability to animate content. It's basically giving you all of the coolness of Flash save super elaborate animation minus all of the headaches of Flash.

The major weakness with this is browser history, like you said, although YUI provides a browser history library that makes use of anchor tags to represent page loads. If we can sort out a safe and secure way to provide bookmarkable pages that won't becoming phishing nightmares, we can leave reloading entire pages in the dust.

Designers seem to think that users seeing a page load at all is now poor design. This is just a poor way of looking at things. Sometimes, you're better off reloading the page, or directing the user to a new page, or whatever else. I've found AJAX to be handy for realtime form validation - for instance, in many of the web applications I create at work, the end user will have to put in the user ID of a university student, faculty member, or employee. I can use AJAX to validate that the user ID exists and that it belongs to the person the user thinks it belongs to.
I disagree... You are better off reloading the page if there is no net gains to putting in this time to not do so, or if the browser history issue is burdensome, and this often the case, but otherwise there is no real technical benefit to reloading an entire page. You can fetch whatever you need, including changing which div blocks are assigned to which classes all dynamically.

Most sites can make use of a framework like Prototype, because it is rare that you write a site that has absolutely no justifiable need to use Javascript (form validation feedback, managing event handlers, whatever). Prototype makes doing many things easier and less annoying.

On the other hand, relying on JavaScript for things like navigation is just shitty design.
Not so, it's the way of the future. You just don't see it yet.

Not only that, but the current frameworks are huge, and many times you don't need 90% of the frameworks' functionality. I'd like to see a modular framework that allows you to easily enable or disable JavaScript files that provide certain functionality. If I'm only using a framework to add and remove form elements, I don't need all the other crap. Admittedly, using these frameworks does streamline parts of the development process, but I think it also ends up creating lazy devs who don't actually know how to use JavaScript anymore. I could use Prototype or JQuery (we use JQuery at work, btw) to enable toggling the visibility of an element on the page, or I can write a very small script myself to do it. If that's the only JS functionality I need, using a framework is just hardcore overkill.
jQuery and Prototype are Javascript, just extensions of Javascript. The concepts are the same, the problems and challenges are the same. Pure Javascript is just too long in the tooth to be useful anymore. Look at just about any site and you have a parade of CSS and Javascript libraries in the HEAD tag. You're right that there is getting to be a lot but that is testament to the general lacking of vanilla Javascript. One way around having to load each library at initial load is dynamic loading, like I said, but otherwise it is hard making the argument that it is better to wrestle with IE 6 than use Yahoo's reset CSS library (or anything like it), better to have a lot of long and arcane vanilla Javascript that attempts to be cross browser and ends up being much longer and more complicated in length when all of this sort of hard slogging is already done for you. Why write in assembly language when you can write in Objective C or Ruby or something much nicer?
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Aug 4, 2009, 04:06 PM
 
I think it's better to compare vanilla Javascript to vanilla Objective-C, without any OpenStep-like class library. You can write an Objective-C program without using Cocoa at all, but why would you want to?

The problem for Javascript, though, is that there isn't even a de facto standard library. Some people use Prototype/Scriptaculous, some use JQuery, MooTools, Dojo, etc. If you standardize on one of them, you wind up with a standard library that's only used half the time — you haven't really solved anything except how to piss off half your users.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 4, 2009, 04:06 PM
 
Shif, this site is still a work in progress (and the graphic design is not my doing, so like it or lump it), but here is a great example of where Prototype can really shine:

Clovertone Music: Store

Do you really want to have to reload the entire page each time as you move in between pages? When you click on one of the grade or genre icons? It takes less than a second now on my non-production staging server, it would take at least a couple to reload the entire page, not to mention to reinit all of the observers and re-render everything that has already been loaded.

When you click on one of the grade/genre icons I ghost the current one, un-ghost the rest. That would be incredibly awkward to do in vanilla Javascript unless I wanted to forgo using a loop, but it is super easy to do in Prototype using each(). There are a gazillion event listeners throughout the site, dropdown menus (which people seem to request frequently) made easier with this toolkit, a lot of AJAX, caching, passing values between PHP and Javascript via JSON, use of Prototype hashes for storing things, dynamic class removal/addition, etc. I don't think this design is particularly unusual, yet I simply can't imagine doing it in vanilla Javascript, it would be a nightmare. I decided not to make the entire nav AJAX, because there is not a great reason to put in this time, most of the time will probably be spent in the store.

How about the whole login system. Why take the user off the page to do something like this, something like the advanced search feature, or watch that promo video? The whole modal dialog thing is quite popular, and many of these require a toolkit (although not all). At any rate, more Javascript, yet it adds a lot.

I know this is a bit of a strawman because you aren't arguing against Javascript in general, but my point is once you immerse yourself there you might as well make it easy on yourself and really take care of business to make your sites as functional as you can utilizing all which these toolkits make easy to do.
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 4, 2009, 04:12 PM
 
Originally Posted by Chuckit View Post
I think it's better to compare vanilla Javascript to vanilla Objective-C, without any OpenStep-like class library. You can write an Objective-C program without using Cocoa at all, but why would you want to?

The problem for Javascript, though, is that there isn't even a de facto standard library. Some people use Prototype/Scriptaculous, some use JQuery, MooTools, Dojo, etc. If you standardize on one of them, you wind up with a standard library that's only used half the time — you haven't really solved anything except how to piss off half your users.
Which is why I proposed taking the greatest hits from each of these and reworking them back into vanilla Javascript.

I'd like to think that I could figure out jQuery or something like it though, the concepts are not worlds apart. Still, in today's day and age people expect these sorts of features in their sites, and honestly you'd probably have an easier time finding somebody who could understand the jQuery/Prototype/Dojo/whatever than the vanilla Javascript.
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 4, 2009, 04:15 PM
 
Originally Posted by Chuckit View Post
They overlap a lot. The difference is more how you use them than what you use them for. It's kind of like Python and Ruby — they're incredibly similar and share a lot of the same strengths, but there's a big enough philosophical difference between them that they each have their own fans.
One of the main and important differences between the two is documentation, which many say Prototype is lacking compared to jQuery.
     
mduell
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status: Offline
Reply With Quote
Aug 4, 2009, 07:01 PM
 
FreeBSD
Apache / Rivet
jQuery
vi
     
shifuimam
Addicted to MacNN
Join Date: Aug 2006
Location: Somewhere in the Pacific Northwest
Status: Offline
Reply With Quote
Aug 8, 2009, 06:55 AM
 
Originally Posted by besson3c View Post
The major weakness with this is browser history, like you said, although YUI provides a browser history library that makes use of anchor tags to represent page loads. If we can sort out a safe and secure way to provide bookmarkable pages that won't becoming phishing nightmares, we can leave reloading entire pages in the dust.

...

I disagree... You are better off reloading the page if there is no net gains to putting in this time to not do so, or if the browser history issue is burdensome, and this often the case, but otherwise there is no real technical benefit to reloading an entire page.
Browser history is HUGE. It's not just a little side thing, like being able to use your tab key to navigate around the page, or whether or not a section can be collapsible. A website is useless to me if it breaks my back button and provides no actual browser history, since it's reloading the same page over and over.

I browse the web heavily. I frequently come across interesting stuff, and I end up closing the tab for whatever reason. Later, I can use Firefox's search function in the history to find it. If the site is all-JS for navigation, and there is no history, wtf am I supposed to do, waste an hour going through the site trying to recover whatever it was I originally found?

Not to mention how you're going to handle SEO when all your content is loaded as a result of client-side interactions with the navigation. And, of course, it's harder to link to pages that you want to share with other people.

Yes, there may be solutions out there for these problems, but the fact is, there aren't any established methods yet, which means that sites that insist on using JS navigation are hardcore screwing over their users.

Unfortunately, that dev site you linked me to isn't a particularly good use of JS in my opinion. I hate, hate, hate, hate using websites that pull that crap. Your navigation and method of loading content has rendered my back button on my mouse, keyboard, and browser worthless. It provides no usable browser history, and it makes it impossible for me to link a friend to a product on your site. Yes, I can right-click on a link and hit "copy link location", but if you're going to have that, why even both using JS to load the content?

It's gotten to the point where web designers and developers are convinced that it's inexcusable for the user to ever see their page reload or "blink" as they're navigating through content. Much like how we expect to see a nanosecond of black as we change channels on the television, users fully expect and understand that when browsing an extremely link-heavy site like an e-commerce site, there will be lots of reloads. If you're having problems with that making the site usable, you need to look into your server and network performance, and the efficiency of your backend code - not trying to use JavaScript to cobble together half-assed navigation that's barely really navigation at all (in the context of web browsing).

Most sites can make use of a framework like Prototype, because it is rare that you write a site that has absolutely no justifiable need to use Javascript (form validation feedback, managing event handlers, whatever). Prototype makes doing many things easier and less annoying.
I've found precious little reason to use any JavaScript framework so far in my work as a web developer. I had a customer who wanted the ability to add and remove form fields at will, so I did what he wanted. Performance was balls in Firefox 1.5, which I was still using as my primary browser at the time (I was unhappy with some features of 2.0, and 3.0 wasn't even in beta yet).

Why even bother doing form validation with JavaScript? You're going to have to write server-side validation regardless, in case the user doesn't have JavaScript enabled in their browser. I see no reason to waste the time writing the same functionality twice just so that my user can save a microsecond of time by not waiting for the page to reload.

I'd much rather deal with content and interactions on a site with server-side code that I know for a fact will behave the exact same way in every browser, rather than relying on JavaScript, which may or may not work as expected depending on the client's environment.

You can no longer assume that everyone is using IE, Firefox, and Safari. Instead of worrying about people on archaic computer hardware, you now have to account for people using devices other than traditional computers to access the Internet. What about people who use video game consoles to look up stuff online? What about smartphones and even WAP-enabled phones? What about netbooks? There are plenty of sites out there that don't really take into account the 1024x600 viewport of your standard netbook. If I have to scroll down substantially to get to my content because the header and navigation are so vertically large, I'm probably not going to waste my time on that site.

Not so, it's the way of the future. You just don't see it yet.
I disagree. It's more of a trendy, overhyped way to do things right now, much like Ruby on Rails, which I've recently been reading about - it seems like the singular most bass-ackwards way to develop a web application. I realize that web design conventions are constantly evolving, but you can't completely eschew something as critical as usable navigation (e.g. bookmarking, site history, permalinks, etc.) until you have a fully workable alternative solution.

Don't use JS for your navigation if you're not going to accommodate for the fact that it allows no way to navigate backward and forward in your site or even link to specific pages. If you want to handle that with querystrings or page anchors or whatever else, go right ahead - but the way that music site you linked to is right now is just poor design. In a cyberworld where people are constantly passing URLs on that they find interesting, through venues such as Twitter and StumbleUpon, you're asking for trouble if you're not going to give the user easily-accessible permalinks to your content.

...better to have a lot of long and arcane vanilla Javascript that attempts to be cross browser and ends up being much longer and more complicated in length when all of this sort of hard slogging is already done for you.
It really depends on what you're doing. If you only need a tiny piece of JS functionality, why use an entire framework to do so? That would be like using Microsoft Word when Notepad or TextEdit would suffice for your specific needs. It's overkill.

Why write in assembly language when you can write in Objective C or Ruby or something much nicer?
No, it's more like "why do people still write batch files and shell scripts when they could write a full-on compiled binary application?". You don't always need the extensive functionality provided by a framework. The files are large, which means that download times are slow on limited connections - like EDGE, which more and more people use to access the Internet, thanks to the iPhone's explosive popularity and AT&T's lack of 3G in many areas of the United States.

JavaScript has its uses, but it's not the end all, be all in website design and development. It's much like CSS - there are people who are *such* purists that they refuse to use HTML tables for any single piece of content in a website. The fact is, there are still things that tables are good for - like, you know, tables full of data.
     
shifuimam
Addicted to MacNN
Join Date: Aug 2006
Location: Somewhere in the Pacific Northwest
Status: Offline
Reply With Quote
Aug 8, 2009, 07:11 AM
 
I should add that with your site, I'm not seeing any actual difference in behavior between JavaScript and no JavaScript:

YouTube - navigation

The first half is without JavaScript. The second half is with it - there's no little fade in/out effect because apparently that doesn't work if you've already navigated to that content in your browser session.
( Last edited by shifuimam; Aug 8, 2009 at 07:21 AM. )
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Aug 8, 2009, 12:26 PM
 
Originally Posted by shifuimam View Post
Unfortunately, that dev site you linked me to isn't a particularly good use of JS in my opinion. I hate, hate, hate, hate using websites that pull that crap. Your navigation and method of loading content has rendered my back button on my mouse, keyboard, and browser worthless.
Some might argue that having to reload an entire graphic-heavy site for such a small bit of content has more of a negative affect on people than just making people click on the thing they wanted to see again instead of the back button. I agree that killing the back button sucks, but loading times suck too. I would like a happy middle.

Originally Posted by shifuimam View Post
Much like how we expect to see a nanosecond of black as we change channels on the television, users fully expect and understand that when browsing an extremely link-heavy site like an e-commerce site, there will be lots of reloads.
Much like how I expect that when I go to the DMV, there are going to be hugely long lines. That doesn't mean I'm looking forward to them wasting my time, just that I expect them to abuse me in that way.

Originally Posted by shifuimam View Post
If you're having problems with that making the site usable, you need to look into your server and network performance
With so many sites hosted in a virtualized environment these days, this isn't necessarily something I can control as much as I'd need to in order to squeeze every last ms out of it.

Originally Posted by shifuimam View Post
I disagree. It's more of a trendy, overhyped way to do things right now, much like Ruby on Rails, which I've recently been reading about - it seems like the singular most bass-ackwards way to develop a web application.
Wait, what? Lack of repetition and verbosity is bass-ackwards? Modular code is backwards? Rapid development? OK, so you hate well-factored code, immediate feedback and sites that are nice to use — where do you stand on cute little puppies?

Originally Posted by shifuimam View Post
No, it's more like "why do people still write batch files and shell scripts when they could write a full-on compiled binary application?".
That is a good comparison. The reason is: "Because it's easier." Not because of some impractical, philosophical love of batch files — it's just easier. And that's the same reason they use Javascript frameworks.

Originally Posted by shifuimam View Post
You don't always need the extensive functionality provided by a framework. The files are large, which means that download times are slow on limited connections - like EDGE, which more and more people use to access the Internet, thanks to the iPhone's explosive popularity and AT&T's lack of 3G in many areas of the United States.
So before it was "I see no reason to waste the time writing the same functionality twice just so that my user can save a microsecond of time by not waiting for the page to reload," but now all of a sudden the loading time is supposed to be a valid argument against Javascript? You can't have it both ways. Also, a minified JQuery takes up about as much bandwidth as your average transparent PNG.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Aug 8, 2009, 12:29 PM
 
Oh, just to make shifuimam scream: Cappuccino Web Framework - Build Desktop Class Applications in Objective-J and JavaScript

Now that is excessive. And yet somehow kind of neat.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
shifuimam
Addicted to MacNN
Join Date: Aug 2006
Location: Somewhere in the Pacific Northwest
Status: Offline
Reply With Quote
Aug 8, 2009, 12:47 PM
 
Originally Posted by Chuckit View Post
Some might argue that having to reload an entire graphic-heavy site for such a small bit of content has more of a negative affect on people than just making people click on the thing they wanted to see again instead of the back button. I agree that killing the back button sucks, but loading times suck too. I would like a happy middle.
The thing is, even with super media-heavy sites, you don't really see long load times anymore unless the infrastructure of that server is having problems. Browsers have gotten much, much better at caching content, which is why in my above video you weren't seeing any page reloads at all as I navigated the site without JavaScript.

My own LiveJournal is a good example, because it's super image-heavy. Once the page loads (which doesn't take that long and is dependent on LJ's performance, which is sketchy at certain times of the day), the sidebar, background images, and top navigation and header don't blink at all, because the browser has cached all that information.

Much like how I expect that when I go to the DMV, there are going to be hugely long lines. That doesn't mean I'm looking forward to them wasting my time, just that I expect them to abuse me in that way.
An inevitably long wait is not the same as seeing the page blink. It's not even really a case of "time wasted" - it's more the visual aesthetic. Sure, you can make something look prettier with JavaScript, but is it worth it if you have to sacrifice core usability of your site?

With so many sites hosted in a virtualized environment these days, this isn't necessarily something I can control as much as I'd need to in order to squeeze every last ms out of it.
Although I understand what you're saying, it's worth noting that virtualization gives you more control rather than less - you can spend a little extra to get more RAM or disk space allocated to your VPS, whereas with shared hosting you're at the mercy of the host to do these upgrades.

But, again - with the way that caching works these days, browsers are damn fast without needing JavaScript to load your content for you (rather than the traditional way of loading pages).

Wait, what? Lack of repetition and verbosity is bass-ackwards? Modular code is backwards? Rapid development? OK, so you hate well-factored code, immediate feedback and sites that are nice to use — where do you stand on cute little puppies?
Thanks for twisting my words around. Look, I haven't done any RoR development myself; I've just been looking through the "getting started" stuff. Its way of dealing with databases looks unpleasant to me. I already know SQL at a pretty advanced level; I don't want something else writing complex queries for me, since it would take more time to tell it what I need than to just write the query myself.

ColdFusion is plenty modular itself. I love CF. I've been developing almost exclusively with it for the past year and a half, and it's light years ahead of PHP. It has its disadvantages - just like any web development platform, including RoR - but it's fantastic for very fast web development and avoiding rewriting the same code over and over.

RoR isn't the messiah of the web development world. I get a little annoyed with people who worship it like it's the only real solution to everyone's development needs.

That is a good comparison. The reason is: "Because it's easier." Not because of some impractical, philosophical love of batch files — it's just easier. And that's the same reason they use Javascript frameworks.
True, but I'm talking about people who use these frameworks liberally while making use of only .01% of the functionality they provide - as in my previous example, if you're just trying to show/hide elements on a page, you don't need an entire framework for that. You need about ten lines (if your format your code properly) of JS to do that. Not an entire framework. It can (I'm not saying it unilaterally is) be overkill to use a framework instead of writing your own damn code (or copying and pasting it from someone else, which is what I did when I first learned how to implement that particular functionality on my page).
     
shifuimam
Addicted to MacNN
Join Date: Aug 2006
Location: Somewhere in the Pacific Northwest
Status: Offline
Reply With Quote
Aug 8, 2009, 12:52 PM
 
Originally Posted by Chuckit View Post
Oh, just to make shifuimam scream: Cappuccino Web Framework - Build Desktop Class Applications in Objective-J and JavaScript

Now that is excessive. And yet somehow kind of neat.
Oh...wow.

Their Flickr demo (http://objective-j.org/learn/demos/FlickrPhotoDemo/)...

You see that "Interesting photos" link up near the top left? Yeah, it's in eleven layers of DIV elements.

And the source behind it is super attractive:



They've apparently never heard of using an external CSS file.
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Aug 8, 2009, 01:01 PM
 
Well, it's all generated code, which usually means inline CSS. They didn't hand-write the eleventy billion divs. That's also why the inline CSS attributes are repeated every step rather than being allowed to cascade naturally. It's still nuts, though.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 8, 2009, 03:41 PM
 
Originally Posted by shifuimam View Post
I should add that with your site, I'm not seeing any actual difference in behavior between JavaScript and no JavaScript:

YouTube - navigation

The first half is without JavaScript. The second half is with it - there's no little fade in/out effect because apparently that doesn't work if you've already navigated to that content in your browser session.
The instant load w/o fade in/out is loading a cache stored in a Prototype hash. I'm not sure what you mean by "without Javascript"?
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 8, 2009, 04:06 PM
 
Originally Posted by shifuimam View Post
Browser history is HUGE. It's not just a little side thing, like being able to use your tab key to navigate around the page, or whether or not a section can be collapsible. A website is useless to me if it breaks my back button and provides no actual browser history, since it's reloading the same page over and over.

I browse the web heavily. I frequently come across interesting stuff, and I end up closing the tab for whatever reason. Later, I can use Firefox's search function in the history to find it. If the site is all-JS for navigation, and there is no history, wtf am I supposed to do, waste an hour going through the site trying to recover whatever it was I originally found?
The lack of a back button is a serious tradeoff, you are right. This is why I'm anxious to utilize Yahoo's browser history lib as soon as I can. However, there are users that can't stand having their entire page reload for every little thing. On mobile phones and slower computers this can take *forever*, and when you are flipping through content in a hurry this can be a huge turnoff. I guess it just depends on the nature of your content. Some content doesn't really need to be bookmarkable. For instance, on many of my sites the Contact link triggers a Modalbox window so that they can contact the person from anywhere on the site. A simple contact form usually doesn't need to be bookmarkable, unless you like contacting that person via their website a whole hell of a lot

I use this same Ajax reload/cache technique on a number of my musician sites so that we can have a global media player that can play uninterrupted as we move in between pages. This is far more elegant than an iframe or a popup window, and since most musician sites only have a handful of pages, giving up the bookmarking ability is usually worthwhile here.

Not to mention how you're going to handle SEO when all your content is loaded as a result of client-side interactions with the navigation. And, of course, it's harder to link to pages that you want to share with other people.
The former is manageable by use of external event observers and URL parsing.


Unfortunately, that dev site you linked me to isn't a particularly good use of JS in my opinion. I hate, hate, hate, hate using websites that pull that crap. Your navigation and method of loading content has rendered my back button on my mouse, keyboard, and browser worthless. It provides no usable browser history, and it makes it impossible for me to link a friend to a product on your site. Yes, I can right-click on a link and hit "copy link location", but if you're going to have that, why even both using JS to load the content?
It's not impossible, I would just have to include a cut and pastable URL somewhere or make use of the browser history lib... This is not ideal, but then again, anybody that comes across an embedded video is used to some sort of widget that spits out a direct URL/permalink.

I've found precious little reason to use any JavaScript framework so far in my work as a web developer. I had a customer who wanted the ability to add and remove form fields at will, so I did what he wanted. Performance was balls in Firefox 1.5, which I was still using as my primary browser at the time (I was unhappy with some features of 2.0, and 3.0 wasn't even in beta yet).
What do you use Javascript for? How good is your Javascript coding? Trust me, when you find a complicated enough thing, vanilla Javascript is near torture. Try making an AJAX request with your own custom callback. It can be done, but it will take you a while to figure this out. Trust me, I've been there

Why even bother doing form validation with JavaScript? You're going to have to write server-side validation regardless, in case the user doesn't have JavaScript enabled in their browser. I see no reason to waste the time writing the same functionality twice just so that my user can save a microsecond of time by not waiting for the page to reload.
Why not? You could tell the user that the two email addresses they typed don't match or that they typed an invalid username or whatever immediately, and it's not hard and has no real downsides. Maybe not everybody is as patient as you?

I'd much rather deal with content and interactions on a site with server-side code that I know for a fact will behave the exact same way in every browser, rather than relying on JavaScript, which may or may not work as expected depending on the client's environment.
All the more reason to use a toolkit so that you don't have to worry about these sorts of cross browser problems. I never depend on Javascript for form validation, but it's a very nice addition.

You can no longer assume that everyone is using IE, Firefox, and Safari. Instead of worrying about people on archaic computer hardware, you now have to account for people using devices other than traditional computers to access the Internet. What about people who use video game consoles to look up stuff online? What about smartphones and even WAP-enabled phones? What about netbooks? There are plenty of sites out there that don't really take into account the 1024x600 viewport of your standard netbook. If I have to scroll down substantially to get to my content because the header and navigation are so vertically large, I'm probably not going to waste my time on that site.
You lost me. Wouldn't those people with slow connections be the greatest benefactors of not reloading the page constantly?


I disagree. It's more of a trendy, overhyped way to do things right now, much like Ruby on Rails, which I've recently been reading about - it seems like the singular most bass-ackwards way to develop a web application.
How is Ruby bass-ackwards? If you have never had to develop a complicated enough site that really challenged your vanilla Javascript chops, I envy you

No, it's more like "why do people still write batch files and shell scripts when they could write a full-on compiled binary application?". You don't always need the extensive functionality provided by a framework. The files are large, which means that download times are slow on limited connections - like EDGE, which more and more people use to access the Internet, thanks to the iPhone's explosive popularity and AT&T's lack of 3G in many areas of the United States.
Again, wouldn't these people be the greatest benefactors of not reloading the entire page all the time? As far as the toolkits themselves, that's why you load them when they are needed. Once they are loaded once they are cached. There is nothing to render or fetch, so this is just disk I/O. You can compress text files to be very very tiny in size, no larger than the smallest image on your site. I don't see the problem here.

JavaScript has its uses, but it's not the end all, be all in website design and development. It's much like CSS - there are people who are *such* purists that they refuse to use HTML tables for any single piece of content in a website. The fact is, there are still things that tables are good for - like, you know, tables full of data.
Which come with their own problems - e.g. removing cells and columns dynamically, triggering Scriptaculous animation as a form of feedback, forcing a cell to be a certain width (if there is no content in there you'll need a transparent GIF to do this, yuck), etc. Tables are fine for some things, but this usage is extremely rare. You can do most things with display:inline-block (and the *display:inline, zoom:1 IE workaround).
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 8, 2009, 04:32 PM
 
Originally Posted by shifuimam View Post
The thing is, even with super media-heavy sites, you don't really see long load times anymore unless the infrastructure of that server is having problems. Browsers have gotten much, much better at caching content, which is why in my above video you weren't seeing any page reloads at all as I navigated the site without JavaScript.
Oh I see, you had Javascript turned off... What you wrote wasn't clear to me.

Yes, it is possible to make a server very fast to make page reloading pretty fast (I run that server that hosts that site and like to run my own servers in part for this reason). However, you are only looking at a part of the picture here. The browser still has to re-render that content, it has to reinitialize all of your Javascript, browser plugins (where applicable), and whatever else you do on load. I develop on an old 1.25 Ghz G4, and especially with enough tabs open reloading any sort of page can be painfully slow. It is much slower on mobile devices that generally don't have the horsepower. The bottleneck is not the server, but the client's browser.

My point here is that there are more variables that you aren't accounting for.

My own LiveJournal is a good example, because it's super image-heavy. Once the page loads (which doesn't take that long and is dependent on LJ's performance, which is sketchy at certain times of the day), the sidebar, background images, and top navigation and header don't blink at all, because the browser has cached all that information.
On a fast computer, sure. You don't get the rendering of content for free though.

An inevitably long wait is not the same as seeing the page blink. It's not even really a case of "time wasted" - it's more the visual aesthetic. Sure, you can make something look prettier with JavaScript, but is it worth it if you have to sacrifice core usability of your site?
The only legitimate "core usability" you have identified is browser history. Let's just be clear here.


ColdFusion is plenty modular itself. I love CF. I've been developing almost exclusively with it for the past year and a half, and it's light years ahead of PHP. It has its disadvantages - just like any web development platform, including RoR - but it's fantastic for very fast web development and avoiding rewriting the same code over and over.
And you have to pay for it (I think?!) and it doesn't run on Linux, which doesn't make it light years ahead of anything to me, IMHO.

True, but I'm talking about people who use these frameworks liberally while making use of only .01% of the functionality they provide - as in my previous example, if you're just trying to show/hide elements on a page, you don't need an entire framework for that. You need about ten lines (if your format your code properly) of JS to do that. Not an entire framework.
Unless you want that element to fade in and out

I agree though, but I've yet to come across only needing JS for so little. Forget the page reloading issue, it is still true that Javascript rich sites are the name of the game now in terms of providing interface feedback, sex appeal, and performance. For instance, image carousels, modal windows/dialogs, rotating banners with crossfades, etc. are all in demand now because they add a great deal to the user experience of a site compared to their alternatives (i.e. not using Javascript). I would say that if you want to write a modern website, you are going to need good Javascript chops, period.

Once you set off to do a Javascript rich site/widget/whatever, this is there using vanilla Javascript falls apart.
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 8, 2009, 04:38 PM
 
Originally Posted by shifuimam View Post
Oh...wow.

Their Flickr demo (http://objective-j.org/learn/demos/FlickrPhotoDemo/)...

You see that "Interesting photos" link up near the top left? Yeah, it's in eleven layers of DIV elements.

And the source behind it is super attractive:



They've apparently never heard of using an external CSS file.

It is much harder to manipulate an external stylesheet via Javascript, which is why toolkits such as Prototype and Scriptaculous work with inline styles when it comes to dynamic overrides. YUI 3 offers a way around this though, which is something I've been meaning to look at.
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 8, 2009, 04:40 PM
 
Sorry Chuckit, I ended up reading and responding to each post sequentially and I now realize that I ended up parroting much of what you already beat me to responding with. Sorry about that, no disrespect
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 8, 2009, 04:55 PM
 
Shif: here is the Yahoo browser history lib in action:

YUI Browser History Manager - Simple Navigation Bar Example

What I've been meaning to test is whether or not one could create bookmarkable URLs this way via URL rewriting/mod_rewrite. Also, I get why you don't want to give Javascript the ability to modify your browser's location bar in its entirety, but why not the path part? What danger is there in manipulating the path, as opposed to the domain/protocol/port?
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 8, 2009, 05:19 PM
 
Shif: as I sit here thinking about this thread, I'm now realizing that I don't really understand your point of view. Perhaps I could get you to clarify?

You rightfully point out the browser's ability to cache, yet you say that using a toolkit is an "overkill". An overkill how, in learning a new layer? Or, in performance? Definitely not in performance, as browsers cache Javascript files too, and a compressed version of a toolkit is very very small - text compresses quite nicely. Whatever differences in performance exist once the toolkit is loaded has more to do with the browser's rendering engine, the algorithms used, or whatever. At this point you're at the point of micro-optimizations.

If you mean in learning something new, I would argue that more modern sites are written using a toolkit than not. It is true that there is no standardization, but it is hard to come across a modern Javascripty site that doesn't use something like jQuery or Prototype.
     
shifuimam
Addicted to MacNN
Join Date: Aug 2006
Location: Somewhere in the Pacific Northwest
Status: Offline
Reply With Quote
Aug 9, 2009, 03:31 AM
 
Originally Posted by besson3c View Post
The lack of a back button is a serious tradeoff, you are right. This is why I'm anxious to utilize Yahoo's browser history lib as soon as I can. However, there are users that can't stand having their entire page reload for every little thing. On mobile phones and slower computers this can take *forever*, and when you are flipping through content in a hurry this can be a huge turnoff. I guess it just depends on the nature of your content. Some content doesn't really need to be bookmarkable. For instance, on many of my sites the Contact link triggers a Modalbox window so that they can contact the person from anywhere on the site. A simple contact form usually doesn't need to be bookmarkable, unless you like contacting that person via their website a whole hell of a lot
I think that you're seriously underestimating a user's desire or need to link to any single page on a site. For instance, your Clovertone site doesn't appear to provide any easy way to link to a single product in the online store. What do you expect your users to do, IM someone and say "go to clovertone.com, click foo, then click bar, then scroll down a little bit until you find the song"? That's ridiculous. It's a hell of a lot easier to do one simple copy and paste so that your friend or customer or whoever else can be linked directly to something.

What about your contact form example? What if you're talking about an older person who just wants to get in touch with the company, so they ask you how? Which is easier - saying "click this link I've emailed you", or laying out steps on how to navigate the site?

It's presumptuous of you to predict your users' needs regarding what pages should and shouldn't be accessible via static permalinks. You have no idea what sort of situation a user of your site may find himself in, and to say "you don't need to link to x or y" is just ridiculous, particularly when there's no justifiable reason not to provide that functionality in the site.

I use this same Ajax reload/cache technique on a number of my musician sites so that we can have a global media player that can play uninterrupted as we move in between pages. This is far more elegant than an iframe or a popup window, and since most musician sites only have a handful of pages, giving up the bookmarking ability is usually worthwhile here.
I don't think it's even worth commenting on this one, because I wholeheartedly despise websites with background music. I've got my own damn music, thankyouverymuch.

However, for situations where you want to have a global media player, I'm not convinced that loading all your site's content with JavaScript simply so you can avoid the inevitable page reload is the only - or best - solution.

It's not impossible, I would just have to include a cut and pastable URL somewhere or make use of the browser history lib... This is not ideal, but then again, anybody that comes across an embedded video is used to some sort of widget that spits out a direct URL/permalink.
I'm not sure what you're getting at by this comment. There aren't permalinks on your site if the user is navigating it within a single browser window. Is there something I missed there?

Granted, you at least make it possible for someone to middle-click a link to open it in a new tab without breaking the URL entirely. This is at least better than the practice I've seen many places that utilize JavaScript for pageloads.

What do you use Javascript for? How good is your Javascript coding? Trust me, when you find a complicated enough thing, vanilla Javascript is near torture. Try making an AJAX request with your own custom callback. It can be done, but it will take you a while to figure this out. Trust me, I've been there
Like I've said - frameworks have their uses. If you're doing AJAX stuff, they're quite useful. If all you're doing is some relatively lightweight dynamic DOM modification, not so much - and even then, I think that DOM modification is pretty damn overused, particularly for things like alert messages upon submitting forms.

I avoid using JavaScript. I believe in developing web applications that are usable by all users in all environments - which means avoiding client-dependent technologies like JavaScript for core functionality like navigation. Using AJAX for validating certain kinds of data - in my case, a user puts in a network user ID of someone, and AJAX goes off to LDAP and makes sure that (a) the ID is valid, and (b) it belongs to who you think it belongs to. This is much less annoying than having to wait until you submit the form to find out if the user ID exists.

I don't use JavaScript for cheesy visual effects or critical components of a website - specifically navigation.

You and I have different customer bases. I work for a public university developing applications that are, generally speaking, for said university. We are required by law to make sites Section 508 compatible, which means making them compatible with assistive technologies like screen readers and people who navigate strictly with a keyboard. I can't rely on things like JavaScript for critical components, because I need to make sure that the content I create is equally accessible by all people in all environments.

Why not? You could tell the user that the two email addresses they typed don't match or that they typed an invalid username or whatever immediately, and it's not hard and has no real downsides. Maybe not everybody is as patient as you?
No, it's not hard, but in my work environment, we usually have pretty compact schedules for getting web apps developed, tested, and out the door to production. I'm not going to waste my time coding JS form validation when I'm going to have to redo the exact same functionality on the server-side anyhow. Making redundant code so that the aesthetic of the site is very minorly improved is really just not worth my time, and I have yet to hear a complaint from any of my customers about the usability of the products I create.

All the more reason to use a toolkit so that you don't have to worry about these sorts of cross browser problems. I never depend on Javascript for form validation, but it's a very nice addition.
Yes, using a framework means that the browser compatibility issues have been worked out on your behalf. But it's still relying on client-side technology for things that shouldn't be exclusively dependent on client-side technology.

You lost me. Wouldn't those people with slow connections be the greatest benefactors of not reloading the page constantly?
You're still loading the content. Like I mentioned before, browsers cache a shitload of content these days. Whether you're loading with AJAX or traditional pageloads, the content still has to be loaded from the server. Either way, if your customer is on a very slow connection, they're going to see performance problems - either they'll click the link and nothing happens and they wonder what the hell is wrong with the site, or they click the link and see the progress indicator fill up as the page loads on their butt-slow connection.

Again, wouldn't these people be the greatest benefactors of not reloading the entire page all the time? As far as the toolkits themselves, that's why you load them when they are needed. Once they are loaded once they are cached. There is nothing to render or fetch, so this is just disk I/O. You can compress text files to be very very tiny in size, no larger than the smallest image on your site. I don't see the problem here.
And again, your browser is caching so much of the content that you're not reloading "the entire page all the time".

I'll grant you that once a framework's JS file is cached, you don't have to worry about loading it every time you load a page.

However, my point is that since browsers cache so much content already, I'm not seeing any real benefit to using AJAX to load your page content as your users navigate your site.

Which come with their own problems - e.g. removing cells and columns dynamically, triggering Scriptaculous animation as a form of feedback, forcing a cell to be a certain width (if there is no content in there you'll need a transparent GIF to do this, yuck), etc.
Wait...what? I can set table cell widths just fine with CSS and no transparent GIFs.

Tables are fine for some things, but this usage is extremely rare.
I disagree. There are plenty of times where a table is completely appropriate - displaying grid-style calendars, displaying tables of data like reports, etc. Yeah, I could do it in CSS, but it would take twice as long and there would be no real benefit.

Originally Posted by besson3c View Post
Yes, it is possible to make a server very fast to make page reloading pretty fast (I run that server that hosts that site and like to run my own servers in part for this reason). However, you are only looking at a part of the picture here. The browser still has to re-render that content, it has to reinitialize all of your Javascript, browser plugins (where applicable), and whatever else you do on load.
Which is why modern browsers are designed to cache much more content than their predecessors.

My point here is that there are more variables that you aren't accounting for.
Indeed. There are variables here that you aren't accounting for, either.

If I was looking for music for whatever purpose and came across your Clovertone site, I would be disinterested within minutes. I have no use for a site that doesn't easily let me bookmark specific pages.

It's not up to you as the designer to pick and choose for me which pages I should be allowed to bookmark, either.

The only legitimate "core usability" you have identified is browser history. Let's just be clear here.
That's like saying "the only 'core usability' of this new car design that you've identified is its ability to go in reverse".

Breaking your client's browser history makes your site effectively useless to your user. It means they can't go back and find content when they search through their browser's history. It means that they can't use their back button. There are many, many mice on the market today that have hardware buttons for browser navigation. I never use my back button, because my mouse has one right on the side. I despise sites that don't allow me to go back and forth with my back/forward buttons as I navigate the content.

By telling me that I'm not even allowed to use back/forward, you're setting a hard-and-fast rule that essentially makes your site unusable.

What you're doing is terminating a basic and very key functionality of any web browser. It's not some special thing that only a few people in a niche market use - it's functionality that every single user on every single platform expects to be there. When you break it, it's irritating for technologically-aware users, and it's frustrating and confusing for techno-phobic users who don't understand why their damn back button doesn't work anymore.


And you have to pay for it (I think?!) and it doesn't run on Linux, which doesn't make it light years ahead of anything to me, IMHO.
Yes, ColdFusion costs money, and it currently only runs on IIS.

However, in the markets of both higher education and corporate enterprise, this isn't exactly a stumbling block. When you're developing independently, of course you're going to use PHP - it's free and runs on any OS. However, PHP is archaic and clunky to me after working in ColdFusion so much.

RoR is one of several web development technologies. It seems like people cream their panties over it, which is just stupid. It's not like it's the messiah of web development. It may not be a total POS, but that doesn't mean that it's the only or best way to do web development.

Unless you want that element to fade in and out
Which is a visual effect that is currently trendy and, like many visual effects on websites, will probably be obsolete and out-of-style in three years.

For instance, image carousels, modal windows/dialogs, rotating banners with crossfades, etc. are all in demand now because they add a great deal to the user experience of a site compared to their alternatives (i.e. not using Javascript). I would say that if you want to write a modern website, you are going to need good Javascript chops, period.
All these things aren't navigation. There is a huge difference between the drag and drop stuff that Flickr's photo organizer does and the core navigation of the site that allows me to send people links to photos and profile pages and photo sets and collections.

Up until about a year ago, OKCupid insisted on using JavaScript for the navigation inside each member's profile. This meant that instead of being able to IM someone with a link to a person's photo page, I had to IM them a generic link to the profile and instruct them to click the person's photo page.

In our undeniable culture of immediate satisfaction (which, ironically, is why you're arguing in favor of using JS for navigation and content loading), this is retarded. I multitask heavily. I don't want to waste time clicking around on a page just to get to the content someone wants to show me. By the time I would have found said content, I've already moved on to five other things.

Once you set off to do a Javascript rich site/widget/whatever, this is there using vanilla Javascript falls apart.[/QUOTE]

Originally Posted by besson3c View Post
It is much harder to manipulate an external stylesheet via Javascript, which is why toolkits such as Prototype and Scriptaculous work with inline styles when it comes to dynamic overrides.
Absolutely. CSS works the way the name says - cascading. External CSS files are applied first, followed by the <style> tag, followed by inline styles, which take precedence over the former two. It's one thing to use inline styles to override existing core/global styles on your site. It's quite another to use inline CSS for everything.

Originally Posted by besson3c View Post
What I've been meaning to test is whether or not one could create bookmarkable URLs this way via URL rewriting/mod_rewrite. Also, I get why you don't want to give Javascript the ability to modify your browser's location bar in its entirety, but why not the path part? What danger is there in manipulating the path, as opposed to the domain/protocol/port?
I have no problem with that. The problem is that people who use JS for site navigation don't do this. It's great in theory; it just hasn't been put into practice.

If you want to use JS to load all your content but still provide me with the ability to copy, bookmark, twitter, email, IM, etc. the permalink URL from my browser's address bar, go for it.

Originally Posted by besson3c View Post
Shif: as I sit here thinking about this thread, I'm now realizing that I don't really understand your point of view. Perhaps I could get you to clarify?

You rightfully point out the browser's ability to cache, yet you say that using a toolkit is an "overkill". An overkill how, in learning a new layer? Or, in performance? Definitely not in performance, as browsers cache Javascript files too, and a compressed version of a toolkit is very very small - text compresses quite nicely. Whatever differences in performance exist once the toolkit is loaded has more to do with the browser's rendering engine, the algorithms used, or whatever. At this point you're at the point of micro-optimizations.
There are times when the functionality provided by a framework is plenty useful. There are times when it's just used to add a little sex appeal to a site. Depending on your customer and audience, sex appeal is entirely unnecessary.

I'm wrapping up a project that is geared toward faculty members at the university. They don't give two shits about sex appeal. They want to be able to get in, do what they need to do, and get out as quickly as possible. This means no JavaScript, no fancy bullshit, no overly "pretty" stuff. It means clear, easy-to-use web forms and interfaces that have zero learning curve.

It's an entirely different story when you're trying to develop "the next big thing" to appeal to teenagers and twentysomethings who are used to all the visually appealing crap found on sites like Flickr, Facebook, Twitter, and whatever the hell else kids uses these days.

I prefer usability to pretty when it comes to web applications, and I reflect that in the applications I design. Sometimes, this absolutely means using JavaScript stuff to allow users to do things like use sliders and drag-and-drop. However, for the wide majority of applications I've done during my employment at this university, there simply has been no need for that kind of visual stuff.

I also think that it's very important to not ignore users with disabilities. Again, this is because of the audience I have to anticipate with the applications I develop. Flickr isn't going to have a lot of blind visitors. A website detailing university enrollment procedures, however, will, and it needs to reflect that.

And, being the person that I am, I just get frustrated with people who get all moony and starry-eyed over the latest and greatest web technologies. I think that Twitter is the biggest pile of crap to poo all over the Internet since AOL. I've met too many people who are wholly obsessed with getting as much of their site content into Facebook as possible. It's the freaking Internet - just because it's big now doesn't mean it's going to be big in five years or even five months. I'm slow to adopt new technologies, because I know from experience that some are just novelties while others are here to stay.

I won't deny that the visual appeal and functionality provided by JS is here to stay - but JavaScript site navigation? I'll pass.
     
shifuimam
Addicted to MacNN
Join Date: Aug 2006
Location: Somewhere in the Pacific Northwest
Status: Offline
Reply With Quote
Aug 9, 2009, 03:41 AM
 
Also, I should add that another big annoyance with doing dynamic DOM modification is how it's done. In my experience as a user, it sucks to have the content I'm actively reading be moved in any direction to accommodate an element that's now being displayed.

For instance, the "Listen to this song" button on your Clovertone site - why not implement that functionality the way that Wikipedia does, where the player controls appear where you've clicked to listen to the song? By placing that above the container with the music details and auto-scrolling my browser viewport so that the player is at the top of the browser, you're rearranging my content and changing the view of the site so that I have to visually re-find where I was looking at a moment ago.

It would be much nicer and more functional/usable if that player control appeared either directly below the "Listen to this song" button or replaced it entirely (which is what Wikipedia does).
     
Synotic
Mac Elite
Join Date: Oct 2000
Status: Offline
Reply With Quote
Aug 9, 2009, 03:10 PM
 
I disagree. It's more of a trendy, overhyped way to do things right now, much like Ruby on Rails, which I've recently been reading about - it seems like the singular most bass-ackwards way to develop a web application.
Thanks for twisting my words around. Look, I haven't done any RoR development myself; I've just been looking through the "getting started" stuff. Its way of dealing with databases looks unpleasant to me. I already know SQL at a pretty advanced level; I don't want something else writing complex queries for me, since it would take more time to tell it what I need than to just write the query myself.
Object-relational mapping isn't a particularly new technology. One of the first successful implementations of ORM was with NeXTStep's Enterprise Objects Framework, which they introduced in 1994 (PHP and MySQL were introduced a year later). It was then integrated into WebObjects which now powers the Apple Store, the iTunes Store and MobileMe.

EOF had proven stable and productive enough (both in implementation and design) that Apple introduced Core Data for Cocoa whose design essentially mirrors EOF. Core Data is now the recommended way of building any Cocoa (or Cocoa Touch) application that needs to manage and persist data. Combined with bindings on the desktop, there's something that conceptually makes sense about being able to directly manipulate your data model from your view (all the while keeping referential integrity and any other constraints you have set up). I don't think anyone's arguing that it's not more difficult to pick up something like an object-relation mapper/object-lifecycle tool/object graph manager than to simply sling SQL and keeping your models synchronized... and your views. Rather that taking the time to learn it can enable you to design and deploy things more quickly and more broadly in scope. It's not that different from taking the time to learn PHP or ColdFusion or whatever you're interested in learning.

So that Ruby on Rails uses an object relation mapper isn't that surprising (or even that innovative). Django uses an ORM. Of the three random PHP frameworks I looked up (CodeIgniter, CakePHP, and Symfony), the latter two had an ORM. Almost every Java web application of any size uses an ORM like Hibernate, which has been around for nearly a decade.

If you had argued that Ruby's particular implementation of its ORM wasn't up to snuff, then I'd love to hear it. But to simply pan the whole project because of a little reading you had done seems uninformed. I think we often spend so much time debating the pros and cons of different frameworks and languages and frameworks built on frameworks (and I'm guilty of this, too), that we don't actually take the time to explore these different technologies and learn about them in earnest. The trendy web developer that tries everything is no worse than the old timer that tries nothing. The truth lies in between. Silverlight probably (hopefully?) won't take over the world. There was probably something to that whole object-oriented programming thing. Perhaps there's some value to object-relational mapping.

As a personal example, when CSS frameworks started to come out, I simply couldn't understand it. I could sling CSS with the best of them (cross-browser and all) and I had no idea why anyone would use a CSS framework let alone what one was. The last point is important. I spent so much energy being confused and uninformed that I didn't even take the time to use them and try them out. Rather, I took too much pride in my CSS skills that I wasn't willing to "dumb" myself down to using CSS frameworks. But once I finally took the time to actually use what was out there (Blueprint, YUI Grids, etc…) it finally made sense why having a tool help with layout might make sense. Sure I could make that layout, but I couldn't make it easy to swap the left and right columns (I'm only floating one of them to the left, and then I'd have to swap my source code, and…). Well I could. I could make make my CSS nice and modular and work with any number of columns and with source order independence, and… But at that point I'd have written a CSS framework. And luckily people have already done that.

--

Finally, I wanted to mention that I actually largely agree with your perspective. I can't stand JavaScript navigation either and I think permalinks and clean link structure are important. But I think we have to be careful with these discussions about "JavaScript: Good or Bad?" or "Ruby on Rails? What's the point?" I think that we'd all agree (and it's been said multiple times) that the answer is almost always "it depends." And I think that the only way to reliably answer that question is to be as experienced as possible in the technologies you're considering. I didn't mention it above, but Ruby on Rails (I don't actually care for it that much, but I'm just trying to provide some perspective ) is actually part of a long heritage of web development stacks. Java frameworks were originally designed in response to the large, unmaintainable codebases written in procedural languages like C, Perl, and PHP. They introduced a lot of powerful conventions to the web like MVC and ORMs. But they, too, became large and difficult to work with. Web applications written in Java are difficult to get started. But finally the wheel turned and PHP frameworks began to incorporate some of the best parts of Java applications without the frustrating parts (compilation and unnecessary configuration). More recently, frameworks like Django and Rails have come on the scene to combine the best of both worlds. They have MVC and ORMs at their core, combined with modern object-oriented languages that lend themselves well to those features. They avoid the plague of XML configuration while promoting fast development. PHP frameworks are trying to catch up, but the momentum has shifted. So these new frameworks may be trendy, but they're not without their history and lineage.
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 9, 2009, 05:53 PM
 
Originally Posted by shifuimam View Post
I think that you're seriously underestimating a user's desire or need to link to any single page on a site. For instance, your Clovertone site doesn't appear to provide any easy way to link to a single product in the online store.
Not true. You just have to know the product ID right now to know what URL to use. This will be improved upon. I did say that this site is a work-in-progress, didn't I?

What do you expect your users to do, IM someone and say "go to clovertone.com, click foo, then click bar, then scroll down a little bit until you find the song"? That's ridiculous. It's a hell of a lot easier to do one simple copy and paste so that your friend or customer or whoever else can be linked directly to something.
First of all, these are not *my* users. I'm working on behalf of a client who is driving the bus. We've discussed these tradeoffs. This debate is a bit of a strawman, shif. I've acknowledged the tradeoffs you are ranting at. The key word is *tradeoffs*. You gain and lose some functionality this way, just as you lose some functionality not doing it this way. Just because *you* don't think this tradeoff is worth the gains doesn't mean that this is some sort of universal truth. It depends.

However, the interface makes sense. It is search/filter driven, which means that most people probably are going to use these tools to find what they are looking for (so my client feels). All we need is an icon to create a cut and pasteable permalink URL, like I said, although the YUI browser history would help too. Otherwise, how do you reproduce the search query you used to find what you are looking for on any site? You copy and paste a big long URL with query string and say "go to page 2 of these results". This site is unlike NewEgg or something where each product has enough content to warrant having its own page, so with or without Javascript there is no obvious way to isolate a single product. This is a hidden feature right now.

It is a little presumptuous of you to lecture me on this as if I'm not aware of any of this, as if I'm designing into a vacuum, and as if there are not solutions to this problem (I've given you two - YUI and copyable URLs). The key is that these are solvable problems.

I don't think it's even worth commenting on this one, because I wholeheartedly despise websites with background music. I've got my own damn music, thankyouverymuch.
Who says I force the music on people? These are *musicians*, their craft is music. Why wouldn't you want to showcase this? I never force feed the music though, just make it available by clicking on the play button.

However, for situations where you want to have a global media player, I'm not convinced that loading all your site's content with JavaScript simply so you can avoid the inevitable page reload is the only - or best - solution.
Name some others... I've given you iframes and pop up windows. What else is there?

I'm not sure what you're getting at by this comment. There aren't permalinks on your site if the user is navigating it within a single browser window. Is there something I missed there?
Maybe we don't have the same idea of what a permalink is? I don't mean this in a passive aggressive way, my usage of the word may not be accurate in this context. I'm simply referring to a URL that gets the user back to where they were. They are currently hidden, but still functional. Like I said, making them visible and functional to visitors in a user friendly manner is a solvable problem.

Granted, you at least make it possible for someone to middle-click a link to open it in a new tab without breaking the URL entirely. This is at least better than the practice I've seen many places that utilize JavaScript for pageloads.
Maybe you have a little to learn on how to best direct your rants?

Like I've said - frameworks have their uses. If you're doing AJAX stuff, they're quite useful. If all you're doing is some relatively lightweight dynamic DOM modification, not so much - and even then, I think that DOM modification is pretty damn overused, particularly for things like alert messages upon submitting forms..
You're missing a key part of this. Javascript/AJAX can be used to make webpages behave more like Desktop apps. However, the Clovertone site is not a great example of this because it was meant to showcase use of Prototype specifically as far as my reason for bringing it up as an example... There are challenges with this too in making appropriate use of a "save" button of some sort, but there are also many occasions where it doesn't make sense to refresh the page, for instance in making bulk changes. Do use the vBulletin quick reply feature? I love it!

No, it's not hard, but in my work environment, we usually have pretty compact schedules for getting web apps developed, tested, and out the door to production. I'm not going to waste my time coding JS form validation when I'm going to have to redo the exact same functionality on the server-side anyhow. Making redundant code so that the aesthetic of the site is very minorly improved is really just not worth my time, and I have yet to hear a complaint from any of my customers about the usability of the products I create.
We have different goals then. I used to work for a University and am pretty close to life as a web guy at a university, and I also used to do this myself several years ago. I understand where you are coming from. However, I'm doing a lot of stuff for musicians and private corps now, where sex appeal is desirable.

Yes, using a framework means that the browser compatibility issues have been worked out on your behalf. But it's still relying on client-side technology for things that shouldn't be exclusively dependent on client-side technology.
Focus Shif, I said before that I'm not *depending* on client-side technology. Don't direct this rant at me, please!



You're still loading the content. Like I mentioned before, browsers cache a shitload of content these days. Whether you're loading with AJAX or traditional pageloads, the content still has to be loaded from the server. Either way, if your customer is on a very slow connection, they're going to see performance problems - either they'll click the link and nothing happens and they wonder what the hell is wrong with the site, or they click the link and see the progress indicator fill up as the page loads on their butt-slow connection.
Again, you're only looking at the server being a variable. What about the amount of time it takes for your browser to render content? How about on mobile devices or slower computers? The browser still has to generate the layout based on the HTML/CSS output, you don't get this for free.

And again, your browser is caching so much of the content that you're not reloading "the entire page all the time".
No, but you're still rendering it.

However, my point is that since browsers cache so much content already, I'm not seeing any real benefit to using AJAX to load your page content as your users navigate your site.
Isn't this operating under the basis that these problems are unsolvable? I pointed you right at the YUI browser history library, which is one such way of solving this problem. If you are making general statements or rants directed at the world as a whole, please direct them accordingly...

Wait...what? I can set table cell widths just fine with CSS and no transparent GIFs.
Tables are fussy if there is no content in a cell, have you not come across this yourself? You can force space with an empty div tag, but if you are going to go this far why not just use inline-blocks for your cells?

I disagree. There are plenty of times where a table is completely appropriate - displaying grid-style calendars, displaying tables of data like reports, etc. Yeah, I could do it in CSS, but it would take twice as long and there would be no real benefit.
I came up with some examples: dynamic cell/row modifications, precise spacing. A calendar is actually a *bad* use of a table if you want to make each cell precisely the same size and you don't want anything to force this from being changed, such as when you want to write stuff into each cell. Yes you can put div tags in each cell to sort of force this, but that's silly, IMHO.

Take, for example, another work in progress:

http://dev1.witzapplecertifiedtraini...lendar/2009/07

The blue spaces will eventually be singe images taken out of the document flow to span across several days. If each day wasn't precisely the same width, something like this wouldn't work. The version of my calendar before this was actually in a table layout, and it was *much* more difficult to fine tune than this inline-block one.

This, I think, is also another suitable use for Javascript. If just want to peak at one of the events to quickly compare it to another to fine the course I want to take, why should I wait for the entire page to load when I can move in between months and events so much faster this way, and events/months I've been to already are cached into memory?

If you think more can be done to give people cut and pasteable URLs, fine (my client didn't agree, and he's pretty tech savvy), but the speed of moving in between stuff in this calendar was definitely a prereq here. This is a tradeoff he will gladly take.

Which is why modern browsers are designed to cache much more content than their predecessors.
Nobody is denying that. Like I said, rendering takes time though, as does reading from the disk. The former is a big problem on slower computers or browsers that have been bogged down with lots of open tabs.

Indeed. There are variables here that you aren't accounting for, either.
Such as?

It's not up to you as the designer to pick and choose for me which pages I should be allowed to bookmark, either.
So, when you come across a site that is entirely in Flash, do you refuse to use it? I think you would be surprised about what a lot of people use bookmarks for and what they bookmark and not bookmark. This is tangential to this debate, you don't have to repeat everything you said about the importance of bookmarkable pages, I never really disagreed with you.... just sayin'.

[quote[Yes, ColdFusion costs money, and it currently only runs on IIS.

However, in the markets of both higher education and corporate enterprise, this isn't exactly a stumbling block. When you're developing independently, of course you're going to use PHP - it's free and runs on any OS. However, PHP is archaic and clunky to me after working in ColdFusion so much.[/quote]

Can you give me an example? I don't mean this in a confrontational way, I've never delved into ColdFusion at all. It's not at all an option for me because non-Apache non-Unix is a deal breaker for me, but I'm curious...

RoR is one of several web development technologies. It seems like people cream their panties over it, which is just stupid. It's not like it's the messiah of web development. It may not be a total POS, but that doesn't mean that it's the only or best way to do web development.
Yeah, but what use is the snazziest of web applications that runs on IIS, hypothetically speaking? I like my mod_rewrite, my basic auth, my compression, etc. I've never touched IIS, can you do all of this stuff there remotely without a GUI? Again, another one of those non-confrontational honestly don't know questions...

Which is a visual effect that is currently trendy and, like many visual effects on websites, will probably be obsolete and out-of-style in three years.
I disagree. Animated effects are very useful as a way of providing interface feedback when applied correctly. Here is another Prototype/Scriptaculous example of mine (also a work in progress):

http://dev1.canbrass.com/potw/

For starters, another typical example of DOM manipulation via Javascript. This is a good technique, I think, for providing a lot of information on a page without requiring page refreshes and without it seeming overwhelming, but without the animation the whole experience is a little jarring.

The crossfading banners on the homepage of the site are also all Javascript:

http://dev1.canbrass.com/

I could go on, but there are a lot of uses for Javascript animation, and they aren't all flash-in-a-pan stuff like Apple style Javascript image reflections.

In our undeniable culture of immediate satisfaction (which, ironically, is why you're arguing in favor of using JS for navigation and content loading), this is retarded. I multitask heavily. I don't want to waste time clicking around on a page just to get to the content someone wants to show me. By the time I would have found said content, I've already moved on to five other things.
You do realize that you are being awfully repetitive here, don't you? It's okay, I just want you to understand that I got your point paragraphs ago... This is really misdirected.

Absolutely. CSS works the way the name says - cascading. External CSS files are applied first, followed by the <style> tag, followed by inline styles, which take precedence over the former two. It's one thing to use inline styles to override existing core/global styles on your site. It's quite another to use inline CSS for everything.
Agreed there, but who uses inline CSS for everything? It makes no logical sense to do so...

I have no problem with that. The problem is that people who use JS for site navigation don't do this. It's great in theory; it just hasn't been put into practice.
Your posting contradicts this. You make it seem like using Javascript for any sort of navigation is an inevitable fail? Perhaps your rhetoric is a little overblown or something?

If you want to use JS to load all your content but still provide me with the ability to copy, bookmark, twitter, email, IM, etc. the permalink URL from my browser's address bar, go for it.
If this is really your only beef with Javascript rich sites and toolkits, perhaps you ought to rethink your very hard line stance against Javascript? These are solvable problems, and moreover it seems that your opinions are clearly shaped by the university culture you work in. If you did Apple's website or the website for some other company with some marketing muscle simply functional is probably not going to cut it. It's a definite prerequisite, but the absence of a killer interface and some flashy design work is not terribly compelling. Sex sells, baby! Apple knows this, which is why you see those Javascript widgets peppered throughout their site.

There are times when the functionality provided by a framework is plenty useful. There are times when it's just used to add a little sex appeal to a site. Depending on your customer and audience, sex appeal is entirely unnecessary.
Exactly right. So why the dogma, hard line stance here?

It's an entirely different story when you're trying to develop "the next big thing" to appeal to teenagers and twentysomethings who are used to all the visually appealing crap found on sites like Flickr, Facebook, Twitter, and whatever the hell else kids uses these days.
Like it or lump it, this is where web interfaces are at these days - more like Desktop applications than yesterday's web pages, the so-called Web 2.0 cliché. You need Javascript to drive all of this, and without a toolkit this is much harder.

I prefer usability to pretty when it comes to web applications, and I reflect that in the applications I design. Sometimes, this absolutely means using JavaScript stuff to allow users to do things like use sliders and drag-and-drop. However, for the wide majority of applications I've done during my employment at this university, there simply has been no need for that kind of visual stuff.
Why not write about your own experiences and needs then rather than coming up with these generalizations that are supposed to fit for everybody?

I also think that it's very important to not ignore users with disabilities. Again, this is because of the audience I have to anticipate with the applications I develop. Flickr isn't going to have a lot of blind visitors. A website detailing university enrollment procedures, however, will, and it needs to reflect that.
Yeah, ADA compliant sites (or whatever the acronym is) are very important for University sites. I have a friend that is working through this now.

You missed a whole other set of needs: mobile apps. *Any* technique you can utilize to make performance better for those little iPhones is a win if you care about mobile app experiences. Performance *may* be a more attractive net gain if given the option between bookmarkability and performance when designing for something like the iPhone, and you couldn't have both. This means, whatever CSS and Javascript you load when the page loads, why not load these dynamically? Not only will you save a little time, but you lighten the load on the client's web browser in rendering this content, you improve battery life, etc.

When you talk about how fast a browser can cache content, you are underestimating the effect of slower browsers/slower computers, but also the whole mobile phone experience. I *can* notice when an entire page has to be reloaded on many sites, and it is noticeably frustrating for me as a surfer on my old abused Powerbook G4.

Just something to consider... Again, my ideal is to have both.


And, being the person that I am, I just get frustrated with people who get all moony and starry-eyed over the latest and greatest web technologies. I think that Twitter is the biggest pile of crap to gambling all over the Internet since AOL. I've met too many people who are wholly obsessed with getting as much of their site content into Facebook as possible. It's the freaking Internet - just because it's big now doesn't mean it's going to be big in five years or even five months. I'm slow to adopt new technologies, because I know from experience that some are just novelties while others are here to stay.

I won't deny that the visual appeal and functionality provided by JS is here to stay - but JavaScript site navigation? I'll pass.

Shif, if we are to continue this conversation, I really think you should lighten up on the dogma. It puts me on the defensive. There is no need for this, we aren't talking religion or politics. All I'm trying to do is make you recognize that not everybody sees things as you do, and there is a legitimacy to these alternative points of view. We each have our own justifications for the tradeoffs and decisions we make, not to mention the ones that the clients force on you. I could have easily asked you to post an example of one of your sites and then ram down your throat my own dogma. I'd much prefer it if we could just have a light discussion rather than ramming anything down anybody's throat.

Besides, I tried your TGI Friday's beef stroganoff like a good little boy, so why the hell aren't you being nice to me? I could have ordered *anything* else on that fine menu, yet I went out of my way to order that stroganoff!
( Last edited by besson3c; Aug 9, 2009 at 06:03 PM. )
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 9, 2009, 05:55 PM
 
Originally Posted by shifuimam View Post
Also, I should add that another big annoyance with doing dynamic DOM modification is how it's done. In my experience as a user, it sucks to have the content I'm actively reading be moved in any direction to accommodate an element that's now being displayed.

For instance, the "Listen to this song" button on your Clovertone site - why not implement that functionality the way that Wikipedia does, where the player controls appear where you've clicked to listen to the song? By placing that above the container with the music details and auto-scrolling my browser viewport so that the player is at the top of the browser, you're rearranging my content and changing the view of the site so that I have to visually re-find where I was looking at a moment ago.

It would be much nicer and more functional/usable if that player control appeared either directly below the "Listen to this song" button or replaced it entirely (which is what Wikipedia does).

Not a bad suggestion. My client made this decision, but I was too busy to really give this much thought (the player is also a work in progress, we will be making changes there), I'll push this some more... Thanks for the idea!
     
shifuimam
Addicted to MacNN
Join Date: Aug 2006
Location: Somewhere in the Pacific Northwest
Status: Offline
Reply With Quote
Aug 9, 2009, 11:34 PM
 
Originally Posted by besson3c View Post
Not true. You just have to know the product ID right now to know what URL to use. This will be improved upon. I did say that this site is a work-in-progress, didn't I?
True, but my issue isn't specifically with your site as much as it is with web designers who implement JavaScript-based navigation without accommodating the millions of Internet users who like to bookmark pages and send links to friends.

First of all, these are not *my* users. I'm working on behalf of a client who is driving the bus. We've discussed these tradeoffs. This debate is a bit of a strawman, shif. I've acknowledged the tradeoffs you are ranting at. The key word is *tradeoffs*. You gain and lose some functionality this way, just as you lose some functionality not doing it this way. Just because *you* don't think this tradeoff is worth the gains doesn't mean that this is some sort of universal truth. It depends.
I think that are some universal expectations and unofficial standards, however. There are expected behaviors in any piece of software, for instance, which is why people tend to bitch when an application doesn't follow the standard conventions of the environment. For instance, Lotus Notes is terrible about this - the keyboard shortcuts they use for everything except the absolute most basic thing - cutting/copying and pasting - are different compared to every other Windows application one would encounter in an enterprise environment. It's frustrating, because the core functionality you expect in an email application behaves differently, requiring you to read the help documentation just to do basic things in the application.

It's the same with websites. When you click a link, you expect it to take you somewhere. If you were to break this functionality without making it clear (e.g. instead of going to a new page, clicking a link just changes the background color of the page, but there's no indicator that this is what it does), it would confuse your users, because it's such basic functionality. Users expect to be able to bookmark websites and pages of interest - the Internet is massive, and bookmarking is the only way to find valuable content later, unless you're exceptionally skilled with Google.

The tradeoff with JavaScript navigation - in the way that it is currently implemented in the sites I've seen - breaks core functionality (the ability to bookmark a page). This would be like saying that the tradeoff to having blue LEDs on your car's dashboard is that your headlights only work during the daytime, or something equally arbitrary and ridiculous.

However, the interface makes sense. It is search/filter driven, which means that most people probably are going to use these tools to find what they are looking for (so my client feels). All we need is an icon to create a cut and pasteable permalink URL, like I said, although the YUI browser history would help too. Otherwise, how do you reproduce the search query you used to find what you are looking for on any site? You copy and paste a big long URL with query string and say "go to page 2 of these results". This site is unlike NewEgg or something where each product has enough content to warrant having its own page, so with or without Javascript there is no obvious way to isolate a single product. This is a hidden feature right now.
I don't think with any e-commerce site that there's a good reason to not have individual product pages. At some point, one of your users is going to want to link to a specific product, whether it be in an email, a website, a twitter posting, or something else. It takes very little time to make a single product page; you can reuse the existing code from your category view.

This is something else where conventions come into play - people expect e-commerce sites to work a certain way. No, they're not all the same, but the gist is generally the same across the board - adding products to a shopping cart, changing quantities, making a user account, entering in billing information, etc. If you were to change all these to follow some arbitrary and unconventional process, it would inevitably frustrate your users.

It is a little presumptuous of you to lecture me on this as if I'm not aware of any of this, as if I'm designing into a vacuum, and as if there are not solutions to this problem (I've given you two - YUI and copyable URLs). The key is that these are solvable problems.
The problem is that few (if any) designers currently implement solutions to the problems posed by JS-based navigation. The Yahoo example is a good solution. Now we just need to get devs to use it.

Who says I force the music on people? These are *musicians*, their craft is music. Why wouldn't you want to showcase this? I never force feed the music though, just make it available by clicking on the play button.
Sorry; I was just talking in general regarding background music on websites.

Name some others... I've given you iframes and pop up windows. What else is there?
I don't really have any experience with that particularly specific situation, so I don't know. Perhaps storing in the session the time location on the currently playing song so that playback continues as expected? Maybe an iframe is a better choice. I don't know.

Maybe we don't have the same idea of what a permalink is? I don't mean this in a passive aggressive way, my usage of the word may not be accurate in this context. I'm simply referring to a URL that gets the user back to where they were. They are currently hidden, but still functional. Like I said, making them visible and functional to visitors in a user friendly manner is a solvable problem.
This is what I mean. A permalink is a URL that takes you back to the page you're currently viewing - and it's one that shows up in your browser's address bar, which I was happy to see that Yahoo's example accomplishes.

You're missing a key part of this. Javascript/AJAX can be used to make webpages behave more like Desktop apps. However, the Clovertone site is not a great example of this because it was meant to showcase use of Prototype specifically as far as my reason for bringing it up as an example... There are challenges with this too in making appropriate use of a "save" button of some sort, but there are also many occasions where it doesn't make sense to refresh the page, for instance in making bulk changes. Do use the vBulletin quick reply feature? I love it!
True, but not all web applications need to behave like desktop apps. It really depends on your target audience and the purpose for your application. The kind of stuff I do isn't really of the "quasi desktop app" variety - things like registration forms for campus events, or application forms for scholarships and special courses. When all you're doing is typing in your contact info and selecting what time of day you're available, or why you deserve a couple grand a year toward tuition, there's just not much of a need for "desktop-like functionality".

I absolutely don't deny that desktop-like functionality is fantastic in certain contexts - like Google Apps, WYSIWYG online webpage builders, Flickr photo organization, etc. But I do think that this trend is unnecessary for more traditional dynamic websites that are either just displaying content or letting you do something simple like typing in your email address and clicking "OK".

We have different goals then. I used to work for a University and am pretty close to life as a web guy at a university, and I also used to do this myself several years ago. I understand where you are coming from. However, I'm doing a lot of stuff for musicians and private corps now, where sex appeal is desirable.
I do understand that completely - for instance, I expect the web portfolio of an artist or photographer to be very graphically-oriented and sexy. I don't, however, expect the online resume of an electrical engineer to have a lot of sex appeal. Different audiences, different goals, different functionality.

Again, you're only looking at the server being a variable. What about the amount of time it takes for your browser to render content? How about on mobile devices or slower computers? The browser still has to generate the layout based on the HTML/CSS output, you don't get this for free.

No, but you're still rendering it.
True. However, with the popularity of the iPhone, have you noticed that more and more major sites are making mobile versions that render much more quickly (and are much more usable on a small QVGA screen)? eBay and Amazon fairly recently released the mobile versions of their sites, and they are awesome.

Your point about the length of time it takes a browser to render the content is a valid one, but JS navigation or not, the browser is still going to have to load (and cache) that content the first time you visit the page.

Isn't this operating under the basis that these problems are unsolvable? I pointed you right at the YUI browser history library, which is one such way of solving this problem. If you are making general statements or rants directed at the world as a whole, please direct them accordingly...
I'm not really ranting at you, besson. I'm just commenting on things that I think are relevant to the discussion at hand. Yes, your Yahoo example is a very good solution to the problems posed by JS navigation. I don't see any problems with it, except that not many designers take the time to do something like that.

Tables are fussy if there is no content in a cell, have you not come across this yourself? You can force space with an empty div tag, but if you are going to go this far why not just use inline-blocks for your cells?
You can also directly manipulate the width and height of TD and TH tags. I use TH tags on all the tables I create, because I use tables for outputting tables of data, so a header row is rather necessary. Setting the width of the column's TH ensures that the cells in that column will all be the expected width.

I came up with some examples: dynamic cell/row modifications, precise spacing. A calendar is actually a *bad* use of a table if you want to make each cell precisely the same size and you don't want anything to force this from being changed, such as when you want to write stuff into each cell. Yes you can put div tags in each cell to sort of force this, but that's silly, IMHO.
I think it really just depends. For instance, if you're just displaying a little calendar for navigating posts on a blog site, a table is going to work fine, since the content is fairly static.

Take, for example, another work in progress:

http://dev1.witzapplecertifiedtraini...lendar/2009/07

The blue spaces will eventually be singe images taken out of the document flow to span across several days. If each day wasn't precisely the same width, something like this wouldn't work. The version of my calendar before this was actually in a table layout, and it was *much* more difficult to fine tune than this inline-block one.

This, I think, is also another suitable use for Javascript. If just want to peak at one of the events to quickly compare it to another to fine the course I want to take, why should I wait for the entire page to load when I can move in between months and events so much faster this way, and events/months I've been to already are cached into memory?
I agree. Between that and the clovertone site (yes, I realize it's still in development), I like how this is implemented better - the Read More link at the bottom of the chosen activity gives you a clear permanent link to the information about that activity/event.

I'm not really a fan of how your scripts force scrolling my window to a certain location, though - this is even more important when you're loading data with JS, because the person is going to keep looking at the page content while they wait for the selected content to load. By forcing a change in the viewport, you're forcing your user to visually re-find the content.

So, when you come across a site that is entirely in Flash, do you refuse to use it? I think you would be surprised about what a lot of people use bookmarks for and what they bookmark and not bookmark. This is tangential to this debate, you don't have to repeat everything you said about the importance of bookmarkable pages, I never really disagreed with you.... just sayin'.
If it takes too long to load and the content isn't particularly important to me, no, I don't waste my time on all-Flash sites. I find Flash sites to be incredibly annoying. The effects on links are obnoxious, scrolling doesn't work as expected, I can't middle-click to open new tabs, the Ctrl-W shortcut button on my mouse doesn't work...

Whoever had the bright idea to make a website entirely in Flash should be shot in the face.

Can you give me an example? I don't mean this in a confrontational way, I've never delved into ColdFusion at all. It's not at all an option for me because non-Apache non-Unix is a deal breaker for me, but I'm curious...
ColdFusion has a lot of built-in functions that don't exist in PHP. The language is very verbose and explicit, which gives you some extra capabilities with things like comparison operators. For instance, instead of having to use a substring function to find a substring in a given string, you just use the CONTAINS or DOES NOT CONTAIN operator. CF also does a beautiful job of taking data - query results, posted web forms, session data, etc. - and putting it into a structure that can then be manipulated with a variety of struct functions. It also then lets you access the many levels of a structure very easily - e.g. if you have foo and bar as sublevels under the main fubar level, you can reference them like fubar.foo.bar instead of having to find the arbitrary number pointer of that level in the structure, etc.

You can also create new structures for things like storing a query in session. And, although this probably sounds trivial, ColdFusion provides the extremely useful CFDUMP tag that lets you dump out any variable or structure in a very nicely formatted HTML table with color-coding and collapsible sections. It just makes it easier to debug problems and work with posted form data during development.

ColdFusion also has something called the "query of queries", which lets you run an SQL query against the results of a query you've already run. It's fast and very handy in certain situations.

ColdFusion is wannabe object-oriented, too. The backend stuff like database queries is handled by .CFC files that are invoked in your actual webpages. You can pass arguments to these functions, which can then pass back data, redirect you, etc. It also has very well-developed native error handling functions. PHP's error handling options aren't quite as easy to use (not to mention that fatal errors can't be trapped in a way that allows you to prevent the user from seeing the plain error page).

Which is another thing - I really hate how PHP can't do page redirects after the HTTP header has already been sent. ColdFusion's CFLOCATION tag lets you redirect your user to a new page whenever the hell you want to.

Yeah, but what use is the snazziest of web applications that runs on IIS, hypothetically speaking? I like my mod_rewrite, my basic auth, my compression, etc. I've never touched IIS, can you do all of this stuff there remotely without a GUI? Again, another one of those non-confrontational honestly don't know questions...
I haven't done much with IIS management aside from when I did ASP.NET stuff for a couple courses in college, and I've got an IIS server running at home now (although it's not live at the moment). Don't get me wrong - Apache is fantastic. There are certainly things about IIS that are far more annoying compared to how Apache lets you do things, like mod_rewrite and .htaccess files.

I'm not saying that ColdFusion is better due to the fact that it runs on IIS. In fact, I wish that it did run on Apache, because that's what my VPS runs. In order to do CF development for my own learning on the side, I have no choice but to run IIS. I'm just saying that I'm a bit suspicious of the massive orgy that has followed the popularity of Ruby on Rails. I've found blogs that tout how amaaaaaazing it is, going so far as saying that all other languages suck for a variety of completely BS reasons (my favorite one so far is that RoR doesn't have an IDE, and real programmers use emacs).

Agreed there, but who uses inline CSS for everything? It makes no logical sense to do so...
I was talking about the auto-generated source from that framework that Cold Warrior linked.

Your posting contradicts this. You make it seem like using Javascript for any sort of navigation is an inevitable fail? Perhaps your rhetoric is a little overblown or something?
In my experience, it's been a huge fail. I haven't encountered a site with JS navigation that implements something like that Yahoo solution.
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 10, 2009, 03:02 AM
 
Originally Posted by shifuimam View Post
True, but my issue isn't specifically with your site as much as it is with web designers who implement JavaScript-based navigation without accommodating the millions of Internet users who like to bookmark pages and send links to friends.
You need to be careful about how you word these sorts of things, Shif. Some people get very defensive when they feel like their work is being criticized. It needs to be treated with more delicacy, my advice. I took what you wrote with a huge grain of salt because I know you are very, er, opinionated (so am I), but if I didn't know this I would probably be pretty offended.

I think that are some universal expectations and unofficial standards, however. There are expected behaviors in any piece of software, for instance, which is why people tend to bitch when an application doesn't follow the standard conventions of the environment. For instance, Lotus Notes is terrible about this - the keyboard shortcuts they use for everything except the absolute most basic thing - cutting/copying and pasting - are different compared to every other Windows application one would encounter in an enterprise environment. It's frustrating, because the core functionality you expect in an email application behaves differently, requiring you to read the help documentation just to do basic things in the application.
I agree completely. Unfortunately, the web is sort of the wild west now. With people who want their web apps to look like their Desktop apps (e.g. many of the Safari users that complain about the look of Firefox), do we mimic Windows or OS X, or vary depending on the user's user agent? Do we use a save button to save stuff or just save content as it is entered (this varies in some Desktop apps too)? You could add to this list ad nauseum, many more obvious stuff than these first two things that have popped into my head. However, maybe the web interface standards horse has already left the barn, to a certain extent? Do people understand the differences between web apps and Desktop apps? Are these lines being blurred now? I don't have the answer to this, I just do what I can to provide as much usability as I can up to a certain point. Sometimes it is appropriate to take some shortcuts. I don't put every page through rigorous disability tests, for instance. Yes I should, but you know how time constraints are. Some might say that we should be making every page iPhone optimized too, I haven't fully jumped aboard that train yet.

The tradeoff with JavaScript navigation - in the way that it is currently implemented in the sites I've seen - breaks core functionality (the ability to bookmark a page). This would be like saying that the tradeoff to having blue LEDs on your car's dashboard is that your headlights only work during the daytime, or something equally arbitrary and ridiculous.
Like I said, you've made this abundantly clear. I'm not disagreeing, I'm just not as adamant as you.

I don't think with any e-commerce site that there's a good reason to not have individual product pages. At some point, one of your users is going to want to link to a specific product, whether it be in an email, a website, a twitter posting, or something else. It takes very little time to make a single product page; you can reuse the existing code from your category view.
How would the user get there with this current interface, leaving Javascript out of the equation? Would it be confusing/unnecessary clicking on a title only to get the same stuff? I do plan to improve upon this, I just haven't decided how yet.

I don't really have any experience with that particularly specific situation, so I don't know. Perhaps storing in the session the time location on the currently playing song so that playback continues as expected? Maybe an iframe is a better choice. I don't know.
The sessions wouldn't work, you'd still get a music interruption. iFrames are not a better choice, not everybody wants their player at the top of the page, for starters. If you haven't thought this over as I have, perhaps you should have thought twice about pushing your opinion so strongly?

I do understand that completely - for instance, I expect the web portfolio of an artist or photographer to be very graphically-oriented and sexy. I don't, however, expect the online resume of an electrical engineer to have a lot of sex appeal. Different audiences, different goals, different functionality.
Exactly, so maybe your original response was a little overblown? I don't mean to put too fine a point on this, but I see this sort of pattern in many of your posts, such as the ones in the Political Lounge that get contentious. You frequently come out with your guns a blazin' with some pretty strong opinions that really put people on edge. At least warm up a bit

Can I ask a personal question? Do you feel like you have to overcompensate a bit being a female in an often male dominated field?

True. However, with the popularity of the iPhone, have you noticed that more and more major sites are making mobile versions that render much more quickly (and are much more usable on a small QVGA screen)? eBay and Amazon fairly recently released the mobile versions of their sites, and they are awesome.
No, I don't own an iPhone/iPod Touch yet, but I will jump on this soon. I read a lot and my partner does a lot of this sort of stuff, so he's always exposing me to different techniques - different stylesheets for different viewport sizes, etc.

Your point about the length of time it takes a browser to render the content is a valid one, but JS navigation or not, the browser is still going to have to load (and cache) that content the first time you visit the page.
Yes, but getting this out of the way once is better than having to render the same content that was already loaded once and doesn't need to be reloaded over and over again.

This is why, as I said, partial page reloading is indeed the future. There are problems to solve with it, there are always wrinkles along the way with technological transitions, but this is definitely where I see things going.

You can also directly manipulate the width and height of TD and TH tags. I use TH tags on all the tables I create, because I use tables for outputting tables of data, so a header row is rather necessary. Setting the width of the column's TH ensures that the cells in that column will all be the expected width.
I've never had any luck whatsoever being precise with my CSS in tables, and I've tried every damn thing. I don't have any examples right now to prove this, but for now you'll just have to trust me that tables can be fussy if you need very fine and precise display control. For just a general table where you don't need this sort of fanciness, sure, tables are fine. Just don't use them for page layout, this is semantically wrong and your site will suffer from it from pageranks alone!

I'm not really a fan of how your scripts force scrolling my window to a certain location, though - this is even more important when you're loading data with JS, because the person is going to keep looking at the page content while they wait for the selected content to load. By forcing a change in the viewport, you're forcing your user to visually re-find the content.
I haven't decided on whether I like this or not. It's literally one line of code, so it can be easily removed or disabled. Sometimes though, when you make an AJAX call it is nice to provide some feedback as to what changed. I often like using the Scriptaculous highlight effect for that, but it all just depends.

If it takes too long to load and the content isn't particularly important to me, no, I don't waste my time on all-Flash sites. I find Flash sites to be incredibly annoying. The effects on links are obnoxious, scrolling doesn't work as expected, I can't middle-click to open new tabs, the Ctrl-W shortcut button on my mouse doesn't work...
I agree, I have never understood the draw to Flash sites. The difficulty maintaining them alone would be a deal breaker to me as a customer.

ColdFusion has a lot of built-in functions that don't exist in PHP. The language is very verbose and explicit, which gives you some extra capabilities with things like comparison operators. For instance, instead of having to use a substring function to find a substring in a given string, you just use the CONTAINS or DOES NOT CONTAIN operator.
I can see how that would be useful to people who don't have regular expression syntax under their belt, but with enough practice you can do really powerful stuff with this syntax, including contain/doesn't contain (and PHP provides pattern matching of strings). I would say that it is worth it for most developers to learn this syntax.

CF also does a beautiful job of taking data - query results, posted web forms, session data, etc. - and putting it into a structure that can then be manipulated with a variety of struct functions. It also then lets you access the many levels of a structure very easily - e.g. if you have foo and bar as sublevels under the main fubar level, you can reference them like fubar.foo.bar instead of having to find the arbitrary number pointer of that level in the structure, etc.
What do you mean by sublevels? Subqueries? Or, are you talking about a general object oriented style of code?

You can also create new structures for things like storing a query in session. And, although this probably sounds trivial, ColdFusion provides the extremely useful CFDUMP tag that lets you dump out any variable or structure in a very nicely formatted HTML table with color-coding and collapsible sections. It just makes it easier to debug problems and work with posted form data during development.
Cool, I'd have to see that, but debug options are always nice. I usually just rely on print_r() for that, myself...

ColdFusion also has something called the "query of queries", which lets you run an SQL query against the results of a query you've already run. It's fast and very handy in certain situations.
subselects?

ColdFusion is wannabe object-oriented, too. The backend stuff like database queries is handled by .CFC files that are invoked in your actual webpages. You can pass arguments to these functions, which can then pass back data, redirect you, etc. It also has very well-developed native error handling functions. PHP's error handling options aren't quite as easy to use (not to mention that fatal errors can't be trapped in a way that allows you to prevent the user from seeing the plain error page).
How about display_errors PHP configuration option in php.ini?

Which is another thing - I really hate how PHP can't do page redirects after the HTTP header has already been sent. ColdFusion's CFLOCATION tag lets you redirect your user to a new page whenever the hell you want to.
Sure it can, there is an option in your php.ini to do this. I can dig it up if you care.

I've found blogs that tout how amaaaaaazing it is, going so far as saying that all other languages suck for a variety of completely BS reasons (my favorite one so far is that RoR doesn't have an IDE, and real programmers use emacs).
It is a great language, from a language purist's point of view. You'd be hard pressed to find an experienced computer scientist who didn't appreciate the Ruby or Python way of doing things. I've talked to many, and Ruby is always a favorite. This isn't the same as saying that every site should be in Ruby, or that you should switch to Ruby, or any of that though...
[/QUOTE]
     
Warren Pease
Mac Enthusiast
Join Date: Jan 2007
Status: Offline
Reply With Quote
Aug 27, 2009, 07:36 PM
 
Shif,

Have you used RoR? I did zero web development two years ago, then I got a job doing it We used CF initially and I cut my teeth on it - learned a lot about web development using it and it did the job. Fortunately for me, my boss had written a CF CRUD library which made working with model objects much easier.

The thing I hated about CF is that that it is very verbose. Every command is a tag so it's two extra characters ('<' and '>') for every command - which gets old really fast. If you want to do simple variable assignment, instead of:

var a = 5;

you'd have to write:

<cfset var a = 5;>

There is CFScript but it has only a limited vocabulary compared to the CFML versions, and always the commands I wanted to use (can't cfquery with CFScript for instance). Having the CRUD library helped because you could abstract that layer away.

I wrote a couple apps with CF and it worked, but it always seemed like it was kind of half-assed language. They tried to put in useful features, but managed to screw things up royally - I'm thinking of the so-called JSON support in CF8 which produced some crazy looking stuff:

Code:
{"ROWCOUNT":2, "COLUMNS":["CITY","STATE"],"DATA":{"City":["Newton","San Jose"],"State":["MA","CA"]}}
I can see where they're coming from with how query's are returned but if your rowcount is 100, that is an awful mess to wade through just to find out what town and state for a record 72 records in. I ended up writing my own JSON which outputs something like you'd expect to use.

Thankfully, it was around the release that CF8 that IT decided to EOL CF. I still use CF to create one-off scripts for the express purpose for migrating DB's off MSSQL to MySQL. It's good for that.

PHP has been a horrible mess too. I've developed a couple apps with CakePHP (and find it lacking in many regards, but still it works). Everybody is trying to get excited about Drupal, but it seems like too much.

Unfortunately, RoR is not an option at work, though given my druthers, I'd be using it full-time. Ruby as a language is a very concise language and Rails is well thought out: Migrations, Fixture, HAML.

I use Migrations and Fixtures in my work PHP projects to quickly create and populate test databases. It's far easier than creating tables in phpmyadmin and then trying to create 10 records for testing. Rails wraps it all up into a two commands (one line):

rake db:migrate:reset && rake db:fixtures:load

The quality of the plugins is great and greatly simplifies development. Have used Paperclip for nearly instant file attachments (with built-in thumbnailing images) and HAML.

I've spent 20 hours trying to make a decent HAML parser for CakePHP - it ain't easy.
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Aug 27, 2009, 08:20 PM
 
I love Haml. I use it for non-Rails work too — it's just so nice and readable. If I make a mistake, it's easy to spot. After the lumpy tag soup of the last PHP project I had to maintain, it's like a glass of cold water in hell.

By the way, there's already a couple of Haml implementations for PHP. phpHaml PHAML

Can't comment on how they work with CakePHP. I haven't heard good things about Cake in general, but a Google search seems to suggest you can use Haml with it.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
Warren Pease
Mac Enthusiast
Join Date: Jan 2007
Status: Offline
Reply With Quote
Aug 27, 2009, 08:49 PM
 
Cake has some arbitrary conventions. For instance, partials (called elements) have to live in app/views/elements/model_name/ whereas the regular controller action views live in app/views/model_name/. Basically, if you use elements, supposedly to make your life easier, DRY and all that, you have to maintain two different sets of views in two different locations. Having recently looked at the code of the rendering View class, the requirement to use the elements/ folder is simply hard-coded into the class - no real rhyme or reason to that 'convention'.

They exist supposedly to make things easier.

I've since made my own subclass to deal with that one issue, but still, things should be simple at first (and harder if you need them to be).

There are two Haml parsers for Cake; one I could get to work mostly, and the other, I never had any success with. Both projects last activity is late 2007/early 2008 :/

The first one is based off phphaml, but didn't allow for using partials (or elements in Cake lingo) which I need to do anything productive. That is the one I've been trying to hack w/o much success.

I'll have a look at the PHAML library and see if that works out better. Thanks for the suggestion
( Last edited by Warren Pease; Aug 27, 2009 at 08:57 PM. )
     
besson3c  (op)
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Aug 27, 2009, 09:31 PM
 
Have you guys looked at other PHP frameworks, such as Kohana?

I'll have to take a closer look at HAML... Thanks for turning me on to that!
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 03:01 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,