Re: [JSMentors] Re: Today, Web Development Sucks

[Garrett Smith]

On 2/3/11, Ryan Grove  wrote:
> On Thu, Feb 3, 2011 at 7:45 PM, Garrett Smith 
> 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

Re: [JSMentors] Re: Today, Web Development Sucks

[Garrett Smith]

On 2/3/11, Ryan Grove  wrote:
> On Thu, Feb 3, 2011 at 7:45 PM, Garrett Smith 
> 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

[Ryan Grove]

On Thu, Feb 3, 2011 at 7:45 PM, Garrett Smith  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

[Garrett Smith]

On 2/3/11, Ryan Grove  wrote:
> On Thu, Feb 3, 2011 at 9:35 AM, Garrett Smith 
> 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:


The logic for patching that was in a long method, buried in several
layers of try/catch and if/else.

And this:

"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

[Ryan Grove]

On Thu, Feb 3, 2011 at 9:35 AM, Garrett Smith  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

[Garrett Smith]

On 2/3/11, Chris Heilmann  wrote:
>
>>> 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".
>
Who are you quoting?

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.

[...]

> 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.
>
Sure, sounds great. And the code should be efficient with no
extraneous cruft. But then it won't fulfill every scenario.

However, the ones "in the trenches" are more closely connected to the
problem, and (ideally but not always) to the problem space. If the
guys working on building the app need an abstraction to handle a bit
of functionality (and for anything having even a modest degree of
sophistication, they will) then they should write and organize it into
their codebase. That is essentially the idea behind writing an
abstraction. Factors that come into play with that are reusability and
encapsulating the parts that vary. I've seen reusability go either way
-- either something is not reusable at all or it has had code added to
accommodate cases for which it most surely will never be tested.

>
>>> 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.

I covered this earlier this week.

One is not required to build a bigger outhouse to claim Yahoo
frontpage stinks. See validator.w3.org and read up on how invalid HTML
isn't standardized.

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.
>

I didn't understand the part about libraries by designers. I think
that I probably did not interpret that sentence as what you meant.

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

Perhaps corporations are too short sighted to see the costs of
building maintenance nightmares.

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

Sorry I missed to see how that question is relevant. I'm not saying yo
don't have a point but pro

Re: [JSMentors] Re: Today, Web Development Sucks

[Chris Heilmann]

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
jsmentors+unsubscr

Re: [JSMentors] Re: Today, Web Development Sucks

[Chris Heilmann]

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] Re: Today, Web Development Sucks

[Guillaume Andrieu]

On 3 February 2011 10:06, Sergio Cinos  wrote:

>
> 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.
>

Hi Sergio.

I don't want to. It just happens.
I'm not responsible for hiring at my company.
Besides, skilled Javascript developers are scarce where I am, they would
have a very hard time finding someone who can write DOM traversal with the
DOM API only, and I can understand that. I don't see the point at all of
learning how to use the horrible W3C DOM API.
Knowing how to traverse a tree is enough, in my opinion, whatever the API.
This is not a Javascript issue. This is a DOM API issue. I wouldn't write
DOM traversal with the DOM API, I would write a DOM traversal library. A lot
of them already exist.

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.
>

DOM traversal is not "plain" Javascript. It's "plain" W3C API.
For other features, like animations or AJAX, I don't see at all why someone
would have to know how to code a library for them before using a library for
them. Not knowing how to build a car doesn't prevent me to use one. I agree
that's it's better to have great knowledge, but when you don't have any, you
have to find a way to be productive enough, in a tough environment, where
people who manage you are not always tech-savvy and wouldn't sort out
between the very knowledgeable who spend their time re-coding libraries that
already exist, and the ones who can learn how to use decently an already
existing library (backed up by a large community and where the bugs are more
likely to be corrected soon).

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

[Sergio Cinos]

2011/2/3 Guillaume Andrieu :
> 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

Re: [JSMentors] Re: Today, Web Development Sucks

[Guillaume Andrieu]

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

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. 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'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. Then the maintenance cost
is too high for upgrading to other browsers and nobody wants to finance it,
so you're stuck with it.

Still, using libraries like jQuery and the like are exactly allowing to do
better than that, since they support more than one single version of a
browser. So you're not lowering your chances of being stuck by using a
general purpose library.


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

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