Reinventing the wheel

[DaveMaxwell]

From a high level, I agree with the overall premise of the article - if you would only be using a miniscule fraction of the framework, then don't use it if you can get the same performance with a smaller footprint. It's better for your customer and better for their clients with better performance.

The problem with catch-all frameworks is their complexity, and often people can't find all the pieces without a ton of digging, which means they end up looking elsewhere and using ANOTHER framework (say jQuery + mooTools + the flavor of the month), or a plugin which has actually been replaced in the baseline code, but the documentation doesn't lend itself to knowing it's been replaced.

The other problem is layering - people put code on top of code on top of other code instead of refactoring constantly like they should always be doing. So you end up with 10 different ways to reach the same solution, then people add onto those 10 different ways, which adds a magnification problem on top of a simple solution...

I still have my old college professors mentality - keep it light and tight - when I approach ANY technology problem. The fewer layers I have to deal with, the easier it is to fix a problem when I go back to deal with it later. I've got a problem right now which is a pain in the maximus simply because there are too many files (at least 10) required to accomplish the same goal, and one of the biggest hurdles is the framework that was chosen wasn't flexible enough to handle anything other than straight table/database interaction.

Frameworks are great for what they're intended for, but they shouldn't be the be all and end all. They are tools to help you do the best job possible with the least amount of effort. HOWEVER - if you become solely dependent on them and can't do the simplest tasks without using them, then YOU'RE not a developer.

[sg707]

I guess I belong in the other end mentality. Whenever there is new project, I ALWAYS search for new weapons to play with (doesn't mean I pick a new one for every project). There are few rules on which I choose... for example, I never use anything less than 2.0 versions. Also, there are successful be all and end all frameworks. You can google "Spring Framework". This framework is so big and covers so much area that you can literally create any type of projects. In fact, this framework was sold to VMWare for cool half billion dollars! It is still free to use but they rake in the cash for training courses. It is no surprise that this framework is the #1 used Java frameworks.

With that said, I don't agree with "Keep it light and tight". I go with "Keep it smart by doing less". At the same time, it is foolish to pick a weapon you don't know how to use... YOU CAN CUT YOURSELF! It's like nunchuck used by bruce lee and myself..there is a vast difference how it's being used.

[Stevie D]

Whenever there is new project, I ALWAYS search for new weapons to play with (doesn't mean I pick a new one for every project).

I guess I just don't have that "oooh shiny" attitude. I decide what I want the website to do, then I figure out how to do it. It's very rare that I'll come across a new toy and then decide to add it to a site. It's a case of doing what I need/want to do, rather than showing off what I can do (or rather, what someone else can do).

[sg707]

I guess I just don't have that "oooh shiny" attitude. I decide what I want the website to do, then I figure out how to do it. It's very rare that I'll come across a new toy and then decide to add it to a site. It's a case of doing what I need/want to do, rather than showing off what I can do (or rather, what someone else can do).

I don't have "oooh shiny" attitude. Instead, I have "How can I make it better and faster for next project?" attitude

[itmitică]

There are two sides of the coin.

<hr>

N00bs would work and reinvent the wheel, it's just that they don't know how, so they turn to libraries instead

That's assuming libraries are targeted to n00bs, since they can't actually learn the language. Which is pretty much not true. If a library makes it easy for n00bs, it doesn't mean the library is for n00bs and n00bs only. Or that any n00b could easily pick the library up and hit the ground running.

The truth is that libraries are for reusable code, for DRY code. And, most importantly, for productivity. Those that worked on projects beyond a certain level will probably understand that better. Using libraries and then finding spots where they don't fit, or where a couple of lines of "vanilla" code are more suitable, really shows a flaw in the app design, which it's certainly not an occasion for a developer to gloat, duct-tapping the holes.

<hr>

Seasoned developers dismiss libraries and would work on how to reinvent the wheel because they know how to

That's assuming seasoned developers actually find it easier to learn how to use a library. Which is pretty much not true. A developer may find a particular library involves concepts it's not qualified for, so it does things the way it knows instead. It "reinvents the wheel" thus admitting its knowledge and skills have limits too.

The truth is that it should learn, it should fill in the gaps in its knowledge and then it should move forward, like the rest. Or it should provide a better alternative. Or, if none of the above, it should understand it doesn't *really* understand the topic.

[Sega]

I have my own perspective on this. We don't know everything and we certainly can't know everything, but apart from that something happens to make the world go round, and that something is money.

People won't pay for custom work like they used to. I find myself using libraries in order to reduce the price on things to accommodate what people can afford. For me the two most important aspects of a website are security and support, in my humble opinion.

I've now found myself reducing the price with ready-made templates and budget logo's. Even thought I can't produce an awesome logo, I'd like to think I can produce a pretty neat website. Having said this people won't pay for a tailor made website. They all want to reduce the price, and when I give them a second option of templates and ready-made library and plug-ins, they always choose the cheapest option. Do you see how it works?

How much would you need to make your own CMS? Even so, how good would you have to be in order to compare to some of the open source platforms out there.

I do use Theme Forrest and there are exceptions when the stuff from there is pretty amazing. I don't feel ready made jQuery is bad. I've seen some examples which are pretty shocking and unusable in most cases, however, jQuery is not bad, and considering we have to learn jQuery I would hate to imagine what learning javaScript would be like.

We should learn and evolve what we learn, so maybe I should learn javaScript.

[deathshadow60]

and considering we have to learn jQuery I would hate to imagine what learning javaScript would be like.

... and that right there says EVERYTHING that's wrong with the majority of people who use jQuery...

[Jeff Mott]

... and that right there says EVERYTHING that's wrong with the majority of people who use jQuery...

I do have to commend you for rightly criticizing the person who shows inexperience, rather than the library.

@Sega My apologies that you had to be singled out. Deathshadow and I are more generally talking about people who are still learning JavaScript. Nothing personal against you.

[kohoutek]

Those are very valid points.

What I don't understand is why you generally oppose to the idea of reinventing, or to put it differently, reformulating something when the scenario permits it or when you feel that the solutions which exist don't fill the bill or could exist in a trimmed-down, more apt version for a given task.

I understand that you find the example in the article above problematic. That's fair enough.

But ignoring the Markdown example, what I don't quite understand is why you would generally negate the idea of the article, the underlying, broader thesis behind it; that a work by someone can and should be taken apart, reformulated, or approached with a completely new methodology when you, as a developer, and with the tools (your skills) think you could come up with a better solution for a task without compromising reusability or efficiency.

I'm not in any way implying that existing applications are bad, nor am I against jQuery and the like, but I don't see how there can't be room or valid scenarios for using alternative concepts.

I'd have thought that the general philosophy behind this approach would be right down your alley, Mitica.

There are two sides of the coin.

<hr>

N00bs would work and reinvent the wheel, it's just that they don't know how, so they turn to libraries instead

That's assuming libraries are targeted to n00bs, since they can't actually learn the language. Which is pretty much not true. If a library makes it easy for n00bs, it doesn't mean the library is for n00bs and n00bs only. Or that any n00b could easily pick the library up and hit the ground running.

The truth is that libraries are for reusable code, for DRY code. And, most importantly, for productivity. Those that worked on projects beyond a certain level will probably understand that better. Using libraries and then finding spots where they don't fit, or where a couple of lines of "vanilla" code are more suitable, really shows a flaw in the app design, which it's certainly not an occasion for a developer to gloat, duct-tapping the holes.

<hr>

Seasoned developers dismiss libraries and would work on how to reinvent the wheel because they know how to

That's assuming seasoned developers actually find it easier to learn how to use a library. Which is pretty much not true. A developer may find a particular library involves concepts it's not qualified for, so it does things the way it knows instead. It "reinvents the wheel" thus admitting its knowledge and skills have limits too.

The truth is that it should learn, it should fill in the gaps in its knowledge and then it should move forward, like the rest. Or it should provide a better alternative. Or, if none of the above, it should understand it doesn't *really* understand the topic.

[sg707]

Seasoned developers dismiss libraries and would work on how to reinvent the wheel because they know how to

Am the only one who felt awe struck when I read this statement.. I can't be the only one...

[Sega]

@Jeff Mott ;
I will get learning jQuery, but I don't see a point learning JavaScript. We did it at university, but that was a long time ago when things were all pop-up and equations. We learned nothing we could use in actual practice, so I left it out in practice and no employer demanded it of requested further training. Nowadays people use jQuery and MooTools rather than writing javascript from scratch, which works for most.

... and that right there says EVERYTHING that's wrong with the majority of people who use jQuery...

Yep, you're right.

People seam to be doing without learning JavaScript, maybe we should open a thread which highlights the benefits of using JavaScript as oppose to libraries (excluding the learning is fun part). Once people see the benefit they are missing out on they would naturally attempt to learn something.

[itmitică]

What I don't understand is why you generally oppose to the idea of reinventing, or to put it differently, reformulating something when the scenario permits it or when you feel that the solutions which exist don't fill the bill or could exist in a trimmed-down, more apt version for a given task.

That should be an extremely rigid scenario for one to do that. It's like saying "For this particular project I'll never ever use arrays. I want a PHP version without arrays." That's Epiphany talking for you. You'll later pay heavily to the mother of all, Experience, to counsel you to never ever waste your time again and fall for that.

[...] why you would generally negate the idea of the article, the underlying, broader thesis behind it; that a work by someone can and should be taken apart, reformulated, or approached with a completely new methodology when you, as a developer, and with the tools (your skills) think you could come up with a better solution for a task without compromising reusability or efficiency.

Me standing behind jQuery is me appreciating "someone can and should be taken apart, reformulated, or approached with a completely new methodology when you, as a developer, and with the tools (your skills) think you could come up with a better solution for a task without compromising reusability or efficiency", don't you think?

I'm not in any way implying that existing applications are bad, nor am I against jQuery and the like, but I don't see how there can't be room or valid scenarios for using alternative concepts.

I like alternative concepts. I like jQuery over vanilla JavaScript, aren't I?

<hr>

The gist of it is that I stand behind one learning programming concepts and finding smart ways of making use of them rather than feeling accomplished by burring its nose down to the level that it won't see the forest because it's looking to closely at the trees. Reinventing the wheel to me is to forget about priding in overcoming petty problems for a certain implementation of a certain language but always look at the big picture of abstract, universally valid programming concepts.

[itmitică]

Seasoned developers dismiss libraries and would work on how to reinvent the wheel because they know how to

Am the only one who felt awe struck when I read this statement.. I can't be the only one...

For clarity. What I mean is that there are developers well versed in a language. Yet they may find a library way of working to be something so radically different that they just throw in the towel. Or maybe they just lack the knowledge it takes to get it. The fact is that they find it easy to just stick with what they already know and they try to reinvent the wheel. Meaning that they can't adapt to new concepts, they can only work and understand their own personal way. Usually, it ends up costing them.

[sg707]

For clarity. What I mean is that there are developers well versed in a language. Yet they may find a library way of working to be something so radically different that they just throw in the towel. Or maybe they just lack the knowledge it takes to get it. The fact is that they find it easy to just stick with what they already know and they try to reinvent the wheel. Meaning that they can't adapt to new concepts, they can only work and understand their own personal way. Usually, it ends up costing them.

Gotcha. I completely agree. Many talented programmer easily dismiss a open source framework because they don't understand. Most are too proud to admit that they don't understand.. so they come to "This framework sucks" and try to sucker you into agreeing to use old / custom codes.

[kohoutek]

That should be an extremely rigid scenario for one to do that. It's like saying "For this particular project I'll never ever use arrays. I want a PHP version without arrays." That's Epiphany talking for you. You'll later pay heavily to the mother of all, Experience, to counsel you to never ever waste your time again and fall for that.

That doesn't quite address anything I've said. Fact is, jQuery wouldn't have come to life if someone didn't reinvent the wheel and just used the Javascript frameworks that already existed, so we have to thank the developers of jQuery for not having followed your principles.

Same goes for PHP and other languages. They could have used what existed then, but they didn't extend it but instead created something new. Someone somewhere felt that new situations required new ways of thinking.

But I'm leaving this discussion alone now as I'm going in circles and simply differ in opinion.

[Stomme poes]

I'm kinda sorry I created this thread. But whatever.

That's assuming libraries are targeted to n00bs, since they can't actually learn the language. Which is pretty much not true. If a library makes it easy for n00bs, it doesn't mean the library is for n00bs and n00bs only. Or that any n00b could easily pick the library up and hit the ground running.

Whether or not it's written for and targeted at n00bs has little to do with it... I know plenty of people in the same boat as Sega, who (fairly easily and quickly) learn jQuery but don't know the basics of (vanilla) Javascript. Either because they haven't had the time to learn it while getting things done on the job, or because they don't see why they should bother (again, other than the learning is fun generality). This was the story of at least 80% of a Javascript class/meeting I had a while back (we were asked what our JS experience was before beginning).

I will get learning jQuery, but I don't see a point learning JavaScript.

Well, besides "just because/learning is fun", this might be one example: http://www.sitepoint.com/forums/showthread.php?808876 (specifically, oddz' post)
and stuff like this: http://www.doxdesk.com/updates/2009....0091116-jquery ...referring specifically to this sort of example:

Almost always, the 'best' way of finding out whether a checkbox is ticked is given with a straight face as:

$(input).is(':checked')

— as obviously input.checked just doesn't do enough selector-parsing busywork to be really modern.

On the one hand, this is an exaggeration. On the other hand, you do see code like this, and lots of it. After all, it does work, and you're not going to notice (as a developer or as a casual user) any actual performance issues with it. It's slower, but in a "people who do jsperf testing" kind of way.

And another note since some people seem to have missed it: Lea builds these very kinds of tools herself and uses them all the time. So claims that she's too busy being full of herself and trying to be a douchebaggy brogrammer yo are silly and mean. Also claims that because her personal blog is using WordPress, she can't possibly be allowed to care about performance for work she does for a client or on a project... not only is ad hominem but also another special form of... being very special. I am disappoint. ಠ_ಠ

And am I the only person who's noticed that the number of Javascript libraries available are now more than I can count on two hands in the last few years? I'm not? Hasn't it, like, tripled lately?? And the number of new CMSes... good lord. Then you must wonder, where are all the new libraries coming from? Oh, they're coming from people reinventing the wheel as Kohoutek said. Yet this is somehow a bad thing, yet you'll all jump on the latest library saying how awesome it is. This makes zero sense. People looking around existing tools to fix their own solutions created these tools, therefore this must be a good thing. You can't go on about "people shouldn't be wasting their time writing solutions to their particular problems instead of using what's already out there" and at the same time rave about how awesome the libraries/tools coming from these very same people are. That's such a sleazy double-standard. W. T. F.

If people didn't reinvent wheels, y'all wouldn't have your precious precious jQuery; you'd have Prototype.js and Dojo. If people didn't reinvent wheels, you wouldn't have your precious precious Prototype.js and Dojo; you'd have vanilla Javascript. You wouldn't have your precious precious SASS or LESS or any of the 500 grid systems floating around out there. You'd have vanilla CSS. You wouldn't have CoffeeScript. You'd have native language syntax.

Kohoutek already stated the above but she apparently wasn't snarky enough to get people's attention so it was time for me to step in and repeat it with some surly attitude and a bit of hate.

[kohoutek]

And am I the only person who's noticed that the number of Javascript libraries available are now more than I can count on two hands in the last few years? I'm not? Hasn't it, like, tripled lately?? And the number of new CMSes... good lord. Then you must wonder, where are all the new libraries coming from? Oh, they're coming from people reinventing the wheel as Kohoutek said. Yet this is somehow a bad thing, yet you'll all jump on the latest library saying how awesome it is. This makes zero sense. People looking around existing tools to fix their own solutions created these tools, therefore this must be a good thing. You can't go on about "people shouldn't be wasting their time writing solutions to their particular problems instead of using what's already out there" and at the same time rave about how awesome the libraries/tools coming from these very same people are. That's such a sleazy double-standard. W. T. F.

If people didn't reinvent wheels, y'all wouldn't have your precious precious jQuery; you'd have Prototype.js and Dojo. If people didn't reinvent wheels, you wouldn't have your precious precious Prototype.js and Dojo; you'd have vanilla Javascript. You wouldn't have your precious precious SASS or LESS or any of the 500 grid systems floating around out there. You'd have vanilla CSS. You wouldn't have CoffeeScript. You'd have native language syntax.

Kohoutek already stated the above but she apparently wasn't snarky enough to get people's attention so it was time for me to step in and repeat it with some surly attitude and a bit of hate.

Ja, oui, genau, it's what I've tried to imply in post #19 way back on page 1:

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 _insert_your_CMS_or_Framework here. They all came about because a developer thought they could do something differently/better than what existed.

But, so far, nobody seems to want to see or acknowledge the contradiction of arguments made in this thread. How you can invalidate Lea's thought process (work) and yet argue pro jQuery and its kin makes zero sense to me. The underlying principles are identical.

[Sega]

The people who re-invent the wheel do so in making money or gaining publicity. They do it because they feel people could benefit from their hard work, and in many cases people do benefit from it. I don't see the issue of using somebody else's creation.

I wrote something a while back and compared web design to carpenters. In the early days carpenters used to make everything by hand, from kitchens to doors. Now they find ready made products and piece them together so that the customer can afford those cheap products. A hand made solid wood kitchen here costs roughly 7K upwards and those were the days when ready made kitchens were not common. Now with ready-made kitchens from places like IKEA people opt out of a tailor-made solutions and prefer the cheap and cheerful stuff as they are more than half the price.

You can't compare quality, tailor made wins every time, but money happens to talk and customers want cheap. As a result of this, people will loose the knowledge of making those hand crafted good and the ones who retain it would charge and arm and a leg. Do you see where this is going? Can you see the comparison with web design?

People are using templates, people are managing and creating websites without knowing all the ins and outs. Do you see where the future is going? Unfortunately it's not who knows most who wins, but who manages to create an affordable product for people, and if that means using things like templates, jQuery and MooTools, well this is what's going to be a winner in the end.

A famous Greek saying goes like this:

You can hang your art or expertise for everybody to see and admire

... but in the end, we can't live on admiration.

[markbrown4]

Off Topic:

I will get learning jQuery, but I don't see a point learning JavaScript. We did it at university, but that was a long time ago when things were all pop-up and equations. We learned nothing we could use in actual practice, so I left it out in practice and no employer demanded it of requested further training.

To state the obvious jQuery IS Javascript, so if you find jQuery useful then Javascript itself is useful.
I'm surprised that no employer demanded it - with HTML5, node, client-side templating, gaming platforms, backbone, coffeescript all gaining steady momentum. I'd say Javascript is absolutely essential for any web developer.

[itmitică]

I appreciate very much the reinvention of the wheel. As long as it's a better wheel, and you actually get to go forward and build something worthy with it, if not a car, at least a stupid little cart.

So, I have nothing against those that help me build cars. My only problem is with those like Lea Verou that just discovered to principle of circle. And her problem with the wheel is that she thinks that looping ad infinitum in a circle means advancement. It takes more than that. You actually have to choose a road and put that wheel on that road.

Examplification

Let's say you build a web site.

You build the CSS style for it. It's only logic you're gonna have a few different sections in it: a reset or a normalize, the base style, different media queries, a few specifics.

Following Lea Verou's lead from the article, you'd split and serve that CSS in a few files. Experience says this is not true, right? You're gaining more by actually serving it all in one file.

Now, using a thing like SCSS means you actually get to eat the cake too. For one thing, you can keep your CSS in separate files at developing time (a huge step forward for cross project reusability), and get a single CSS file for production, with a single click.

As a side note, that's why I like where Light Table is going.

Doing less, getting more, remaining organized. Well, that's more like it.

What Lea Verou refers to as reinvention of the wheel is a completely different thing: writing less to get less, and regression, no use of any tools. She's not even considering a stupid little cart, she's just throwing a little fit against all libraries, against open source even, because she's too lazy to actually think one simple thing the whole way through.

I'm not sorry if it feels a little harsh, but I am sorry some took it personally.

<hr>

Finally, you want to see how much the wrong reinvention of the wheel costs us? Take a look at UAs and their war. Take a look at W3C and WHATWG and their war. I don't see more good than bad coming out of it. That's why I'm against reinventing the wheel just for the sake of it. A new wheel is a better wheel? Not always. That's Lea Verou omits to tell us.

[DaveMaxwell]

What Lea Verou refers to as reinvention of the wheel is a completely different thing: writing less to get less and regression, no use of any tools. She's not even considering a stupid little cart, she's just throwing a little fit against all libraries, because she's too lazy to actually think one simple thing the whole way through.

I guess I took that article from a whole other perspective - I took it as her saying that you should really look at what you're actually doing and see if you need these gargantuan js libraries and see if you can't find/create a solution which is lighter and does just what you need it to do.

And I'm sorry, but jQuery is a beast if you don't get one of the stripped down versions - which most people don't. Or they'll do a quick google search for a piece of functionality and use that rather than looking at what they already to see if they can leverage that. So you end up with jQuery AND mooTools AND .....

A good example is a project I'm working on now - our client built a prototype design with a horizontal menu which had a horizontal sub-menu. They built their menu using jQuery (and not the version already being used within the framework we're building their site with), and it was completely unecessary - I was able to recreate it using straight CSS which was cross browser and clean, and the extra bloat from the unneeded scripting (and extra css class cruft) was gone. It took them weeks to realize the menu wasn't the same, and weren't happy when they realized I changed it, but in the end we have less work because I didn't have to revamp it everytime they changes a menu item.

[itmitică]

I don't know how the menu was built, so I can't comment on that, but I'm not sure yours is an example to inspire, Dave.

You're saying you've gone against the client's plans, and without him knowing you decided on your own what's best. This shows failure to comply and integrate from your part, with disregard but for your own concerns.

I'm sure that if you've managed to make a good case that yours is better, things would've been better both for you and for your client.

<hr>

About jQuery being a beast. This issue has been discussed over and over. jQuery has a powerful CDN. jQuery actually goes out of its way to help developers and users too. So developers alone are to make that or break that. Like it is the case with the wheel reinvention.

[Stomme poes]

Off Topic:

You're saying you've gone against the client's plans, and without him knowing you decided on your own what's best. This shows failure to comply and integrate from your part, with disregard but for your own concerns.

Companies don't like it when you sneak accessibility into their sites too. Doesn't keep me up at night. :) I suppose Dave could have just overcharged them to do the unnecessary extra work of constantly reworking their broken bloated menu when they upgraded every time, but that seems less fair (to the client).

Then again, you'd think the client-developer relationship wouldn't be so poor that they had to discover their changed menu on their own, and then wonder "what other things has he pulled out from under us that we don't know about?"

[DaveMaxwell]

You're saying you've gone against the client's plans, and without him knowing you decided on your own what's best. This shows failure to comply and integrate from your part, with disregard but for your own concerns.

Nothing that arrogant or self-serving, I assure you. In this case, the prototype they had built did not fit into layout in the pdf design mockup they had provided. Not even close - over 25% too wide. The revamp was done to allow it to fit into the design mockup they had provided as it was just less work since the prototype version provided included different hard coded lengths for each top level menu item, which didn't allow for any type of menu changes or expansions.

[DaveMaxwell]

Off Topic:


Then again, you'd think the client-developer relationship wouldn't be so poor that they had to discover their changed menu on their own, and then wonder "what other things has he pulled out from under us that we don't know about?"

Again, nothing so devious. It was done early on in the templating process as I was converting the pdf over to html. I was working top-down and the menu was the 3rd or 4th thing done, so by the time I was done, I had forgotten all about it. I was just thankful I did it when they changed the menu items since the widths weren't hard coded anymore and it was just a matter of changing the text and not having to change the widths of each and every menu item.