I read this post by Lea Verou about why we want to write our own: In defense of reinventing wheels
When I read this I thought immediately of the multitudes of jQuery threads that aren't actually about jQuery, but generally the use of libraries (and on top of that, "preprocessors", grids, and stuff that completely changes syntax like CoffeeScript).
Her point about performance and maintainability make sense: if you're loading Library X for one little feature, and not using all the other stuff LibX was written for, you're wasting and slowing and complicating. It also means instead of getting your minor task done today it might be another day or two.
Just curious, where is the line?
- for you personally as a developer
- for where you work/team/company
- for random other people you'll never meet but whose code you might have to touch
Also any valid points regarding Lea's article in general will also be interesting, I think.
*edit: I couldn't remember how I came across the article, but going through my subscribed threads... it was originally brought up by Kohoutek and I'm glad she did!
For me, if I can't do it by myself or with a dedicated script that I've cribbed from another site then I won't do it. I don't use JQuery, and I doubt that I ever will. I don't want to saddle users with massive downloads and processor overload just because I can't figure out how to do something properly.
Some scripts I'll write from first principles, others I'll pillage and plunder from other people who've got them working. But if I don't understand what's going on, I won't use it. I don't want magic on my sites, I want engineering. Because when you get magic, you get problems that you can't fix. That's why we get so many umpteen squillion queries a week* from people who have added some pre-packaged library or framework or whatever without having the faintest idea what it does, so invariably there's some conflict or unintended consequence or buggy behaviour when they introduce it into their site, which they are powerless to understand or fix.
It's like people who buy microwaveable ready-meals and then wonder why it's set off their allergies and made them fat, because they didn't read the warning label or understand what went into the food. Cook it from fresh ingredients and you'll know if it's healthy or not.
I am lucky that I have the luxury of not having to produce code to order for other people or have my livelihood depend on my ability to churn out all-singing all-dancing for clients who don't understand web design.
* Warning: this post may contain mild exaggeration
I agree that we need to balance performance vs reusability. But in order to intelligently balance performance, we need to measure performance. It seems to me that the jQuery critics often fail to realize or fail to accept that performance data reveals that jQuery's impact is actually negligable.
For the same reason, Lea's example using Markdown, which she considers a justified reason to reinvent the wheel, I think is actually a bad example. What is Markdown's performance cost? She never measured. She has no idea. So ultimately what happened is, she did extra work to create a less feature rich app, she increased the amount of code that she personally has to manage, and she increased the chance of introducing bugs, all for some unknown performance gain, which I strongly suspect would turn out to be insignificant.
The three laws of reusable code
I. Libraries are reusable code. So libraries are good. No, libraries are gold. Every programmer uses them. Every piece of software relies on them. Who says otherwise, is not a programmer or lies.
II. Since every programmer uses libraries: see I), as a consequence, jQuery is good. No, jQuery is gold. If one argues against it, it should also provide a better code library. If it fails to provide such an alternative library, it should humbly work in silence until it does.
III. Any programmer' goal require reusable code. If a goal may seem to small that it looks like it requires non reusable code, a programmer should apply the laws I) and II).
I'm sorry, but UAs constantly load full, complete CSS processors for web pages that only require 25%-60% or even less from its implementations. How 'bout that?
The three laws of DRY code
I. Preprocessors are good. No, preprocessors are gold...
When I decided I was going to build what was essentially a wiki, I had a I choice, should I use mediawiki (or similar software) or should I build it myself? The advantage of mediawiki is that has a lot of my code done for me but I was not happy with it - think the wikis developed using mediawiki are ugly, difficult to use and I there was a handful a niche components I needed to implement. A select few sites like wikiHow have successfully modified the mediawiki code to their needs but considering I've never used PHP or databases before this point 'reinventing the wheel' and starting from scratch is much easier for me than learning the vast and complicated mediawiki libraries than modifying them to my will. And turns out allowing someone to read, edit, add & delete to a database is really easy - that's essentially what I wiki is and it's one of the first things you learn in php. So I have my wiki, I just got to make it a good one - significantly easier than reverse engineering mediawiki.
To somewhat disagree with TechnoBear, I think good website (or any technology for that matter) should feel like magic - but to get that you need some damn good engineering, they come hand in hand. A clunky framework that creates dumb buggy special effects isn't magic, it doesn't feel like magic, it's just clumsiness rolled in glitter.
The only thing I can say in partial support for this is code ownership. Anything you build yourself you will have a great understanding of. Though the downside of that is once you leave than someone else has to deal with all your decisions without any support. Using a well known and tested library or framework will reduce the gap for the next poor schmuck that needs to maintain a project. I'm pretty stubborn myself but libraries and frameworks have many advantages even if they reduce performance to an extent. In this day and age with all the great libraries and frameworks available I think it is best to use them to some extent. Having to deal with all custom code is a pain… especially when it is ancient and no one exists that originally built the system.
I'm from the age where userland libraries in languages where you don't have compilation before execution -- aka interpreted languages -- are as a rule of thumb idiocy on the scale of fixed fortifications, carbon core reactors, or drilling for oil in a salt mine situated below a lake. Figuring in a narrow transmission pipe for user-side execution into the equation only further multiplies this effect.
But that requires a distinction that doesn't even seem to be taught anymore; the difference between userland code and system code. System libraries are usually fine; they're built into the language, they typically use optimized low level or at the very least well compiled code, and in the best cases don't even have extra overhead compared to user operations because they're called via a list of pointers instead of nested case statements or looped IF comparisons.
Userland libraries -- like jquery -- are in the same language as the rest of your code, are not compiled, and typically do nothing more than slow your program, add bloat, and turn any project into a train wreck. They encourage failing to bother even learning how to do what you actually want to do, and in many cases result in larger code than you'd have without the library.
Perfect examples of this being accordion effects; where the average 10k script that requires jquery isn't as efficient or feature rich as 5k of script written without it.
It's why languages like PHP are best used as glue between it's system libraries, more efficient engines like mySQL, user input and HTML output -- it's what they're for... and why massive userland libraries written in it are also quite often fat bloated wrecks many projects would be better off without; see all that templating asshattery like Smarty, or the constant attempts to shoehorn types of MVC into a language and operating process that just aren't built for it like Codeignitor. For every minute 'saved' slapping out some off the shelf solution, it's likely costing minutes of debugging or wondering why the framework does what it does that could be better spent just learning to do it your blasted self.
Ripping things down to the bone and building them back up -- be it people or projects -- is how you make things better. Blindly and unquestionably grabbing a solution off the shelf and then shoving that square peg into the round hole isn't. It might be expedient, but sacrificing quality, functionality and usability on the altar of expedience is short sighted, lazy and typically indicative that perhaps you should go take up something a bit less detail oriented like macramé or knitting... either that or the project had unrealistic goals from the start; a common affliction it seems.
The whole notion of "Don't reinvent the wheel" is typical of the soft unmotivated half-assed approach to doing things typically resorted to by the inept, ignorant or outright lazy; it falls into the same category of thinking as "If you can't say anything nice" or "status quo is good enough". As George Bernard Shaw wrote:
The reasonable man adapts himself to the world; the unreasonable man persists in adapting the world to himself. Therein all progress depends on the unreasonable man.
Besides, let's face it... What if someone had told John Dunlop, Andre Michelin and Philipe Strauss not to reinvent the wheel?
I disagree. I think it is outright inconsiderate to future developers to go off on your own tangent and reinvent things. If your programming your own personal project its fine. However, in a business atmosphere where people come, go and have different beliefs using a tried and true library will result in a smaller learning curve and chance to introduce bugs with ongoing mainenience by people who did not build the original code base. Besides many of open source projects exist have pretty decent documentation. That alone is a good reason to use them regardless of other sacrifices. Not to mention communities of support that is not available when someone goes off and does their own thing. Granted there is a time and place for it but business wise it makes very little sense to not use preexisting technologies to some extent. If not for anything else to reduce mainteniance cost and headaches when the original developer(s) leave. I deal with this problem first hand. I build many applications on a very complex custom templating language similar to PHP built on C and Oracle which was created about 15 years ago. Since the original developers left there has been very little work done on the core system because people are afraid to touch it. Thankfully it is very stable. It would take years of work to convert all the applications that are dependent on it to something modern and well supported. That is what you get when you end up doing your own thing. Though in our case it was acceptable because the system existed even before PHP, Ruby, etc. In closing when you make the decision to reinvent the wheel when an acceptable version of the wheel already exists though maybe not perfect your only thinking about yourself and users. Your not thinking abut the ongoing cost of mainteniance and negative consequences when original developers of that system move on and could care less. At least with a community you have people to ask questions but with custom code your pretty much left to your own devices even if there is documentation… which would probably be doubtful.
... and just what makes said libraries ANY different in that regard? With so many of them what are the odds anyone else is going to know that any more than the language being used? If anything libraries reduce the odds of the next poor shlub maintaining it having an easy time of it, because you then have to have someone that knows the language AND the library, as opposed to just knowing the language! The notion that libraries help other people come in to maintain later is a empty claim at best. From the mid 90's until I retired I made a career out of going in and cleaning up other people's messes -- and to be brutally frank whenever some 'brilliant' off the shelf library was involved, typically the code was an even harder to understand and more convoluted mess that similar applications built without such 'aids'; partly because the people who went for those tools never bothered learning enough programming to have been doing the job in the first place! A decade or so of my going into finish or take over other peoples work is the lions share of why I think libraries like jquery are idiotic rubbish that basically piss all over any website they are on!
... and that's BEFORE we talk about how it's typically not used for anything useful in terms of the end user experience and instead is for goofy animated crap and inaccessible garbage that ruins any chance of my wanting to visit such pages! So not only is it rubbish IMHO after almost three and a half decades of programming, it's also ruining websites for me as a user.
Well for one a support community. In the case of custom code and the original developers have moved on they could probably care less. Especially without compensation.
Second documentation. Perhaps some companies strive on documentation but in my experience it seems to be none existent for custom libraries or frameworks.
Well when a project or company marries themselves to some type of popular code base they can get developers whom specialize in it. Many of our sites run Drupal so in looking for people that is something that is considered when hiring people. Though I do tend to believe if you know the core language than any framework/library can be learned. Its just a matter of learning the patterns, consequences, function/method signatures and implicit/explicit ways of doing things best.
Drupal mark-up makes we want to cry at times so lets just avoid a conversation about Drupal. I was merely providing an example based on my current circumstance.
How is that any worst from someone developing their own custom reusable methods, patterns, etc which will naturally happen for larger projects. I mean… I'm not talking a simple static site here. I'm talking something on the level of facebook, amazon, vehix, etc. For mid to large projects that are highly dynamic web applications some form of framework will evolve naturally when things are being done properly. There will be patterns, utility functions, function libraries and work flow for achieving application concepts best. No different than what most frameworks or libraries provide just on a grander scale providing more functionality than you *might need. That seems to me like worthy trade off for having documentation, support community, maintained and solid code base.
In the age you're from, perhaps that was true. But technology is very different today, and performance research reveals that your claim is no longer true.
You're of course entitled to your opinion. Just be aware that the best and smartest in the business generally hold the polar opposite view. Reusing well written and widely tested code is almost always the best option.
Real programmers are about Replacing the wheel. Reinventing it? Nah... That's what people stuck in their own primitive artificial infinite loop do. They'll never manage to produce something of worth outside their own personal scope.
It was StevieD actually. Green mod, white fuzzy animal, easy to conflate :)[/ot]
Haha.. I can't even get it right when it's written in front of me. I didn't realise I associate avatars so closely to a persons username, or that I'd identify an avatar before a username. Interesting psychology, sure would make identity designer's proud.[/ot]
I agree completely.
In defense of Lea, I think she is more trying to encourage people to solve some of their own problems themselves and not become completely dependent on tools.
Encouraging people to roll their own frameworks is a good idea, she spends a lot of time herself making these types of tools for others to use.
The discussion reminds me a lot of http://fronteers.nl/congres/2009/sessions/roll-your-own-effects-framework
I find this thing at the bottom of her page to be a little ironic:
Proudly powered by WordPress
I mean... LOL
In regards to the partly used libraries.
This is not a story. It's a warning, for all you out there, thinking you got the world in your hands.
My story begins with innocence. It begins with simplicity and big ideals.
One day I thought it'd fun to build a simple text processor, with added bold and italics effects. It's the only things I'm needing, anyway. Thinking at this small level would probably mean less time spent to model the app, to think about implementation process, to plan the testing phases, to debug, to enhance performance, to improve maintainability...
A few days go by. I'm almost at a finish. One day, this girl, Epiphany, comes knocking on my door: she heard about my simple adorable project, but she wants font faces options too.
I mean, can I refuse her? And I'm thinking: OK, it's not that hard, I just have to write a plug-in for my little app, since I want things to be tidy, and this new feature is only to please Epiphany and her alone. And I do it, but after a while I feel like the innocence of my little project has little stains to it, now. It's not the little child anymore, it's looking somewhat strange.
But, you know girls, right? Epiphany just won't stop. She comes every week asking for more: font sizes, line heights, text alignment. Headings, tables, images. And the list starts growing bigger and bigger, and my "little" project starts scaring me codeless. It's not my little white dove anymore, it's a clumsy Frankenstein, getting out of hand. I never planned for that.
And one day, Epiphany stops knocking. She never calls. She's forgotten me. I feel lost and useless now, having worked to create a monster nobody wants anymore. I'm forced to live with it, like a remainder of when things only looked so easy to do, when I had no clue about the bigger picture, but I was so confident and happy.
After a while, one day, I happen to bump into Epiphany. I start being angry, looking at her being so happy. I'm now set to destroy her. And I demand an explanation. I force her into a dark corner, with the risk of being thrown in a cell, and I ask her "Why?"
And her answer fills me up with void. Her answer makes all the efforts I've done to please her look like roller coaster rejects. And it makes so much sense, it hurts. It's so logical, it cuts through my brains like L.A.S.E.R.
Here's what she said: "I've found another app for that. A better app, made by many brains that are used to work together, to profit form their experience, that don't rely on users telling them what they should do, but on other developer brains, and they're not scared about that. It gives me all the things I want in one package, and it doesn't make me come over every week and beg for more."
Figures. I thought I was one of a kind for Epiphany. I was so wrong. I wasted my life trying to prove my self to Epiphany.
For movie rights, you can contact me directly, I won't mind.
I don't understand your comment. So Tim Berners Lee who's used Drupal as his platform is, by your logic, hypocritical? Do you need to do everything yourself in order to justify a point? I also don't see her arguing in absolute terms, so I don't quite get where her use of WordPress weakens her point.
I'm with pro framework as well. I don't agree with "I'll make my own code since I'm only using one feature of the framework". Then it turns into "I'm using just ONE MORE feature so I'll code that too". How would this ever end when requirement is ever changing? Basically you can't! If it's a framework that's generally accepted by the public then I'd try to jump in when I have a need for it. Like someone said.. if you're NOT using any framework then you're not a programmer. That's my 2 cents.
How this ends is what you see now and it's how jQuery and co. came to life in the first place. They started small, requirements changed, and we have the result. Same goes for WordPress, Drupal, ExpressionEngine, TextPattern, Perch, and insertyour_CMS_or_Framework here. They all came about because a developer thought they could do something differently/better than what existed.
It's just... ironic. She's worried about performance, she's telling me this
I’m saying that you should consider writing your own code when the percentage of features you need from existing libraries is tiny (lets say less than 20%). It might not be worth carrying the extra 80% forever.
yet she "proudly" uses Wordpress.
She may be not talking absolutisms, but she's childish in her approach.
I chose to use JSON files to contain the phrases. I didn’t want the phrases to include HTML, since I didn’t want to have to escape certain symbols.
I mean, really, JSON could not be used to simulate a node element for <span>, at the very least, if she didn't want HTML tags straight into her JSON? Why is regex better? There's already a mechanism in place, escaping in JSON, but she felt like... what? There's no solid argument for going against that. At least, not to me.
Why she's using JSON for small data, is another performance thing altogether.
next page →