I’ve been chatting with the Free Software Foundation and they’ve posed a tricky question: What is trivial JavaScript? – or – What is not trivial JavaScript?
It seems like an especially hard question to answer – especially without using subjective terms.
For example I would say that the following are all trivial:
- Use of inline JavaScript/DOM 0-style code (ex. onclick=”…”).
- Use of unobtrusive scripting to layer on basic page behaviors (ex. Twitter).
Whereas the following are sufficiently complex as to be deemed not trivial:
- Applications that do Ajax requests to a server-side component (ex. GMail).
- Applications where the majority of the initial download is executable code (ex. 280 Slides).
- Applications that are unable to function without the use of JavaScript (ex. Google Maps).
But this brings up the question: What about poorly-designed pages that have a small amount of JavaScript but are unable to function without the use of JavaScript? I’d still deem it trivial.
And what about sites that are somewhere in-between? For example Netflix has a significant amount of unobtrusive JavaScript on their site but I would hardly consider it to be trivial (pop-ups, Ajax-loading, all sorts of unobtrusive interaction).
Is there a tangible line that is crossed on the road to complex JavaScript development? Is it an externality like storing script in a separate file (ex. <script src=’…’></script>)? or is it inside the script itself like in using Function prototypes or closures? It feels like the measure should be put upon an external source (as to not make restrictions upon what someone could, or couldn’t, write using the language) but what would the proper external measurement be?
Thoughts?
Greg (June 10, 2008 at 8:38 am)
I don’t think you can draw a line with something like this. Far too subjective. What you lay out is probably a good approximation of what the term means for a lot of people, though.
Aditya Mukherjee (June 10, 2008 at 8:45 am)
Any Javascript that is used to cosmetics rather than functionality, is trivial. Any bit of code that is not *needed*, is trivial – which is clear from the definition itself.
Taking the example of Script.aculo.us. The library itself is some fairly complicated Javascript. However, the end purpose is simply effects (not going into UI elements like auto-completers). Sliding/scrolling/fades are all generally one function code that doesn’t too long to write, and the output is a single action.
I say triviality lies in the final output. You can write a 100 line or a 1 line code to generate a box to show a message to a user. At the end, you’re just showing a message.
Joe D'Andrea (June 10, 2008 at 9:01 am)
Depends on what the FSF defines trivial as. A quick lookup reveals “small and of little importance” and “of little significance or value.”
Let’s suppose the FSF defines trivial as small. “Let’s get small.” :)
In that case, trivial JavaScript could very well be nothing more than minimal JavaScript. Minimal code entropy, as it were.
On to the significance/value/importance part. By trivial does the FSF only mean core, POJ (Plain Old JavaScript)? No jQuery or other library assistance?
If libraries are fair game, then it could be said that jQuery turns up the dial on value while keeping entropy nice and low, a.k.a. a lot of bang for the buck!
Eddie Welker (June 10, 2008 at 9:01 am)
Question doesn’t really have much to do with Javascript, it’s more a demonstration of a person’s definition of “trivial.” But I get the point.
You could say that non-trivial is something that’s genuinely useful, regardless of how it was written. Non-trivial could be something written in a “best-practices” sort of style. Or you could say non-trivial is code written in a style that requires significant/advanced study of the language. But even wrapping these all together, you’re gonna be tripped up by the subjective word ‘trivial’.
Additionally, your definition will be much harder if you try to mix two views (code style, and what the code actually does). You can write something using all of the closures you want, but it will matter little if it only converts Celsius to Fahrenheit.
Iraê (June 10, 2008 at 9:07 am)
I like the Aditya’s point of view. Although I think trivial javascript is something that:
– Does a single task
– Do it in an simple way
– Works cross browser even without tweeks
Lets use “show a message” example. If you show a message using something like innerHTML to a div if some inputs are incorrectly filed atatched by an inline onclick=”myFunc()” its trivial. If you place an absolute positioned div with events added when the dom is ready it’s not trivial, since you have to consider cross browser inconsistencies during your task and you could trigger memory leaks and many more problems.
I think libs like jQuery, Prototype, Dojo, etc are the tools to write a kinda trivial code backgrounded by an untrivial code.
Jan (June 10, 2008 at 9:08 am)
Colour me ignorant, but why would such a distinction be of interest or practical use? And what does the FSF has to do with it? :)
Will Larson (June 10, 2008 at 9:14 am)
If we assume that question is emphasizing JavaScript, instead of just being a sneaky way of asking “What is trivial code?”, then I think my definition would be “Any JavaScript that can be understood by programmers who hasn’t studied JavaScript.” I would be a bit skeptical of any response which doesn’t involve the word JavaScript at least once. ;)
Frederick Polgardy (June 10, 2008 at 9:30 am)
It feels to me like the question: When does a group become a mob? :-) The 10th person? The 100th? There isn’t a simple, clearly identifiable transition point – and yet, you know a mob when you see one. There are signs that a chunk of JavaScript may be non-trivial – as you say, the use of inheritance patterns, closures, modules, etc. – but to me it’s more a high-level question of how much layering is present in the code – is it more “structured” or more “stream of consciousness,” etc.
John Resig (June 10, 2008 at 9:35 am)
After doing some thinking one clear thing that has arisen is that on one side of “JavaScript is required to make effective use of a web page” is trivial JavaScript and on another is non-trivial JavaScript. However what isn’t clear is the width of this gap (really, it’s just a subjective gap at this point). It shouldn’t matter how many lines it took to write it or in how many browsers it works in so long as the use of JavaScript is required in order to make effective use of a site.
@Aditya and Iraê: The issue that I have with your particular point of view is that it’s really hard to quantify. At which point does the implementation of some code become not trivial? 5 lines? 100 lines? How does browser support factor in – how do you determine what a good level of browser support is? Is an email application built to work in IE6 trivial because it doesn’t support multiple browsers?
@Jan: I’m not sure yet – I’ll be meeting with them some time this week. I’m assuming that it’s related to licensing or IP issues.
Jan (June 10, 2008 at 9:45 am)
@john sounds like a huge source of confusion and possible loopholes to me.
Jeremy Martin (June 10, 2008 at 9:49 am)
That is an interesting question. I would contend that it depends on who’s talking. If we’re defining trivial based on the ease or simplicity of development, then the definition is dependent on the coder. The way I see it, something may be “trivial” for a seasoned developer, yet complex for a newbie. I suppose sooner or later the size of the code plays a factor, but it’s definitely a lot harder to put a finger on what makes my line of code trivial and yours not.
Marty Alchin (June 10, 2008 at 10:22 am)
Personally, I’d define trivial code (in any language, JavaScript included) as code you can read and write without looking up anything in an external resource. Essentially, if you know it off the top of your head, it’s trivial; if you have to look it up for any reason, it’s non-trivial.
Of course, that not only underscores the subjectivity of this issue, but explicitly relies on it, as well as the skill level of the individual developer. For instance, there was a time when closures were a complete mystery to me, but now I consider them trivial, and I’m consistently amazed when professional web developers don’t know what they are. Much of what people like you and PPK might consider trivial probably looks like ancient Greek to somebody getting started with a MySpace page.
Micah (June 10, 2008 at 11:46 am)
Let’s perhaps put the crosshairs on the “dependancy” factor.
Case Study 1: Someone finds a circa 1998 web page with a copy-n-paste javascript snippet. If most persons in the market for copy-paste JS can get this working in their own page in a couple of steps, and wham! you done with it – that’s trivial javascript.
Case Study 2: Some guy who used to lurk the innerWebs in ’98 learning JS byHook() or byCrook(), but THESE days stays up at night contemplating whether the performance boost of the latest jQuery release is worth re-testing implementations (browser quirk hunting anyone?) with the previous point release, yet for him it remains a thought experiment because cruising tech blogs is an increasingly consuming diversion … theoretically speaking – that’s non-trivial javascript.
The inter-dependencies: Browsers/JS Runtimes, JS frameworks, Unpredictable user input (HTML!) in some CMS scenarios. Once you care about standards, diligent cross-browser testing, better and better usability, meeting the needs of a wide range of users – well, there are lots of moving parts that can break down (or work beautifully – but that’s the glass half full talking).
Anyway, I’m I ranting or meditating … ahem – better come to a full stop.
atom (June 10, 2008 at 12:32 pm)
I would say that anything that is js based progressive enhancement is trivial. If the application requires it and is unable to degrade gracefully without it, I would say non-trivial.
This is assuming the application developer know what they are doing though.
Bradley Sepos (June 10, 2008 at 12:38 pm)
My humble designer’s perspective:
Enhancements to a site, such as popups, rollovers, simple event bindings, and even a little ajax to help usability and decrease pageviews are all trivial to me. When you build an actual web application in whatever capacity, the application as a whole is non-trivial while many of the parts may be trivial individually. To me, the core logic of an application (even if it’s just the “glue” holding together many more generic pieces) is what I consider non-trivial.
That might be too general an explanation for this problem. But I think we can all agree that JavaScript and the browser environment are constantly moving (hopefully forward), and thus our criteria will always be a moving target.
Mike Booth (June 10, 2008 at 3:15 pm)
This is the silliest question ever. I yield the floor to Richard Feynman:
“I still remember a guy sitting on the couch, thinking very hard, and another guy standing in front of him, saying, ‘And therefore such-and-such is true.’
“‘Why is that?’, the guy on the couch asks.
“‘It’s trivial! It’s trivial!’ the standing guy says, and he rapidly reels off a series of logical steps. ‘First you assume thus-and-so, then we have Kerchoff’s this-and-that; then there’s Waffenstoffer’s Theorem, and we substitute this and construct that. Now you put the vector which goes around here and then thus-and-so…’ The guy on the couch is struggling to understand all this stuff, which goes on at high speed for about fifteen minutes!
“Finally the standing guy comes out the other end, and the guy on the couch says, ‘Yeah, yeah. It’s trivial.’
“We physicists were laughing, trying to figure them out. We decided that ‘trivial’ means ‘proved’. So we joked with the mathematicians: ‘We have a new theorem – that mathematicians can prove only trivial theorems, because every theorem that’s proved is trivial.'”
—
I quote all this so that you’ll appreciate what I mean when I suggest that this:
$('div.outer a.ugly').css('display', 'hidden');is trivial Javascript. But it wasn’t always so. And it still might not be so for everyone.
Once you answer this question, can you tell me how many Javascript programmers fit on the head of a pin? :)
Su (June 10, 2008 at 3:24 pm)
I think I’ve missed something. What’s this question actually about, eg. where did the term “trivial Javascript” even come from? Is someone trying to draw a line for where it becomes pointless/questionable to apply a license to a chunk of JS, or something?
Konijn (June 10, 2008 at 3:59 pm)
Some potential pointers,
* if you needed to code to make it work on multiple browsers-> not trivial
* if you had to comment it because you knew you would confuse yourself or fellow coders -> not trivial
* if you couldnt google for the code under 5 minutes -> not trivial
T.
Aditya Mukherjee (June 10, 2008 at 4:01 pm)
@Su: The point is the complexity of the code. What is ‘serious’ code and what is not.
@John: I’ll restate my first line (without eating up my words :P): “Any Javascript that is used for cosmetics rather than functionality, is trivial.”
JS effects are trivial. JS UI elements aren’t. Cross browserness is an aspect of your code, not the code itself. OOP-JS is by no means trivial, but if you’re using OOP just for the heck of it, then yes, it is trivial.
The functionality of the simplest form of a code should decide whether the code is trivial or not. I hope that makes better sense? This should solve your problem of quantification. It doesn’t matter if something took 5 lines or 100 lines to make. If ultimately it does something cosmetic, or something the application/page doesn’t *need*, it is trivial. A mail application made to work *only* in IE6 is not trivial, because it adds a whole new tool/service (whatever you want to call it).
Frederick Polgardy (June 10, 2008 at 4:43 pm)
@Aditya: I don’t think the cosmetic/functionality distinction is relevant at all. In some circumstances, it actually requires far more complex JavaScript coding to render an effect than it does to perform some business or application function. A cosmetic feature might be a trivial *feature* but it’s not trivial *JavaScript*. Maybe I’m misunderstanding your point.
Felipe Gomes (June 10, 2008 at 7:05 pm)
I consider that non-trivial JavaScript is all JavaScript that is put into thought during the development of a web page or web app. That is, all code that is considered part of the development itself, and not a simple way to do something fancy or interactive on the page.
I imagine that most trivial JavaScript can be generated by automatic tools, which mostly generate horrible and garbage code, but is unfortunately too common around the web.
As an example, if a developer wants to do a fancy menu bar or fade out animation, and then he goes to find or use some tool which just generate the code and says “put this along with script.aculo.us on your page” -> trivial;
now, if the same menu or animation is an important part of your app, and you go and take decisions of what library to use, how to implement it, etc. -> non trivial.
Mostly, it comes down to the difference of whether the code is simply written in an ad-hoc way (if the developer does not truly understand the code or do not care), where he is just following some guide and blindly copying code, or whether design decisions and considerations was used to produce that code. It doesn’t matter if he ended up using innerHTML instead of DOM manip, as far as this was a decision and he understands the differences between each other and has a good explanation over the decision (browser compat, speed?) for example.
The trivial would’ve been if he ended up with innerHTML spaghetti code copied from some legacy code 5 years olde.
(Not that *I* would consider innerHTML nowadays, but it’s just an example)
With such definition, it is possible to do trivial/non-trivial aesthetic stuff, and trivial/non-trivial interaction stuff.
However, it is harder to judge a code as trivial/non-trivial by simply looking into it, without knowledge about the process of its development (if any).
Peter Benoit (June 11, 2008 at 2:39 pm)
Not sure about trivial Javascript, but I’m going to code some trivial c# later, followed up with some moderately trivial Cold Fusion, which should be trivial, but who uses Cold Fusion anymore? :)
Triviality is obviously in the eye of the coder. What John finds trivial, some freshmen developers might find difficult.
-p
Ollie (June 12, 2008 at 8:40 am)
In defence of Google Maps—you may be surprised how well it works without JavaScript! Of course it is the experience that is different with JavaScript, not the essential functionality.
Cris (June 12, 2008 at 10:05 am)
It’s certainly a relevant question when you’re trying to assign resources within a team. Can I give this task to the intern, or do I need to hand it to the senior Javascript guru?
That’s why I agree with Marty Alchin’s reply that subjectivity is actually of critical value in this definition. I need to know what counts as trivial for the people at my disposal. I don’t have PPK or John Resig on my team, so I have to judge “trivial” based on who I actually do have.
ajpiano (June 18, 2008 at 3:03 pm)
Here’s a thought:
I come to a page. My JavaScript is off.
Trivial JS: I can still do everything I needed to and find out everything I was looking for.
Non-trivial JS: I can’t.
I think the question of triviality was based on the code’s relationship to the application, not to the developer’s relationship to the code.
–adam