Re: [JSMentors] Today, Web Development Sucks
Hi Garrett. In 2007 I started reviewing YUI and moved on to prototype.js, Dojo, jQuery, Mootools, Ext-js, Sencha, and others. They all have different problems but the common problematic themes seem to be interdependency, being too general, making poor inferences and typechecking. So what do you do now? Rewrite everything from scratch? Learning javascript building quality code has little to do with making money. I was not talking about making money. I'm interested in learning how to build web applications without Javascript libraries (not being an incompetent, to use you terms :) ). Cheers, Guillaume. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Today, Web Development Sucks
2011/2/3 Guillaume Andrieu gh...@taleo-initiative.org: What should I recommend to new employees in my company when they have to learn Javascript, who have to start coding with Javascript without having had any proper formation ? Why do you have people that needs to start coding JavaScript without formation? That's the root of a lot of web develoment problems. If they doesn't known JavaScript fire them and hire someone who has JavaScript skills, or teach them *before* they start coding production code. If you want to teach JavaScript, don't use jQuery, use a good JavaScript book. In my opinion, any developer that needs a library for DOM traversal (or any other feature) should not write production code. When they can code almost everything using 'plain' JavaScript, then they can start using libraries. -- S.Cinos JavaScript Developer at Tuenti.com -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
[JSMentors] Re: Today, Web Development Sucks
On Feb 3, 6:39 pm, Guillaume Andrieu gh...@taleo-initiative.org wrote: Hi Rob. A consequence of using most general purpose libraries is that because they only support a small number of current browsers and don't tolerate new browsers very well (a consequence of their poor code quality and architecture), they not only disenfranchise perhaps 5 or 10% of web users who don't have a compliant browser, but also require constant upgrades and maintenance because of new or upgraded browsers. This is the antithesis of the web. I'm not sure I see the alternative. Well written, robust code that uses appropriate feature detection and fall back strategies is not difficult to write. Coding the thing yourself would lead to the same maintenance, probably even worse, each time a new browser (or browser bersion) appears which you had not targeted at first. How do you manage this better without using libraries ? Then you don't understand how to implement feature detection. No one is saying write every application from scratch, or that you shouldn't use any kind of library. Just don't use poorly written general libraries. If you design an application to just use basic, simple javascript then you don't need complex CSS selectors, chaining and so on. You just need a library of basic functions that does what you need and no more. And that can easily be written to be cross-browser with very little extra effort and maintained in your (or the corporate) repository. My favourite chuckle is over enterprises that deliver web applications that only run in one version of one browser (IE 6 being the the worst culprit). They end up with web applications that are more restrictive than the desktop applications they replaced - I'm sure more restrictive operating environment wasn't in the business case for changing to browser-based apps. I don't laugh at this. This is rational. No, it was completely irrational. I use a timesheet system every day that some idiot built so that it is based on ActiveX and IE 6. I've written more complex systems that can run perfectly in any browser since Navigator 4 without javascript. They are nicer with script, but don't need it. And by being able to not use script at all, fallback for missing features (pretty rare since they are based on very basic functions) is simple. One system has been running for nearly 8 years without a single modification. None. And works perfectly in every browser that accesses it. Most of the applications are written under time/cost constraints. When your initial requirements are to support only IE6, and you don't have time/money to invest in supporting other browsers, you take shortcuts. It doesn't cost any extra to write cross-browser applications. You may no test them in a wide variety of browsers, but if your library is developed to be cross browser to start with, and you understand the issues, your application should be cross browser anyway. It's not always (even rarely) the developper's decision, but under pressure you have to deliver something that meets the requirements and only the requirements. In my experience, the choice of browser is almost never a business decision, it's usually made by some IT manager backed up a business that doesn't know any better. You only need to ask them how they are going to deal with mobile devices to get them on the back foot. [...] If the time and effort spent learning a general purpose library is instead spent learning javascript, then far better outcomes can be achieved. Wait... Are we talking about people writing applications only within the boundaries of one library (people starting every line of JS code with a $) ? If yes, then I agree. Knowing the language is necessary. If not, which DOM traversal-only library do you suggest I use ? Any javascript programmer who needs a library to do DOM traversal should not be writing production code. It would take me 10 minutes to teach a programmer what they need to know to do it. What should I recommend to new employees in my company when they have to learn Javascript, who have to start coding with Javascript without having had any proper formation ? If you are in any kind of supervisory or management position then it is your responsibility to ensure that the people you are in charge of are competent to perform the tasks they are set. If they aren't, you either ensure they get appropriate training or get someone who has appropriate skills to do the job instead. -- Rob -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
[JSMentors] $('body') vs $(document) in Pub/Sub pattern
Hi guys,
I know this is more jQuery related question and perhaps it'd be better
to ask in its forum but I'll drop it in case some jQuery experts in this
group could answer it. Is there any reason why I should be using
$(document).bind/trigger over $('body').bind/trigger (or the other
way around) if I wanted to use it as a PubSub ? Any different in terms
of performance or others ?
Thanks
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] $('body') vs $(document) in Pub/Sub pattern
Den 03.02.2011 13:03, skrev Fran:
Hi guys,
I know this is more jQuery related question and perhaps it'd be better
to ask in its forum but I'll drop it in case some jQuery experts in
this group could answer it. Is there any reason why I should be using
$(document).bind/trigger over $('body').bind/trigger (or the other
way around) if I wanted to use it as a PubSub ? Any different in terms
of performance or others ?
Thanks
Hello,
maybe it's worth checking out this jQuery plugin for your pub/sub needs:
https://gist.github.com/661855
--
Mads Erik Forberg
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] $('body') vs $(document) in Pub/Sub pattern
That plugin is essentially the same thing as using $(body).trigger/bind,
has the overhead of going through the event system and is actually
larger by a few bytes* than my simplified version:
https://github.com/phiggins42/bloody-jquery-plugins/blob/master/pubsub.js
~phiggins
* or at least it was the last time ben and I compared them ...
On 2/3/11 7:12 AM, Mads Erik Forberg wrote:
Den 03.02.2011 13:03, skrev Fran:
Hi guys,
I know this is more jQuery related question and perhaps it'd be
better to ask in its forum but I'll drop it in case some jQuery
experts in this group could answer it. Is there any reason why I
should be using $(document).bind/trigger over
$('body').bind/trigger (or the other way around) if I wanted to use
it as a PubSub ? Any different in terms of performance or others ?
Thanks
Hello,
maybe it's worth checking out this jQuery plugin for your pub/sub
needs: https://gist.github.com/661855
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Today, Web Development Sucks
Well written, robust code that uses appropriate feature detection and fall back strategies is not difficult to write. That's why the web is full of that, right? If you write for yourself or an app for your hairdresser, yes. If you write in a company decisions are made by committee, not driven by tech excellence. Get out of your ivory tower and ride your unicorn down the town square and see some of the issues the commoners have to deal with. Then you don't understand how to implement feature detection. No one is saying write every application from scratch, or that you shouldn't use any kind of library. Just don't use poorly written general libraries. Some cheese with that whine? All the big libraries are open source and very much in use. If you really are that gifted and care about what people use on the web, file bugs and fix these oh so poorly written libraries. Right now, you come across as someone with a massive ego who is grumpy as people do not use his stuff or ask him to build bespoke code. It is too easy to say something is poorly written [citation needed] is what I say. If you design an application to just use basic, simple javascript then you don't need complex CSS selectors, chaining and so on. You just need a library of basic functions that does what you need and no more. And that can easily be written to be cross-browser with very little extra effort and maintained in your (or the corporate) repository. By whom? You expect that the people coming after you are as gifted and dedicated to the cause. Most of the big projects I built went into maintenance mode sooner or later. At least with libraries like YUI or jQuery they didn't mess around with the core code of the library. FYI: I don't like chaining and if you write massive CSS selectors you are doing it wrong. With your own solutions you will find document.write() hell added by maintainers sooner or later. Wake up and smell the corporate mandate: release this quick - maybe you get a chance to fix it later. I left my last role as a frontend architect as I've seen over and over again that you will not touch code that was shipped ever again unless you work on internal products. The web gets build by many people - a lot of them incompetent design agencies - if we can use a YUI or jQuery to at least deliver a basic support for all browsers instead of undocumented code magic then we are at least moving ahead. If not, which DOM traversal-only library do you suggest I use ? Any javascript programmer who needs a library to do DOM traversal should not be writing production code. It would take me 10 minutes to teach a programmer what they need to know to do it. The DOM is friggin broken and badly supported across browsers. Yes, that comes from the guy who wrote Beginning JavaScript with DOM Scripting and Ajax 5 years ago. If you really want to support browsers, then a library that polyfills the browser differences for you makes a lot of sense. Check out John Resig's The DOM is a mess: http://ejohn.org/blog/the-dom-is-a-mess/ And don't get me started on Events. If you don't simulate them you can never do proper event delegation with keyboard access for example. Of course you can teach DOM in 10 minutes. The issue is that applying DOM properly needs 3 years of experience on how browsers fail to understand it. And personally I'd rather concentrate on building sensible interfaces for end users rather than patching 10 year old code. What should I recommend to new employees in my company when they have to learn Javascript, who have to start coding with Javascript without having had any proper formation ? If you are in any kind of supervisory or management position then it is your responsibility to ensure that the people you are in charge of are competent to perform the tasks they are set. If they aren't, you either ensure they get appropriate training or get someone who has appropriate skills to do the job instead. Big topic here. I told my last company I leave my job when the first backend developer writes JavaScript as engineer is engineer - and I did. There is no good corporate JS training (oh wait, isn't that why we did this list?). What I normally tell people to do is to train their folk up to understand JavaScript how it is implemented. Go through the http://www.opera.com/company/education/curriculum/ and check out Crockford on JavaScript: http://yuiblog.com/crockford/ Then use a library SENSIBLY to allow you to concentrate on building things for end users. Great talk on this: http://lanyrd.com/2011/lwsmix/scckp/ Chris -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] $('body') vs $(document) in Pub/Sub pattern
it would only really matter if you were triggering dom events. Also, the
point about it going the event system and bubbling and whatnot still is
valid.
~phiggins
On 2/3/11 7:38 AM, Fran wrote:
I like this really tiny but clever plugin. I'll definitely keep it in
mine, but still I have the question whether using $(document) or
$('body') makes any different. Any idea ?
Thanks
On 03/02/11 12:12, Mads Erik Forberg wrote:
Den 03.02.2011 13:03, skrev Fran:
Hi guys,
I know this is more jQuery related question and perhaps it'd be
better to ask in its forum but I'll drop it in case some jQuery
experts in this group could answer it. Is there any reason why I
should be using $(document).bind/trigger over
$('body').bind/trigger (or the other way around) if I wanted to
use it as a PubSub ? Any different in terms of performance or others ?
Thanks
Hello,
maybe it's worth checking out this jQuery plugin for your pub/sub
needs: https://gist.github.com/661855
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] localStorage - special setter and getter
Juriy Zaytsev :
But is it a bug really? As far as I know, web storage spec (
http://dev.w3.org/html5/webstorage/) makes no clarification on whether
interface members are writable; or enumerable/configurable for that matter.
WebIDL spec, however, does mention something about interface members having
attributes { [[Writable]]: true, [[Configurable]]: false, [[Enumerable]]:
false } (http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces).
Thanks for the links and the info.
So it seems like writability of localStorage's getItem, setItem, clear, etc.
is actually in accordance to spec... which is probably not that great, since
it only makes for a more fragile implementation. The opposite argument could
be that [[writable]]: false would disallow useful cases of overwriting
localStorage methods, whatever those cases might be.
The problem is that they are not actually localStorage's methods. They
are inherited trough the prototype chain from `Storage' interface.
localStorage.setItem('foo', 'bar');
localStorage.getItem = null;
localStorage.getItem('foo'); //TypeError
localStorage.__proto__.getItem.call(localStorage, 'foo'); //bar
The setter in this case shadows `getItem' in the prototype chain and
here IMHO internal attributes wouldn't help a lot, while
`localStorage' instance hasn't own property `getItem'.
I think they have to specified the setter and getter of Storage instances.
Another interesting part of `localStorage' are integer properties. For
example getter with integer is mimic of `localStorage.key(n)';
localStorage.setItem('foo', 'bar');
localStorage[0]; //returns foo
localStorage[21]; //throws an Error with message: Index or size is
negative or greater than the allowed amount
localStorage[-1];
This is about the getter, the more interesting part is. Could set an
item which key is integer digit?
localStorage.setItem('10', 'bar');
localStorage.hasOwnProperty('10'); //true
localStorage[10]; //Error try to get the 10th key instead of item with key 10
localStorage.getItem('10'); //bar
Another example using regular setter instead of `setItem':
localStorage[666] = 'bar'; //There is not any errors here
localStorage.getItem(666); //bar
localStorage[666]; //Error
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] $('body') vs $(document) in Pub/Sub pattern
2011/2/3 Fran m...@fran.ie:
I like this really tiny but clever plugin. I'll definitely keep it in mine,
but still I have the question whether using $(document) or $('body') makes
any different. Any idea ?
There is one small difference. The $(document) selector is a bit
faster. I dont think that there would be other difference.
--
Poetro
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] $('body') vs $(document) in Pub/Sub pattern
On 2/3/11 9:12 AM, Poetro wrote:
2011/2/3 Franm...@fran.ie:
I like this really tiny but clever plugin. I'll definitely keep it in mine,
but still I have the question whether using $(document) or $('body') makes
any different. Any idea ?
There is one small difference. The $(document) selector is a bit
faster. I dont think that there would be other difference.
right and then the question is: why would you even be running a dom
selector/instantiating a jq obj for something that has little-to-nothing
to do with the DOM. The point of pubsub is that it's _not_ coupled to
anything.
~phiggins
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
RE: [JSMentors] $('body') vs $(document) in Pub/Sub pattern
1. Body will bubble up through HTML to document. document doesn't have any
place to bubble.
2. You don't have to use the dom when doing jQuery custom events.
$(document).trigger works the same way as $(myNS).trigger where myNS is your
global namespaced object
This probably makes more sense to your app than bouncing events off the dom
anyway.
-Original Message-
From: jsmentors@googlegroups.com [mailto:jsmentors@googlegroups.com] On Behalf
Of Fran
Sent: Thursday, February 03, 2011 10:07 AM
To: jsmentors@googlegroups.com
Subject: Re: [JSMentors] $('body') vs $(document) in Pub/Sub pattern
Because I'd also like to use namespaced events and I think jQuery has this
cleverly implemented
On 03/02/11 15:00, Peter Higgins wrote:
On 2/3/11 9:12 AM, Poetro wrote:
2011/2/3 Franm...@fran.ie:
I like this really tiny but clever plugin. I'll definitely keep it
in mine, but still I have the question whether using $(document) or
$('body') makes any different. Any idea ?
There is one small difference. The $(document) selector is a bit
faster. I dont think that there would be other difference.
right and then the question is: why would you even be running a dom
selector/instantiating a jq obj for something that has
little-to-nothing to do with the DOM. The point of pubsub is that it's
_not_ coupled to anything.
~phiggins
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
[JSMentors] Re: Today, Web Development Sucks
On Feb 3, 6:38 am, Chris Heilmann code...@gmail.com wrote: Well written, robust code that uses appropriate feature detection and fall back strategies is not difficult to write. That's why the web is full of that, right? If you write for yourself or an app for your hairdresser, yes. If you write in a company decisions are made by committee, not driven by tech excellence. Get out of your ivory tower and ride your unicorn down the town square and see some of the issues the commoners have to deal with. It is the perpetuation of these problems that guarantee they remain a problem.. Then you don't understand how to implement feature detection. No one is saying write every application from scratch, or that you shouldn't use any kind of library. Just don't use poorly written general libraries. Some cheese with that whine? All the big libraries are open source and very much in use. If you really are that gifted and care about what people use on the web, file bugs and fix these oh so poorly written libraries. I see comments like this often, but this is easier said than done and I don't mean because of some technical difficulty but rather due to politics of each major library's community. You can check CLJS for many instances of this. Right now, you come across as someone with a massive ego who is grumpy as people do not use his stuff or ask him to build bespoke code. It is too easy to say something is poorly written [citation needed] is what I say. Repetition is tiresome. If you design an application to just use basic, simple javascript then you don't need complex CSS selectors, chaining and so on. You just need a library of basic functions that does what you need and no more. And that can easily be written to be cross-browser with very little extra effort and maintained in your (or the corporate) repository. By whom? You expect that the people coming after you are as gifted and dedicated to the cause. So you'd rather not write decent code because whoever follows you won't? Most of the big projects I built went into maintenance mode sooner or later. At least with libraries like YUI or jQuery they didn't mess around with the core code of the library. I guess the word YUI or jQuery is an appropriate synonym for warning: keep out or you might break the duct tape... FYI: I don't like chaining and if you write massive CSS selectors you are doing it wrong. With your own solutions you will find document.write() hell added by maintainers sooner or later. Wake up and smell the corporate mandate: release this quick - maybe you get a chance to fix it later. If a maintainer uses document.write they probably shouldn't have been hired in the first place. I left my last role as a frontend architect as I've seen over and over again that you will not touch code that was shipped ever again unless you work on internal products. The web gets build by many people - a lot of them incompetent design agencies - if we can use a YUI or jQuery to at least deliver a basic support for all browsers instead of undocumented code magic then we are at least moving ahead The basic support bit is in question. If either the [insert label] general library or the code magic break you're probably in the same boat either way. . If not, which DOM traversal-only library do you suggest I use ? Any javascript programmer who needs a library to do DOM traversal should not be writing production code. It would take me 10 minutes to teach a programmer what they need to know to do it. The DOM is friggin broken and badly supported across browsers. Yes Yes, that comes from the guy who wrote Beginning JavaScript with DOM Scripting and Ajax 5 years ago. An argument from authority is a logical fallacy. If you really want to support browsers, then a library that polyfills the browser differences for you makes a lot of sense. Check out John Resig's The DOM is a mess:http://ejohn.org/blog/the-dom-is-a-mess/ I think RobG's point is that you should focus on code that polyfills RELEVANT differences instead of possibly all possible differences. And don't get me started on Events. If you don't simulate them you can never do proper event delegation with keyboard access for example. Of course you can teach DOM in 10 minutes. The issue is that applying DOM properly needs 3 years of experience on how browsers fail to understand it. So put that on the job requirements posting. And personally I'd rather concentrate on building sensible interfaces for end users rather than patching 10 year old code. If the code has worked for 10 years up til now, that deserves commendation. I sure wouldn't mind patching someone else's code once every 10 years... -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/
Re: [JSMentors] $('body') vs $(document) in Pub/Sub pattern
Hi Joel,
I didn't thought about the first point, thanks for that. About the
second one, I thought about it but found that I could get intro trouble
with certain versions of jQuery if I tried to unbind events since jQuery
seems to try to call detachEvent or removeEventListener (depending
on the browser) assuming always the object is a DOM element and that's
the reason I wanted to use $(document) or $('body')
I'm not really interested in bouncing events off the dom as you say, so
I'll probably go for something like this jquery plugin someone suggested
in the list: https://gist.github.com/661855
Thanks.
On 03/02/11 15:35, Joel Dart wrote:
1. Body will bubble up through HTML to document. document doesn't have any
place to bubble.
2. You don't have to use the dom when doing jQuery custom events.
$(document).trigger works the same way as $(myNS).trigger where myNS is your
global namespaced object
This probably makes more sense to your app than bouncing events off the dom
anyway.
-Original Message-
From: jsmentors@googlegroups.com [mailto:jsmentors@googlegroups.com] On Behalf
Of Fran
Sent: Thursday, February 03, 2011 10:07 AM
To: jsmentors@googlegroups.com
Subject: Re: [JSMentors] $('body') vs $(document) in Pub/Sub pattern
Because I'd also like to use namespaced events and I think jQuery has this
cleverly implemented
On 03/02/11 15:00, Peter Higgins wrote:
On 2/3/11 9:12 AM, Poetro wrote:
2011/2/3 Franm...@fran.ie:
I like this really tiny but clever plugin. I'll definitely keep it
in mine, but still I have the question whether using $(document) or
$('body') makes any different. Any idea ?
There is one small difference. The $(document) selector is a bit
faster. I dont think that there would be other difference.
right and then the question is: why would you even be running a dom
selector/instantiating a jq obj for something that has
little-to-nothing to do with the DOM. The point of pubsub is that it's
_not_ coupled to anything.
~phiggins
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Today, Web Development Sucks
Some cheese with that whine? All the big libraries are open source and very much in use. If you really are that gifted and care about what people use on the web, file bugs and fix these oh so poorly written libraries. I see comments like this often, but this is easier said than done and I don't mean because of some technical difficulty but rather due to politics of each major library's community. You can check CLJS for many instances of this. How exactly is filing bugs and fixing things you obviously see are wrong hard to do? My point is that ranting about something without bringing up WHAT really is broken is just noise. And appears arrogant. I know the solution and can do better, but I won't tell you. Right now, you come across as someone with a massive ego who is grumpy as people do not use his stuff or ask him to build bespoke code. It is too easy to say something is poorly written [citation needed] is what I say. Repetition is tiresome. Then point to resources where it has been proven or listed. This is the internet - things can be linked. If you design an application to just use basic, simple javascript then you don't need complex CSS selectors, chaining and so on. You just need a library of basic functions that does what you need and no more. And that can easily be written to be cross-browser with very little extra effort and maintained in your (or the corporate) repository. By whom? You expect that the people coming after you are as gifted and dedicated to the cause. So you'd rather not write decent code because whoever follows you won't? No, but I'd rather write code using a library that serialises browser support for me and is documented than write my own stuff and not document it. A library is not only code, a library is also support, maintenance and documentation. Most of the big projects I built went into maintenance mode sooner or later. At least with libraries like YUI or jQuery they didn't mess around with the core code of the library. I guess the word YUI or jQuery is an appropriate synonym for warning: keep out or you might break the duct tape... Erm, YUI is the library the Yahoo front page is built with - the largest web site on the web. If you build something bigger, that works for a more diverse market and across more locales then you can claim other things are built poorly. Judging libraries by designers using 12 different widgets on one page to achieve a certain look and feel is not giving them the respect they deserve. FYI: I don't like chaining and if you write massive CSS selectors you are doing it wrong. With your own solutions you will find document.write() hell added by maintainers sooner or later. Wake up and smell the corporate mandate: release this quick - maybe you get a chance to fix it later. If a maintainer uses document.write they probably shouldn't have been hired in the first place. And how exactly are we the ones hiring the maintainers? Of course they shouldn't be hired, but they are cheap and this is what counts high above. That's why it is important to build on something that is proven and documented rather than our own awesome.library that polyfills the browser differences for you makes a lot of sense. Check out John Resig's The DOM is a mess:http://ejohn.org/blog/the-dom-is-a-mess/ I think RobG's point is that you should focus on code that polyfills RELEVANT differences instead of possibly all possible differences. That is why YUI is modular, I agree that the kitchen sink approach of some libraries is annoying. The same applies to HTML5 polyfills. If you add 12 scripts and 3 different styles just to make IE6 behave then something is wrong. And don't get me started on Events. If you don't simulate them you can never do proper event delegation with keyboard access for example. Of course you can teach DOM in 10 minutes. The issue is that applying DOM properly needs 3 years of experience on how browsers fail to understand it. So put that on the job requirements posting. Again, have you ever hired people? What tech people put in job requirements is not what is going live in a lot of cases. http://www.readwriteweb.com/start/2011/01/the-valley-lacks-flexibility-not-talent.php And personally I'd rather concentrate on building sensible interfaces for end users rather than patching 10 year old code. If the code has worked for 10 years up til now, that deserves commendation. I sure wouldn't mind patching someone else's code once every 10 years... With that I meant Internet Explorer 6 - if I have to write all my code around the crap this browser needs then we will never build nice interfaces. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to
Re: [JSMentors] Today, Web Development Sucks
On 2/3/11, Guillaume Andrieu gh...@taleo-initiative.org wrote: Hi Garrett. In 2007 I started reviewing YUI and moved on to prototype.js, Dojo, jQuery, Mootools, Ext-js, Sencha, and others. They all have different problems but the common problematic themes seem to be interdependency, being too general, making poor inferences and typechecking. So what do you do now? Now I am looking for a competent sports med doc in San Francisco. Someone who has expertise with knees and who can work with my insurance. I participate in individual sports and martial arts and seem to have torn my ACL and damaged my meniscus and probably more. No MRI yet. The first doctor I saw (Dr. Chase of San Francisco General Hospital, Urgent Care) said I was fine. Rewrite everything from scratch? Building packages or modules of functionality is a fine idea but don't recreate The Thing where everything depends on that thing. Learning javascript building quality code has little to do with making money. I was not talking about making money. I know. Programming is not a very rewarding endeavor, so money tends to be a big motivator in learning it. I'm interested in learning how to build web applications without Javascript libraries (not being an incompetent, to use you terms :) ). Creating and organizing abstractions well takes a lot of trial and error. Do not create a set of abstractions that have not gotten real need; make sure you really need them first. Do not be too general, especially with cross browser DOM adapters and keep the parts independent enough so that you can swap out one interface object with another, but only as needed. Garrett -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] localStorage - special setter and getter
On Thu, Feb 3, 2011 at 8:09 AM, Asen Bozhilov asen.bozhi...@gmail.comwrote:
Juriy Zaytsev :
But is it a bug really? As far as I know, web storage spec (
http://dev.w3.org/html5/webstorage/) makes no clarification on whether
interface members are writable; or enumerable/configurable for that
matter.
WebIDL spec, however, does mention something about interface members
having
attributes { [[Writable]]: true, [[Configurable]]: false, [[Enumerable]]:
false } (http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces).
Thanks for the links and the info.
So it seems like writability of localStorage's getItem, setItem, clear,
etc.
is actually in accordance to spec... which is probably not that great,
since
it only makes for a more fragile implementation. The opposite argument
could
be that [[writable]]: false would disallow useful cases of overwriting
localStorage methods, whatever those cases might be.
The problem is that they are not actually localStorage's methods. They
are inherited trough the prototype chain from `Storage' interface.
localStorage.setItem('foo', 'bar');
localStorage.getItem = null;
localStorage.getItem('foo'); //TypeError
localStorage.__proto__.getItem.call(localStorage, 'foo'); //bar
The setter in this case shadows `getItem' in the prototype chain and
here IMHO internal attributes wouldn't help a lot, while
`localStorage' instance hasn't own property `getItem'.
I think they have to specified the setter and getter of Storage instances.
So `setItem` sets keys on an object, shadowing interface members defined on
the [[Prototype]]... Providing getItem/setItem shortcuts in terms of ES
property access/assignment is always problematic, since objects are likely
to inherit from `Object` (or other interfaces) and so can't be used as
reliable hash tables.
It's the same shoot-in-the-foot-convenience, as providing access to elements
via their id/name off of document (like IE did back in the days, and the
rest followed the suit, if I recall correctly). Ditto for form controls
exposed through the form.
Another interesting part of `localStorage' are integer properties. For
example getter with integer is mimic of `localStorage.key(n)';
localStorage.setItem('foo', 'bar');
localStorage[0]; //returns foo
localStorage[21]; //throws an Error with message: Index or size is
negative or greater than the allowed amount
localStorage[-1];
This is about the getter, the more interesting part is. Could set an
item which key is integer digit?
localStorage.setItem('10', 'bar');
localStorage.hasOwnProperty('10'); //true
localStorage[10]; //Error try to get the 10th key instead of item with key
10
localStorage.getItem('10'); //bar
Another example using regular setter instead of `setItem':
localStorage[666] = 'bar'; //There is not any errors here
localStorage.getItem(666); //bar
localStorage[666]; //Error
I didn't know numeric keys have special behavior. Is this part of the spec?
That's one lovely interface...
[...]
--
kangax
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Today, Web Development Sucks
On Thu, Feb 3, 2011 at 9:35 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: And I've filed well over a dozen bugs on YUI. I've submitted patches and even forked YUI so that I could help with that (my Github username is GarrettS) YUI bugs didn't get fixed. I've gone into more detail about that on this very list. Which bugs have you filed? I'll happily review them if you feel they haven't gotten appropriate attention. I only see two tickets from you in the system, both enhancements. I could be searching for the wrong usernames, though. http://yuilibrary.com/projects/yui2/ticket/2528514 http://yuilibrary.com/projects/yui2/ticket/2528872 Your GitHub account contains a (very broken) fork of YUI 2 with only three commits: two are enhancements, and the third is apparently every other file in the entire source tree. https://github.com/GarrettS/yui2/commits/master - Ryan -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Today, Web Development Sucks
On 2/3/11, Ryan Grove r...@wonko.com wrote: On Thu, Feb 3, 2011 at 9:35 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: And I've filed well over a dozen bugs on YUI. I've submitted patches and even forked YUI so that I could help with that (my Github username is GarrettS) YUI bugs didn't get fixed. I've gone into more detail about that on this very list. Which bugs have you filed? I'll happily review them if you feel they haven't gotten appropriate attention. I only see two tickets from you in the system, both enhancements. I could be searching for the wrong usernames, though. I filed from 2007 when YUI was on Source Forge. I filed a lot of them as anon for some reason. Here are a few YUI Test bugs that I have record of: http://yuilibrary.com/projects/yui2/ticket/1889970 (dunno if it was fixed but IIRC it was open for a long time so I patched my own copy). http://yuilibrary.com/projects/yui2/ticket/1922892 Patched that myself too. NEver figured this one out: http://yuilibrary.com/projects/yui2/ticket/1923420 - but IIRC the issue was resolved in a later version of Opera. The code I was testing would work normally, just not with synth events. `waitForCondition` was not implemented but instead marked FUTURE and then WONTFIX. It's a pretty useful feature so I patched it into the copy of YUI that I was using (not the one on GitHub) and I also added it to my own unit testing framework. http://yuilibrary.com/projects/yui2/ticket/2528872 One of the first bugs I found in YUI Test, where I found that calling resume twice, would cause errors. It was filed either late 2007 or early 2008, using the sourceforge tracker (which they stopped using over a year ago). Sure it was a dumb thing for me to do, more of a user error and not mission critical to YUI Test. But anyway, here it is: http://yuilibrary.com/projects/yui2/ticket/1884010 The logic for patching that was in a long method, buried in several layers of try/catch and if/else. And this: http://yuilibrary.com/projects/yui2/ticket/1924108 hidden iframe causes focus() to throw errors http://yuilibrary.com/projects/yui2/ticket/2528514 http://yuilibrary.com/projects/yui2/ticket/2528872 Your GitHub account contains a (very broken) fork of YUI 2 with only three commits: two are enhancements, and the third is apparently every other file in the entire source tree. I only used YUI Test and I only recall testing and patching those parts. I really don't know about the very broken parts of YUI. -- Garrett -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Today, Web Development Sucks
On Thu, Feb 3, 2011 at 7:45 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: http://yuilibrary.com/projects/yui2/ticket/1922892 Patched that myself too. I can't speak for anyone else, but the insulting tone you used in the comment on this ticket can't have helped your chances of convincing anyone that it shouldn't have been closed. `waitForCondition` was not implemented but instead marked FUTURE and then WONTFIX. It's a pretty useful feature so I patched it into the copy of YUI that I was using (not the one on GitHub) and I also added it to my own unit testing framework. http://yuilibrary.com/projects/yui2/ticket/2528872 Looks like it was recently moved to the new ticket queue for the standalone version of YUI Test, so the old ticket was closed. The new ticket is still open and targeted for a future release: http://yuilibrary.com/projects/yuitest/ticket/6 Out of the other tickets you linked, I don't see anything that I'd consider a significant or blocking issue. I can sympathize with being unhappy when tickets you've filed aren't resolved to your satisfaction, but when you told Chris you had filed well over a dozen bugs on YUI, the implication seemed to be that they were more serious than these. I only used YUI Test and I only recall testing and patching those parts. I really don't know about the very broken parts of YUI. Earlier in this thread, you wrote I haven't found a library that I can say was even mediocre. I began using YUI in 2006, before reviewing it. We had a lot of bugs and many related to YUI that just took a lot of time to debug. If you've only used YUI Test, then were you only referring to YUI Test when you wrote that? - Ryan -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Today, Web Development Sucks
On 2/3/11, Ryan Grove r...@wonko.com wrote: On Thu, Feb 3, 2011 at 7:45 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: http://yuilibrary.com/projects/yui2/ticket/1922892 Patched that myself too. I can't speak for anyone else, but the insulting tone you used in the comment on this ticket can't have helped your chances of convincing anyone that it shouldn't have been closed. I don't agree. I think the bug should have been fixed. And I don't know what your problem is either. I am just trying to answer your question about which bugs I filed. I think I've probably filed more but now I'm not sure if I can say that without having to prove it. I don't feel like rooting my inbox The bug that needs priority NOW is my R. Knee. DUnno what's wrong w/o MRI but doctors are just as incompetent as any js developer, twice as arrogant, and even lazier. Wow! The first doctor, Dr Chase of SF General sent me home and said to rest for two days; that I'd be fine. A drunk on the street could tell me that for a quarter. Incompetence is rife and that is probably why we have lawyers in the US. Garrett -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Today, Web Development Sucks
On 2/3/11, Ryan Grove r...@wonko.com wrote: On Thu, Feb 3, 2011 at 7:45 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: http://yuilibrary.com/projects/yui2/ticket/1922892 Patched that myself too. I can't speak for anyone else, but the insulting tone you used in the comment on this ticket can't have helped your chances of convincing anyone that it shouldn't have been closed. `waitForCondition` was not implemented but instead marked FUTURE and then WONTFIX. It's a pretty useful feature so I patched it into the copy of YUI that I was using (not the one on GitHub) and I also added it to my own unit testing framework. http://yuilibrary.com/projects/yui2/ticket/2528872 Looks like it was recently moved to the new ticket queue for the standalone version of YUI Test, so the old ticket was closed. The new ticket is still open and targeted for a future release: http://yuilibrary.com/projects/yuitest/ticket/6 Out of the other tickets you linked, I don't see anything that I'd consider a significant or blocking issue. I can sympathize with being unhappy when tickets you've filed aren't resolved to your satisfaction, but when you told Chris you had filed well over a dozen bugs on YUI, the implication seemed to be that they were more serious than these. The bugs like not setting pageX are not serious? COme on did you read the comments I wrote? That explains the importance. And what about calling focus() on the iframe throwing errors in IE? Of course it's totally unusable if you can't call focus() because it fails worngly. I forgot how but it either stopped the entire suite or it caused a false failure on the test. And why did I patch it? Jeez you act like I'm nitpicking and taking potshots. Grow up. I used YUI Test a lot it was the best test framework I could find at the time. Sure I gave Nickolas a lot of feedback in personal emails. I eventually got the drift that he didn't like me. Maybe you guys are firends or something, huh? I only used YUI Test and I only recall testing and patching those parts. I really don't know about the very broken parts of YUI. Earlier in this thread, you wrote I haven't found a library that I can say was even mediocre. I began using YUI in 2006, before reviewing it. We had a lot of bugs and many related to YUI that just took a lot of time to debug. If you've only used YUI Test, then were you only referring to YUI Test when you wrote that? YUI Test depends on YUI and I recall it was calling one of the methods of YUI like isDefined or something that was akin to the Goog.isDef function bad example in the code guidelines doc. Plus I used YUI when I was at Yahoo, just before I made the mistake of paying a visit to Trang's house and then whoops, oh no, got me fired :-(. A double disappointment (and I am not referring to the version of YUI I used). The manager of the team had chosen YUI in total ignorance and for the silliest rasosn (this is YAHOO, so we must use YUI). We had a ton of bugs in that code and the most disgusting of which came from our own team. Choosing YUI did not improve our code it a manager decision and he had no clue about FE Eng so not a well informed decision. That code was among the worst code I have worked on in my career. Often front end decisions come down to manager making a decision on which library to choose or which library user to hire; not about asking somebody to write a little widget and then reviewing that code and never about asking teh candidate to review a pieve of the company's code. -- Garrett -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
