This question came in today and I thought it was an excellent one to share with my readers. It is also one of those questions with a lot of different takes so I hope my readers chime in with their own opinions as well. The reader wants to remain anonymous, but I really feel like he is in a similar position as a lot of my other readers as well. So, let's get into it.
First, some background (that I'm mangling a bit to help keep his anonymity so please excuse any awkwardness).
12 years in IT. Started as helpdesk tech, budget cuts inherited systems/server admin, more budget cuts inherited developer position, more budget cuts inherited Adobe Connect Admin and server cluster, even MORE budget cut and absorbed DBA position, but hired helpdesk guy. My organization has around 450 employees spread across the organization and state. So roughly, I'm ... Systems/Server Admin, Web Developer, DBA and Connect Admin. I consider myself a decent CF and .Net programmer (.net MVC mainly). To clarify I am NOT talking about designing Apps, just websites/web applications.
While I was in a different role, I was doing roughly the same over the past decade as well. (Although I only used .Net for a little while.)
Now - the questions:
The more courses and conferences I go to and the more I learn/read about the need to move my server side websites and applications to more client side with 100% responsiveness (which to me, means built on a js platform, with a bootstrap framework). Is this thought process correct?
Technically you are talking about two very different things. One is about moving to the client side and the second is about responsive design. I'm going to completely ignore the responsive question since it is a bit off topic. Let's carry on though with his next question as it directly relates to the above.
Is it even possible to 100% replace all the server side CF and .Net code with JS to bring db calls and such client side? Is it necessary? Or is still having CF/.Net server code ok? This is my big question....should I start dumping/migrating these technologies and move in a js direction?
When I began my development career, I was mainly doing simple HTML sites. I started using JavaScript when it was LiveScript. But I quickly discovered that my design skills weren't really up to snuff, and I enjoyed building dynamic sites a lot more. (Back then it was in Perl CGI.)
I started doing more and more server-side work and leaving the client behind. My only real front-end work was taking a PSD and turning it into a table-based layout. (Yes, I used tables. They worked. Deal with it.)
It was only a few years back that I turned my attention back to the client-side. If you've followed this blog for many years, then you know what happened next. I spent a heck of a lot of time researching and learning about the client-side. When I had left it was an IE6-induced mire of pain and agony. Now it's much better.
So enough rambling - he asked - is it possible to 100% replace server-side code with client-side code? No. But you can do a heck of lot more on the client-side then you could in the past. You still have browser incompatibility issues to be concerned about, but the environment is just so much stronger now. Plus, many of these new sexy tools degrade well. It is no longer a case of, "I can use X if IE6 supports it", but rather, "I can use X because I know that if your browser doesn't support it, I gracefully degrade."
It feels like we went from a dumb-client/smart server playground to a smart(er)-client/smart server system. That's good all around in my opinion.
You shouldn't be thinking about replacing your server-side code but complementing it.
If js is the way to go (which quoting you and many others it is), what direction do I go? I get overloaded with which structure to use (backbone VS jq mobile VS angular etc).
JavaScript is one part of the whole. HTML has also come a long way. HTML5 has been hyped out of the yingyang, but it has brought some pretty darn useful, practical features. Finally, CSS is really improving as well. Don't just think of JS, but the whole of client-side development.
So... yeah. You feel overloaded. I do too. I think I've been honest on this blog with my struggles in understanding how to better write JavaScript code. I am a big believer in starting slowly. I really wouldn't be concerned about the JS frameworks out there. They exist. They solve problems. You don't have them yet. You need to learn the syntax. Get the basics under your belt. Trust me - you're going to know when you need something like Backbone or Angular. You're going to run into the same issues you run into the server-side. Where to put your code - how best to reuse code so you aren't violating DRY. You'll (hopefully) have that itch at the back of your brain that says, "I know I can write this code, but something tells me I can do this better."
I don't know if I am going 100 different directions at once and am being more confusing with each abstract question.
You aren't alone. There are - currently - more JavaScript libraries than atoms in the universe. (That number may not be 100% accurate - but it probably will be by noon tomorrow.) As I said above - start small and focus in one thing at a time. I'd strongly urge you to consider the Mozilla Developer Network. It covers all aspects of client-side development and is not focused on Firefox only (as I thought for a long time).
p.s. Ok, responsive design is important. I feel bad ignoring that aspect of his email, but since it was a bit focused in and his main concerns were at a higher level, I thought it was best to ignore it in the main article. Feel free to chastise me for that in the comments. ;)
Archived Comments
I started playing with AJAX at my last job and fell in love with it. My current job prevents me from using AJAX as much because everything has to be compliant with Section 508. Nothing about responsive design prevents a site from being 508-compliant, but poorly implemented AJAX can.
I would like to see more information on how to properly design a site that uses AJAX to asynchronously update the information on the page while remaining 508-compliant.
@Paul: you seek "Progressive Enhancement".
Progressive Enhancement is a development technique that stresses the primacy of the semantic HTML, then testing for browser-capability and conditionally "layering" on JavaScript and/or CSS enhancements for the browsers that can utilize those enhancements.
One of the keys is understanding that we're testing for what the browser can do, as opposed to browser-sniffing. Modernizr is a very popular browser-capability test suite.
Progressive-Enhancement is inherently (section 508) accessible; it provides for meeting the letter of the law and the spirit of the rule.
The Filament Group wrote the excellent "Designing With Progressive Enhancement" book (http://filamentgroup.com/dw... on the subject. (I am not affiliated with Filament Group, though they are so freaking smart I wish I were.)
Check out "A List Apart's" excellent intro (http://alistapart.com/artic... on the topic.
I learned this morning about another framework called Meteor where they say "the same language you use to set up jQuery slider plugins can also be used to query your app’s database!"
http://www.smashingmagazine...
I think the economics of having a shared ColdFusion or Railo account make it not worth the effort for me to use JavaScript. ColdFusion is much easier to work with than JavaScript.
That being said, even ColdFusion can be daunting - after doing a lot of plunking around, I decided not to use ORM and to even discontinue using cfquery. Instead, I now use the new cfscript hotness setSQL and execute inside of scripted components. This of course requires ColdFusion 9+.
So even if you stick with what seems to be the simpler approach, there is still a lot to learn/relearn.
"I think the economics of having a shared ColdFusion or Railo account make it not worth the effort for me to use JavaScript. ColdFusion is much easier to work with than JavaScript."
I'm sorry - can you explain this? I fail to see how the cost of CF, or the lack of cost of Railo, would stop you from using JavaScript.
It might be tempting to replace all ColdFusion code with node.js or another JavaScript library like Meteor. But JavaScript is a much harder language to work with, and the cost of running ColdFusion is not that prohibitive.
One argument might be that writing server side code in the same language as their client side code would make things simpler. But ColdFusion code is already simple. I struggle with JavaScript. When I get into the ColdFusion lane, it's clear sailing.
You're talking about replacing CF with another server-side platform. That isn't at all what we are talking about. The original person was asking if you could replace server-side code with client-side code. JS on the Server isn't client-side code.
@Raymond, Phillip may not be talking about exactly the same thing in terms of smarter clients vs. leaner clients, but he does bring up another point which is core to the main discussion. As clients get smarter and more of the app is written javascript, at what point does it make sense to then consider "standardizing" the code across the client and server with one language by using something like Node.js as he describes.
Not that I'm looking for you to provide this answer, but it is does open up another set of the million and one considerations that are out there regarding how we might architect a modern application that will naturally be more js heavy than something that was written in years past.
I think it would be a consideration. If I were a client-side dev who did not have server-side experience, something like Node would be *very* appealing.
To add a bit to that, @Phillip, I think we can agree that JavaScript will make it's way into your application one way or another. You simply cannot write a modern web application without JavaScript, so avoiding it altogether is certainly not a feasible option.
There are techniques, however, that you can certainly employ which will aide in keeping more of your code (and business logic) on the server and away from the client, which I think would be more central to the main theme of the discussion. Even relatively simple js, though, tends to get unwieldy quickly, leading you to quickly realize "you're going to need something" to help manage it (quoting the feeling that Ray describes in the article).
One such example I have recently faced in my own projects is the decision between (when making ajax calls) whether to return markup rendered in a cf template (the server-heavy approach) vs. going the more modern approach and returning straight json and handing the rendering of the markup using a client side templating system like handlebars (the smarter-client approach).
For the moment, I have begun porting my markup into handlebars in order to transfer less data over the wire (json being lighter weight than html), but it is a bit of a tedious process as I have always been in the habit of writing my template markup in cf, meaning there are many templates to refactor. With that said, if you wanted to let cf do more of the work, arguments can certainly be made that would keep the js side of your application lighter by continuing to render the templates on the server.
Nothing groundbreaking of course, just thought I would share an example of something I am dealing with along these lines.
Brian - just to make things even more confusing (grin), the folks at Twitter actually ended up moving *away* from templating on the client. They found that for older browsers, they could get better performance doing the rendering on the server and returning HTML.
I'm not saying that you should follow the same, client-side templating works fine for me and I recommend it, just putting the thought in your head.
There's many way to skin the cat so to speak in web development. That's what keeps the hair gray. ;)
Haha yes Ray, it would be too easy otherwise :) I think that's what makes this line of work so much fun though (at least that's what my optimistic side tells me). I guess in the end we all need to decide for our specific projects and user demographics what makes the most sense.
I hadn't heard that about Twitter's decision though, thank you for sharing. For what it's worth, I did come across this performance comparison by Ryan Florence written last year where he provides a nice analysis and even has a series of test requests that run and return realtime speed results. Anyone can check it out here if interested:
http://ryanflorence.com/201...