"The Good Enough Revolution" - As it applies to js

[Pherdnut]

The argument against libraries is not just related to javascript, but

is of general interest for most programming languages. The site I am
working at has developed a number of VB applications over the years
using MS development tools.  Recently, they have been forced to
upgrade certain parts of their technology stack, and now half of those
VB programs must be re-written because the current libraries don't
support things that were use in previous versions.

So while at the time they might have been seen as "good enough", they
certainly aren't now.

What is the general argument against libraries? You provided yet
another example of either MS sucking or your team letting too many
versions go by before upgrading. At some point things do have to
change or go stale. I expect JQ to be well-maintained but even if it
wasn't there's no future-proofing against MS's refusal to conform to
standards. I'm new to this newsgroup so I've been trying to read up on
past debates and I keep seeing this recurring idea that a good library
should somehow anticipate the quirks of a new browser.

How is such a thing possible? In ten years, MS has barely made any
real movement in conforming to the W3C DOM. At this point, I'm almost
more worried about how much of a pain in the butt it's going to be
when/if they finally start actually trying now that we've really
nailed down some solid methodology for catering to their garbage.

Let's imagine I did write my own custom library with nothing but
exactly what we needed for the team of 23 front end developers I work
with and it was even a good 20% faster than JQ by some meaningless
standard. Odds are perfectly reasonable I'm not going to be at that
company when IE 9 rolls around. What's better for the team, my code,
or a popular framework supported by a crew who will be anticipating
changes that need to be made from the first day the beta of IE 9 is
made available.

Also, I think the fact that we have to write for a number of
conflicting interpretations of the very language we're writing with
and the object models it follows, makes the library question a very
different one where JS is concerned.

 

[RobG]

I regularly reduce old code on the sites I work on by more than half
using JQ and I'm being conservative.

Reducing the number of lines of code is, of itself, pointless. If that
is the sole beneift of the exercise, you've likely wasted your time
(and the money of your employer).

It's probably been used to knock
out megabytes worth of crap-code on our sites in just the last couple
months. That's worth a one-time cache of 15K for the user.

Then the "crap code" would also be cached, so what's been saved? Your
example might have some meaning if you could produce a business case
for doing it.

If you had
say... 3-5 static page sites that just needed some form validation in
mind, I could see your point.

That is a common scenario where a library with validation plugins is
added to a site - the "developers" justify it on the basis that it
isn't worth writing bespoke code for such a trivial excercise and that
using a library is "good enough".

Use snowballs from there, so that the library is used for all sorts of
things that it shouldn't; soon enough the site is dependent up it and
technology choices are foisted on unsuspecting users.

 

[Erik Reppen]

Formerly Pherdnut btw. Same account. e-mail always revealed my name.

By 'knock out' I meant 'eliminated/replaced.' By crap code I mean
JavaScript written by people who supposedly know Java and can barely
handle HTML. I've seen tables dynamically built for every row of a
table, markup in our database, and one gem of a for loop with
something like 215 compound conditional statements for the purpose of
building and spitting out a dozen lines of HTML for search results.
Granted, just vaguely competent POJS and real back end devs would
drastically reduce the code but being able to rebuild quickly is very
helpful and ultimately given the sheer volume of behavior covered
there is a massive savings in the amount of script loaded sitewide.
There is no aspect of core JQ I haven't touched on working on our
stuff and yes a few lines can save you hundreds of lines of cross-
browser and convoluted DOM API junk.

That some people misuse libraries does not detract from my experience
with them when they are built properly and used well. I have no
interest in JQ outside of its core, which primarily covers
crossbrowser issues you have to deal with near-constantly in JS. I
don't want somebody to come up with the solution to the problem for
me. I'm actually quite good at that. I just don't want to waste time
redoing the same code-branching solutions to the same dippy little
problems over and over again. I had my own set of functions for that
before that I was reasonably pleased with and I like what this set
offers even better.

 

[RobG]

What is the general argument against libraries? You provided yet
another example of either MS sucking or your team letting too many
versions go by before upgrading.

Thanks, you just proved my point - using a library creates additional
dependancies. Whether those dependancies are acceptable or not
requires analysis of the particular circumstances (a business case).
Therefore, rather than simply saying "libraries are good", make a
sound business case and maybe you'll get it accepted. Or not.

At some point things do have to
change or go stale.

Change for the sake of change? Get that past any reasonably competent
project board. Forced upgrades may be a great strategy for a software
vendor to get you to buy new versions of their products, not so great
when your client finds out what's going on though.

I expect JQ to be well-maintained but even if it
wasn't there's no future-proofing against MS's refusal to conform to
standards.

I don't think MS needs to be singled out for poor support of web
standards.

You've clearly missed previous discussions about feature testing here.
jQuery has belated decided it is a good idea, so it's better prepared
than it was before. It's not that hard to "future proof" web sites
and applications, more relevant is making them tolerant of new,
unknown browsers and until its adoption of feature testing, jQuery was
particularly bad at that. Tolerance is becoming more important with
each new browser-enabled mobile device, as is efficient, concise code.
jQuery sucks at that.

I'm new to this newsgroup so I've been trying to read up on
past debates and I keep seeing this recurring idea that a good library
should somehow anticipate the quirks of a new browser.

All that needs to be anticipated is that a browser may not support any
features required by the scripts being used. It goes beyond "a good
library" to a sound development strategy.

The old bug-bear of "this site doesn't support your browser" has been
replaced by "our script library doesn't support your browser". Guess
that's progress.

How is such a thing possible?

It isn't necessary.

In ten years, MS has barely made any
real movement in conforming to the W3C DOM. At this point, I'm almost
more worried about how much of a pain in the butt it's going to be
when/if they finally start actually trying now that we've really
nailed down some solid methodology for catering to their garbage.

The only sites that would fail would be those dependent upon browser
sniffing. You might be aware that there are still developers who think
it's a viable "good enough" strategy. It isn't and never was.

Let's imagine I did write my own custom library with nothing but
exactly what we needed for the team of 23 front end developers I work
with and it was even a good 20% faster than JQ by some meaningless
standard. Odds are perfectly reasonable I'm not going to be at that
company when IE 9 rolls around. What's better for the team, my code,
or a popular framework supported by a crew who will be anticipating
changes that need to be made from the first day the beta of IE 9 is
made available.

Presumably "your" library would belong to the employer and the IT
section should have a methodology for maintenance and support of the
code. The use of jQuery does nothing to help in that case, there will
still be a significant amount of "library" code written on top of it.
All of that code needs to be tested and updated every time a new
version of jQuery is implemented in addition to every time a new
"supported" browser appears. So what have you saved? Oh, that's right
- if it's not a supported browser, you don't do anything and just let
it break.

Also, I think the fact that we have to write for a number of
conflicting interpretations of the very language we're writing with

You mean ECMA-262 implemenations? What conflicting interpreations?

and the object models it follows

The javascript object model? or the DOM? I don't see how either of
those makes a library like jQuery a no-brainer. Quite the contrary -
jQuery wraps just about every available DOM method to support its
chaining strategy - developers end up writing jQuery, not javascript.
How will jQuery deal with HTML 5 or ECMA-262 version 5?

, makes the library question a very
different one where JS is concerned.

Presumably that is a reference to providing cross-browser support. If
you look at the very limited number of jQuery supported browsers, that
wouldn't be very difficult anyway.

Let's be clear - I'm not saying never user a library. But their over-
use has consequences that reflect on web development as a whole, such
as driving technology decisions (such as browser upgrades) that
otherwise need not have been made, or pushing users toward particular
software vendors or platforms. Those negative aspects should be
avoided as much as possible on the web, where the underlying philosphy
is to make information available as widely as possible with the
minimum of restrictions.

And certainly a "good enough" philosophy should be challenged at every
opportunity. At the least, the goal should be the best quality
possible within the project's constraints (where quality is judged on
functional performance, not things like crappy UI effects).

 

[David Mark]

It is

As my signature might suggest, I generally agree with the idea.

The idea that a script written six years after IE6, proposing to make
cross-browser scripting easier, still fumbles IE quirks mode, ActiveX
and simple things like attributes *to this day* is some sort of
revolutionary breakthrough because such a thing is clearly "good
enough" if lots of people use it?

Still makes progressive enhancement impossible as well. I just don't
see it. I think something like that might be a disruption (in a
positive way) some day. If only...

 

[David Mark]

I regularly reduce old code on the sites I work on by more than half
using JQ and I'm being conservative.

Interesting you should mention that. I often reduce sites by 80% by
throwing out such scripts (among other things). Makes them far more
compatible and reliable as well. I'm sure disabled users appreciate
the changes as well.

And jQuery is not 15K. It's about 50K in the form that is comparable
to other assets (and most sites use a tiny bit of that). The
possibility of compression shouldn't enter into such comparisons.
Think about it.

 

[Matt Kruse]

I don't think it has anything to do with being a "purist", but much
more to do with valuing quality.

But that is the point of the article - that "quality" is not
necessarily the only or best judge of value. People will often
sacrifice quality in exchange for convenience, cost, aesthetics,
familiarity, etc.

The reason I saw a parallel to the common library discussions here is
because many js experts have a myopic view that since code quality is
most important to them, it should be the most important thing to
everyone. And they fail to understand or relate to the masses of
developers who choose the option that is "good enough".

No, it isn't. Those who promote libraries, refuse to listen to valid
criticism and don't see that they aren't "just fine" are the ones
missing the point.

This always sounds to me like the professional photographer who can't
comprehend why anyone would choose not to buy an SLR with multiple
lenses and flashes for taking pictures. Clearly it results in higher-
quality photos. Clearly those who choose cheap point-and-shoot cameras
are missing the point! Don't they see the reduction in resolution? The
increase in noise? The desaturation in colors?! Why would they settle
for that?! They are missing the point!

While people may point out flaws, incompatibilities, or performance
problems with libraries, this need not be an argument for not using
them. Because when you factor in development time, convenience,
support, ease of learning, the number of problems that they _do_
solve, and resulting code quality as compared to what might have been
written otherwise, then they can often be seen as the clear winner.

While not perfect, certainly "good enough".

If that were not the case, then they certainly would have died out by
now. Argue all you want against it, but the "free market" of
technology seems to be going in the opposite direction.

Matt Kruse

 

[Michael Wojcik]

So, do you still buy -nowadays- that a web app should run 100% server-
side, and serve just pure html and as few unobtrusive javascript as
possible ?

Yes, many of them should. Client-side scripting often provides little
or no useful additional functionality. The most popular web
application, search, works just fine without client-side scripting.

I'd bet you $10 that this (bs) isn't going to last for much longer...

What isn't going to last, and for how much longer? If you mean whether
web applications without client-side scripting will continue to be
useful for years to come, I'd take that bet.

People are always predicting the demise of this or that technology or
approach. They're nearly always wrong.

A browser without javascript *enabled* is going to end up being as
useful and desirable as a PC without an internet connection...

Almost 54 million downloads of NoScript say you're wrong.

 

[Matt Kruse]

And certainly a "good enough" philosophy should be challenged at every
opportunity. At the least, the goal should be the best quality
possible within the project's constraints (where quality is judged on
functional performance, not things like crappy UI effects).

Functional performance may be your judge of quality, but to someone
else UI effects may in fact be their measure of quality.

A typical barrier in these kinds of discussions, IMO, is that the
'experts' here don't seem to be able to imagine the world through
someone else's eyes and experience. Things look very different to
different people, and if they choose a different path it's not
necessarily because they are stupid or uninformed. Perhaps you just
can't see the world how they do and don't have to deal with the same
challenges, so you can't relate.

I am fascinated by "pop culture" and trying to understand the
"consensus" decisions that emerge from the swarm of people that all
act independently. Clearly, many javascript experts/purists have
strong arguments against libraries and point out their shortcomings.
Yet it seems like the majority of people out there writing javascript
have decided differently, and they are headed in the library
direction. I have no interest in persuading either side that the other
is correct. I am interested in understanding the merits of each view
so that I can better relate to the development environment that people
find themselves in, and I find myself in sometimes.

Understanding why people apparently choose an option that is of "lower
quality" than another available option can only make us better at what
we do. And as someone who works with many aspects of web technology
(not just js), I want to make sure I know where things are headed and
why. To use an analogy, I want to make sure I have a VHS deck and know
how to use it, even if I think Beta is obviously superior. In the end,
it may not matter what I think is best because it's the consensus of
the mob that will decide where things go. If you refuse to understand
or even acknowledge the advantages of the other way of doing things,
you may close yourself off to new ideas and opportunities. You may be
the guy who still trumpets the superiority of OS/2 and proclaims how
much Windows sucks and how stupid its users are, but finds himself
without a job

Matt Kruse

 

[Erik Reppen]

And certainly a "good enough" philosophy should be challenged at every

opportunity. At the least, the goal should be the best quality
possible within the project's constraints (where quality is judged on
functional performance, not things like crappy UI effects).

My experience is that I have not ended up writing JQuery instead of
JavaScript. It's a really fancy object that takes a lot of the time
and tedium out of the DOM API and uneven support for it. It gets heavy
use but not exclusive use. There's a kind of an absolutist philosophy
here on things. Yes, it uses browser sniffing for some things. I don't
know where yet, but I've read enough of Resig's stuff to trust he's a
good enough dev to avoid it when possible, but sometimes what we're
anticipating is more than just whether a given method or property
exists. How do you test for whether the box model is completely hosed,
for instance? There is more to the unique quirks of a browser that
could be relevant to a library than just the JavaScript methods and
properties supported and I'm a strong believer that coding for the web
requires a strong understanding of the relationship between the JS and
the other languages it's typically intermingled with. Too many would-
be JS rockstars don't know jack about CSS or the finer points of HTML
and their code suffers for it.

On your final point, I agree. I don't think I need to justify the use
of a library as a 'good enough' policy. If a library helps me do
better work in the time allotted, it doesn't murder performance, and
seems perfectly stable to me, I'm going to call that a major win, not
a compromise. There's nothing about extending the element object with
a whole bunch of methods using prototype in a way that doesn't
interfere with the core language that isn't JavaScript. That sort of
flexibility is one of the things that makes JS a beautiful language to
work with.

There is nothing we can do about people who don't want to learn the
craft properly. They are going to produce crappy code regardless of
whether they're pulling it from an ugly library, Dynamic Drive, .NET,
or writing 800-hose hosebeasts all by themselves. Bloat is inevitable
with standards as low as they are to people who don't know better and
good devs tend to eschew management in favor of continuing to actively
write code so that's not likely to improve. If the amateurs do
horrible things with JQuery, let them, or help them along however you
can. Just be happy that there's enough of them out there to keep
anybody with more than mediocre skills in demand. The more they fail,
the stronger arguments for doing it right become. And the more people
who belong there are relegated to Craigslist Computer Services section
offering web services 'any way u want it.'

 

[RobG]

There isn't a general argument against libraries, not least because
'library' is too imprecise a term. Any collection of source code (and/or
source code fragments) might validly be labelled a "library", and so
only the (hypothetical loonies) who write every single character of
every line of code they create at the point of entering it don't already
use something that could be considered a library in one sense or
another.

Yes, I was trying to point out that there are downsides to 3rd party
libraries in that they can force upgrades and re-work for no other
reason than a new version is not backward compatible with a previous
version.

 

[RobG]

Functional performance may be your judge of quality, but to someone
else UI effects may in fact be their measure of quality.

A typical barrier in these kinds of discussions, IMO, is that the
'experts' here don't seem to be able to imagine the world through
someone else's eyes and experience.

I am not, nor have ever professed to be, an expert on javascript.
People engaged in a discussion shouldn't be instantly categorised as
stridently for or against a particular proposition just because they
offer a point of view.

Things look very different to
different people, and if they choose a different path it's not
necessarily because they are stupid or uninformed.

Did I say that people are stupid or uninformed because they use a
library? No, not ever.

Perhaps you just
can't see the world how they do and don't have to deal with the same
challenges, so you can't relate.

You like pigeon-holing people. Of course I can see the benefits of
libraries, I've even pointed people to them when I think it's
appropriate, but there are arguments for and against. I also get very
tired of arguments that something can't be done because of poor
technology choices, or refusal to admit to weaknesses in a development
strategy. 3rd party libraries have downsides, if you want to be seen
as credible, present both sides of the argument.

I am fascinated by "pop culture" and trying to understand the
"consensus" decisions that emerge from the swarm of people that all
act independently. Clearly, many javascript experts/purists have
strong arguments against libraries and point out their shortcomings.

The fact that "experts/purists" point out the shortcomings of
particular libraries doesn't mean they are fundamentally opposed to
libraries. It should be seen as constructive criticism.

Let's name names. David Mark has been strident in his criticism of
jQuery (and other libraries), yet published his own library (as an
exercise to show aspects of library development) and has apparently
decided to assist in the development of Dojo. Is he one of the
"experts/purists" you're referring to?

Richard Cornford has consistently argued that most 3rd party libraries
are poor quality, yet supports the development of code libraries for
re-use.

Garrett Smith has published his APE library.

So get the chip off your shoulder, accept criticism and move on.

Yet it seems like the majority of people out there writing javascript
have decided differently, and they are headed in the library
direction.

Terrific. And they will never be in a position to determine whether
their library of choice is any good or not because they lack the
skills to find out. By the time they do, they've published bucket
loads of library-specific code that can only be salvaged by a re-
write. Great for developers, but take the client's perspective for a
moment.

If this discussion does nothing more than make one person more
thoroughly investigate their choice of js library to the extent that
they can present a balanced case for and against it, then it has been
worth it.

I have no interest in persuading either side that the other
is correct.

Then why post a link to an article about "good enough" development and
use it to support the use of a particular library? Seems like an
argument for mediocrity.


[...]

You may be
the guy who still trumpets the superiority of OS/2 and proclaims how
much Windows sucks and how stupid its users are, but finds himself
without a job

Good grief, more verballing. Windows vs OS/2 was just an example of an
IT "good enough" story that predated the article you linked to. I am
certainly not, never have been, nor ever will be, an evangelist for OS/
2.

 

[Erik Reppen]

Browser object models always have varied, but current trends suggest
that large parts of those object models are converging. It is an under
appreciated fact that Firefox has more non-standard features in its
object model that any other browser that has ever existed, while still
exhibiting the most comprehensive implementation of the existing
standards. Even if/when everyone correctly and fully implements all the
existing/proposed standards there will still be considerable variation
between browser object models. That is the reality of browser scripting;
learn to live with it, others have and it is not going to change.

Richard.

So you 'won' this argument in 2003 but the rest of us are just too
slow to pick up on it. With all due respect, I'm sure everybody here
could teach me a few things I don't know, but it's 2009 and that's
just a little bit silly and perhaps a touch pompous. I don't believe
anybody was doing anything advanced enough with the DOM before IE 7
came out for varying layout or positioning discrepancies and other
concerns to ever be a real issue for your code. I defer to your
achievement given the browsers you worked around at the time because I
certainly don't miss IE 5, and was never blessed with having to deal
with IE 4 but I can't help but wonder if you have a realistic basis
for judging the merits of a modern framework.

There are concerns here other than whether a framework ever has bugs.
That's great that your code never does, but how does it help me if it
doesn't do anything for me that I wasn't already doing for myself.
Yes, I was quite capable of dealing with crossbrowser issues in
regards to the DOM before I ever touched a framework. I know where to
find quirksmode and I've read plenty of Crockford's stuff. But at the
end of the day, it's Dean Edwards' work that I'm really intrigued by
and I'm not sure I would expect any of you guys to understand why at
this point.

 

[jeanph01]

For me, Jquery is great. Period. There is so much passion and desire
to help in the community that I don't see why I would not use it. Ok I
don't program for the IPhone or blackberry or whatever. My clients
have powerful workstations with plenty of bandwidth, lots of Ram but
also with IE6 (ouch!). When I include the library and plugins, I get a
lot of things I will never need or use. So what ? My job is done, i
deliver, and I don't care to continue to work or think about my code
when I go to bed. I love what I do and I like what I create. Am I a
guru in js ? Not at all. So what ? I have fun and I think, this is the
most important thing. And for me Jquery is not good enough, it's the
best choice. My user base like what I do, even if they do have that 50
ms response time that some better programmer could give them.

 

[Garrett Smith]

I am not, nor have ever professed to be, an expert on javascript.
People engaged in a discussion shouldn't be instantly categorised as
stridently for or against a particular proposition just because they
offer a point of view.


Did I say that people are stupid or uninformed because they use a
library? No, not ever.


You like pigeon-holing people.

You know, I've gotten that attitude from other jQuery developers. I've
been asked: "Which library do you use?" I've also been told "We are
using jQuery." And when I reply: "For what/What are you trying to do?"
This is the type of answer that is the most insulting to the religious
fanatic. IT's like, not only do I not follow their sect, I don't even
believe in the fundamentalist ideas.

JQuery is promoted as "magic". I think it invites cult-like following.

Of course I can see the benefits of

libraries, I've even pointed people to them when I think it's
appropriate, but there are arguments for and against. I also get very
tired of arguments that something can't be done because of poor
technology choices, or refusal to admit to weaknesses in a development
strategy. 3rd party libraries have downsides, if you want to be seen
as credible, present both sides of the argument.

jQuery is an abstract set of ideas, values, or experiences developed as
part of a cultural matrix.

(comes right from Wikipedia's "Religion" page).

The fact that "experts/purists" point out the shortcomings of
particular libraries doesn't mean they are fundamentally opposed to
libraries. It should be seen as constructive criticism.

Let's name names. David Mark has been strident in his criticism of
jQuery (and other libraries), yet published his own library (as an
exercise to show aspects of library development) and has apparently
decided to assist in the development of Dojo.

Good place for him .

Is he one of the

"experts/purists" you're referring to?

Richard Cornford has consistently argued that most 3rd party libraries
are poor quality, yet supports the development of code libraries for
re-use.

Garrett Smith has published his APE library.

Thanks, but that does not make me an expert.

(AFL 3.0 is not suitable for commercial use)

The social aspect of Github is great. For example, anyone with an
account can leave criticism for "commits" where it says "comment".

Coincidentally, Github is using jQuery and very slow, have you noticed?

In a recent thread on the "Github" google group, a user reported "slow
script" dialog box in Safari 3. The Github support suggested that a user
upgrade from Safari 3 to Safari 4 because Safari 4 is faster. While that
may be true, I do not accept that Safari 3 is not fast enough.

So, Github answered Richard's "good enough for what" question. jquery is
not good enough for Safari 3.

Garrett

 

[Thomas 'PointedEars' Lahn]

For me, Jquery is great. Period. There is so much passion and desire
to help in the community that I don't see why I would not use it. [...]

Blind leading the blind, that's why. You missed or deliberately ignore the
"25% not answered" part in Richard's posting as well. And you did not quote
any of which what you are replying to. You are a loser finding lame excuses
for your incompetence while blinding yourself to the facts at hand, in the
hope nobody will notice. Like a kid playing "if I can't see them, they
can't see me." Only this time the repercussions of your decisions, and
ultimately and inescapably, your mistakes, affect the lives of a great many
other people. But you don't care about them, do you? Your job is "done"
(it is not) and you have "delivered" (you have not).

<http://jibbering.com/faq/>


PointedEars

 

[Bart Lateur]

Coincidentally, Github is using jQuery and very slow, have you noticed?

In a recent thread on the "Github" google group, a user reported "slow
script" dialog box in Safari 3. The Github support suggested that a user
upgrade from Safari 3 to Safari 4 because Safari 4 is faster. While that
may be true, I do not accept that Safari 3 is not fast enough.

Does Reddit (http://reddit.com) use jQuery? Ah, yeah, apparently it
does.

Occasionally I use an ancient PC to browse the web (600MHz, 256MB RAM),
on reddit.com I consistently get warnings that some Javascript is taking
forever... 3 times on every page load.

It's about the only website where I have this kind of problem.

 

[Gregor Kofler]

Erik Reppen meinte:

I don't believe
anybody was doing anything advanced enough with the DOM before IE 7
came out for varying layout or positioning discrepancies and other
concerns to ever be a real issue for your code.

jQuery was first published in February 2006, IE 7 appeared in October
2006. Go figure.

A - if not _the_ - goal of jQuery is and was to even out the various
pecularities of browsers (or rather browser DOMs). Perhaps it would be a
smart thing to think about intelligent "browser detection" then. And
browser sniffing is not an intelligent way to do so. As it was proven in
2003, 3 yrs before jQuery saw the light of day.

Gregor

 

[Gregor Kofler]

jeanph01 meinte:

When I include the library and plugins, I get a
lot of things I will never need or use. So what ? My job is done, i
deliver, and I don't care to continue to work or think about my code
when I go to bed.

You forgot: We are talking about a *professional* attitude towards
client side scripting (and our work) here.

Gregor

 

[jeanph01]

jeanph01 meinte:


You forgot: We are talking about a *professional* attitude towards
client side scripting (and our work) here.

Gregor

--http://www.gregorkofler.comhttp://web.gregorkofler.com- vxJS, a JS lib in progress

I'm professionnal but what you consider important for your code is
maybe not important for my user.