

7 rules of unobstrusive javascript - sayanee
http://icant.co.uk/articles/seven-rules-of-unobtrusive-javascript/

======
kls
_You don't expect JavaScript to be available but make it a nice-to-have rather
than a dependency_

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.

~~~
pasbesoin
I disagree. As long as Javascript remains a significant vector for "mal-ware",
I'll leave it disabled by default and remain cautious about opting-in on a
site by site and domain by domain basis. And I'll advise my family, friends,
and users to do the same.

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.

~~~
kls
Please don't take this the wrong way, as it is not my intent to be rude, but
you represent a statistically insignificant amount of revenue. It's smaller
than a percent. But the new technology stacks and the features and services
they can deliver offer real and tangible revenue or cost savings. When
factored in, catering to your use case does not make viable business sense. If
that ever changes, we as an industry will have to re-evaluate the technologies
choices but as it sits now, progress and momentum are behind JavaScript web
applications.

~~~
pasbesoin
In turn, I hope that you didn't find me too rude -- rather, just to my
personal point.

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.

~~~
kls
_I'd be curious as to a description of some of the specific revenue and cost
saving advantages._

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.

~~~
pasbesoin
Well, that all makes sense to me (at a first read). And I will and do opt-in /
enable scripting on a site by site basis in order to engage such features.

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"?

~~~
kls
_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.

