7 rules of unobstrusive javascript(icant.co.uk) |
7 rules of unobstrusive javascript(icant.co.uk) |
This one needs to be let go of, it is no longer a best practice and it is the norm among many of the most advanced web apps available to not only require JavaScript, but make it the core architectural underpinning of the solution. The days of web apps working without JavaScript have passed.
As of late, the market has refined itself into Web Sites and Web Apps. For web sites a CMS solution should be utilized, but for web apps, more and more it is refining it's own client side toolkits with HTML, CSS and JavaScript becoming the tools of choice.
Note that, as part of this, you'd better have something to show me without Javascript enabled. If I get a "blank page", I'm unlikely to engage further.
I realize I'm increasingly in the minority and that perhaps the world is "passing me by". On the other hand, more and more "normal" people around me are being compromised by exploits and wondering "WTF".
There's a limited role for more advanced, scripted presentation. But a lot of what currently "requires" Javascript is just needless genuflection.
I welcome the discussion. And I realize that I'm an outlier.
Nonetheless, I see a lot of "required" Javascript these days that to me looks rather useless, or at least not really necessary.
I'd be curious as to a description of some of the specific revenue and cost saving advantages. However, I'm not specifically asking that of you, here, as this is an already nested set of comments where the cost/benefit of the effort -- even should you be inclined to consider it -- might well merit it. (And I'm being literal, not somehow snarky, in saying that -- just to be clear.)
If a description is not in the cards but you have some pertinent links handy, I'd welcome the opportunity to take a look at them. (But again, no expectations of a response on my part.)
Regardless, thanks for taking the time to respond. I appreciate the consideration your parent response shows. :-)
P.S. I don't want to sound too much like I'm asking/begging for a further response.
Perhaps I'm a bit of a "parasite". I come to the web mostly to acquire and to share information. Inasmuch, I find a lot of the current scripting a hindrance rather than an aid.
Also, having recently spent a weekend cleaning up a personal contact's business systems from a mal-ware infection (and all the crap that turned up once this crisis prompted them to call me and so cause a closer examination of their systems), I do feel some personal animosity towards poorly defended and utilized vectors for such stuff.
Sure no problem, the first and foremost that I can think of would be self contained widgets for third party sales channels. Lets say I sell hotel rooms. I can build a JavaScript widget that provides rates and inventory in a small list on the side of a page. A related sales site can then just drop it on their site, by adding a div with a certain CSS class assigned to it and it instantly giving me a direct sales channel where there was none. At little to no integration cost to them. So with that widget, I can implement a pretty robust affiliate sales channel. I could do the same with a static image or HTML as advertisement, but having real inventory and prices available is going drive up conversion. Thus it could be said to be a new channel of revenue.
Second would be in certain usage patterns, there are some usage patterns that when you have to submit a page back to the server for every step it becomes cumbersome and requires significantly more code. Lets take a grid for example, say I provide a list of items in a grid and I want that information to be sorted in one of several ways. With the old model of spitting it back to the server I have to hold on to a bunch of info on the server, and generate several views to re-sort it. With a JavaScript grid, I just have a couple of custom sort functions that I pass into the sort method on the array and then re-bind the results to my grid. So what would necessitate 5-6 different views generated by the server, I can manage with just a call to array.sort() the grid can observe the array.sort() and react to it being called. In these kind of multi-path UI workflows not round tripping to the server reduces a good deal of complexity from the system.
For me personally I think getting rid of SP (ASP, PHP, JSP) leads to a more maintainable system, because I think it is simpler. Having the UI and workflow concerns as a separate application that is delivered to the browser helps deal with a lot of Anti-patterns that the SP development model introduced. I prefer to write my front ends disconnected from the server and have their only connection be for data and business processing. I feel that it reduces the complexity of the solution and that it separates the concern of the workflow of a system from the processing of a system nicely. Some will differ on that and some will be more productive in the SP's. For me and the team I work with, we can deliver more compelling apps faster using JavaScript as our UI languadge. As well, I like the fact that the server architecture forces everything to be implemented behind addressable interfaces. It makes going to Mobile or other platforms as simple as creating a new work flow tailored for that specific device. JavaScript applications have evolved to take advantage of what the web is becoming. More and more people are implementing workflows never originally conceived of on top of unrelated back end systems. Taking services from Facebook, and Yelp or twitter etc. and implementing totally novel and new concepts, even if they are wholly unrelated to the companies that provide the services. This was not possible when UI's and data where locked, together, behind proprietary server technologies like the SP's. To me that is the greatest advantage, it provides a UI platform for an internet where all services are available as a collective platform. The entire web becomes the platform and anyone can write a workflow on-top of it.
As for useless features implemented in JavaScript I would say we had the same issue with Flash, just because you can does not make it the reason to do so. All I can speak for are the effort that I am part of and when we embark to build something we try to back it with real business need. Some people don't seems to put as much emphasis on not wasting time and money and I don't see that changing whether it is just a static web page, JavaScript or any other technology.
I don't like having to turn on scripting in order to see anything and to form an initial assessment/opinion, e.g on a front page. In that respect, I still favor "degrading gracefully", or "enhancing gracefully" -- I've seen it described both ways. (And that's just one of the "annoyances" I guess I was referring to.)
Back around the time Gmail was first "oohing" people, I did a small bit of snazzy scripting for a prototype to enable a much more user friendly interface on an internal corporate system. (Unfortunately, the powers that be -- or were -- didn't know what to make of it, and it languished.)
In the wild and woolly web, though, I still have concern about opening the scripting door to compromises. I'm not sure what the solution is to that.
Anyway, thanks very much for taking the time and effort to write up the description. I take your points, and I like numerous aspects of the direction you're describing. It does seem at least somewhat more in line with the so called "web application" paradigm as an alternative and/or successor to the "web page" paradigm.
If I may ask a follow-up, what's your perspective on keeping the pieces and the integration "safe"?
For me, I would like to see the browser sand boxed completely away from the OS, with the cloud this may be a ever closer reality, have drop box like functionality for the browser where if you want to upload a file, you do so from the cloud not your local device. So say I want to send you a picture, I choose the picture from say Picasa or Flicker as opposed to going to my local drive.
I would like to see something like SSL certificates for web providers that want to be able to step past that sandbox. So providers prove their identity to get a certificate that lets browsers access files to upload or native apps are utilized to get content into the cloud. Cutting the filesystem away from the browser is the first step.
Second with HTML 5, there are browser based data stores available to developers. This should be the first option when a developer wants to keep file information on a users system. From there they should offer to save files to the cloud providers. With the way the web is moving, there are less and less legitimate reasons for a web provider to access the native system. If they do, they should be able to justify that reason for a certificate or they should be able to write a native app and supply it via an app store.
Naturally some providers will not like the thought of using an app store, in which case they can offer it for download with a certificate or via a whole lot of security exceptions on the part of the user. Much like Firefox does with a expired SSL certificate where they user has to basically insist that they know what they are doing. I would like to see enterprise controls on that as well, where an IT department can override the user and not allow acceptance of the risk by the user.