The future of Prototype framework
Mislav
thread about Fork by Peter Michaux. Some other developers expressed
their concerns that they shared with Peter - the same concerns that I
keep hearing over and over in the past few months. Basically they can
be summed up to these points:
1) it augments Number, String, Array, HTMLElement and Function
prototype
2) it is not namespaced
3) its Event module is not robust enough
4) Enumerable module is slow / is strange / sucks (pick any of these)
5) strange inheritance scheme [1]
6) Sam is not addressing the public enough or acknowledging
contributions
7) it doesn't have official/up-to-date documentation
In the following paragraphs I'm going to debunk these. I'm nothing more
than a Prototype contributor and enthusiast who, at one point, almost
ditched Prototype and created a fork (hybrid of YUI, mootools and
Prototype) for his personal use, but then recent updates proved things
were still rolling and won my attention back. Since then I dedicated my
spare time to try and make Prototype better instead of creating yet
another spinoff.
So, here we go. I'll try to keep it as short as possible. References
can be found on the bottom.
--------------------
1) augment *.prototype - JavaScript is based on dynamic prototypal
inheritance and object prototypes are available for writing with a
reason. This way we can add utility methods directly to objects we need
them to operate on. That is true OOP and that is what Rails does to
Ruby built-in types without anyone crying about it. Instead, people
love it. It makes the code shorter, operations more concise and the
whole thing is easier to remember.
People are actually afraid only of Array.prototype augmentation,
because they have been using them as associative arrays all this time.
This is wrong [2], so stop it. When you look at what Prototype does
with a mind unclouded with fear, you'll see that Number, String and
Function extensions are sweet, new Array methods are great, and that
was it does to extend DOM elements is brilliant.
--------------------
2) namespace - Prototype is, in fact, somehow namespaced. Its modules
are namespaced, to be exact: DOM stuff is in Element, xmlHttpRequest in
Ajax, and so on. There is no global namespace because it doesn't fit in
with its philosophy - Prototype is a low-level framework aimed at
making coding easier, not a nightmare. It also extends built-in objects
and you can't namespace _that_.
Some of you say "it doesn't play along nicely with other frameworks". I
fail to see effort to "play along nicely" in other frameworks except
packing it all in a single namespace. If you want to namespace
Prototype for your project that uses YUI, MochiKit and Dojo at the same
time, you can easily do it by hand by taking 20 minutes of your time in
a text editor. But in the end, using multiple frameworks will
inevitably lead to feature duplication.
YUI has everything namespaced, and everyone likes YUI. But everyone
hates writing "YUI.namespace.module.bla.foo.bar()" to access a
function. So what do people do? They bring often used functions to the
global namespace and name them conveniently. In Prototype, you don't
have to undertake effort to have that kind of convenience.
--------------------
3) Event module - True, it is pretty basic right now. It doesn't do
scope correction, work around Safari bugs, or provide the ability to
remove all the observers from an element... Or does it?? See ticket
#5786 [3] by Andrew and me that brings all this to Event, and more.
This is open source. When you miss a feature you can either whine about
how YUI is better on your blog, or you can pull up your sleeves and get
it done. Event module is more than usable right now and is getting
better, so it is certainly no reason to ditch Prototype, unless you are
making a GMail-killer app or something on that scale.
--------------------
4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype
is awesome! It reduces lengthy code full of endless loops and closures
you can easily get lost in otherwise. It comes at a price, though -
speed. Yes, using "each()" and friends (they all use "each" internally)
can considerably slow your loop. There is a benchmark [4] by Marius
Feraru; run it, observe the results.
OK, let's power on our common sense now. Exactly how much iterations
are we going to need, anyway, and at what rate? The benchmark shows
that, roughly, I can iterate over an array with a 1000 elements about
100 times in a second. That's not at all slow - it is fast! I can have
an array of 1000 HTML elements and iterate over all of them in just 10
milliseconds.
Your common sense should tell you by now that most of the time you
won't even have a 1000 elements in an array. You will iterate over 5,
10, 20, sometimes 50 elements. I'm talking about more than 90% percent
of all cases here - in a big app when speed is critical, you can always
write an ordinary loop - who's stopping you? But in all other cases,
you can have the sweet, sweet sugar of Enumerable.
It gets better. The ticket #6650 [5] proposes a speedup of Enumerable
methods by using JavaScript forEach (currently implemented in Firefox
1.5). There is another thing - remember how you can throw $break and
$continue in an iterable? Do you know that for N iterations you need 1
try/catch block for $break, but N of those blocks for $continue? Do you
know that you can continue with an ordinary return statement, and that
dropping $continue support in favor of return can speed up all
iterations by almost 40% percent? I'll be posting a patch for this
soon.
For people worried about Hash implementation, see #6649 [13]. If the
patch gets applied you will be able to iterate over functions, use less
memory and have a "safe" type of Hash that you can store anything into.
--------------------
5) class inheritance - Currently Prototype utilizes Class.create() and
Object.extend() to get things done. Why do people have a problem with
this? OK, we're quite aware that this doesn't scale, but it served us
so well all this time and it's going to get much better in Prototype
2.0 [6]. Remember, the "all-mighty" and powerful YUI doesn't have a
class inheritance scheme other than native JavaScript prototype
inheritance and manually juggling the prototype objects around when
subclassing ... But it still works and scales [7] pretty well, doesn't
it?
--------------------
6) Sam Stephenson - I admit I too miss having him around the list or
ticket discussions, but if people willingly fill in for him than this
is not a problem. And people are doing that - Justin Palmer is blogging
about Prototype development and roadmap [8] (something Sam clearly
doesn't have time for) and Thomas Fuchs (madrobby) is doing a great job
going through tickets, commenting and applying tested patches
regularly. Sam also occasionally pulls up his sleeves and applies a
"flurry of updates" [9] which alone is worth subscribing to the RSS log
[10] because there are awesome gems in there.
Regarding patches lingering about for too long: this is not because Sam
or Thomas are lazy or indecisive. It is because patches are being
submitted in poor quality and/or without tests. Like in Rails, tested,
quality patches get applied sooner.
--------------------
7) API documentation - in the works [11]. Until released, read Justin
Palmer [8] and other resources [12] which served us so well all this
time. Documentation existed all this time, only it wasn't centralized
or written by Sam so people didn't realize it.
--------------------
*Whew* There it is - all points covered.
Currently the only thing I don't like in Prototype codebase is the
Insertion API and small things that pollute the global namespace like
Toogle.display() and Try.these(). But I have yet to come across a
JavaScript framework that matches the power of DOM manipulations in
Prototype. Form serialization is robust, Ajax is powerful but still
easy to use, and the Trac is full of ready patches that just wait being
decided on. All this is covered by tests built on a JavaScript unit
test library.
Comments/questions appreciated. Please be short and to the point -
there are a lot of things that can be discussed here. Please don't
troll or point out to other frameworks. And please point out to valid
points of criticism I've missed.
Just don't whine - make it work.
(And contribute.)
--
Mislav
references:
[1]
http://encytemedia.com/blog/articles/2006/5/23/prototype-inheritance-madness
[2]
http://www.andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/
[3] http://dev.rubyonrails.org/ticket/5786
[4] http://gfx.neohub.com/benchmark/t/loops.html
[5] http://dev.rubyonrails.org/ticket/6650
[6] http://sam.conio.net/articles/better-inheritance-for-prototype
[7] http://code.google.com/p/yui-ext/
[8] http://encytemedia.com/development
[9]
http://encytemedia.com/blog/articles/2006/9/5/the-flurry-continues-more-prototype-updates
[10] http://dev.rubyonrails.org/log/spinoffs/prototype/src?format=rss
[11]
http://encytemedia.com/blog/articles/2006/10/31/prototype-a-call-for-documentation
[12] http://del.icio.us/mislav/prototype.js+documentation
[13] http://dev.rubyonrails.org/ticket/6649
Ken Snyder
Applause! Whistles! Good rebuttal.In the following paragraphs I'm going to debunk these....
Just to add. The Enumerable methods really underscores one of Prototype's philosophies:4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype is awesome! It reduces lengthy code full of endless loops and closures you can easily get lost in otherwise. It comes at a price, though - speed. Yes, using "each()" and friends (they all use "each" internally) can considerably slow your loop. There is a benchmark [4] by Marius Feraru; run it, observe the results.e.
Generally favor brevity, ease of creation, and ease of maintenance over speed.
I believe this is a very important part of forward-thinking web philosophy and I am excited to be able to contribute.
--Ken
Mark Holton
Thanks
Deco Rior
Karl Guertin
> Ruby built-in types without anyone crying about it. Instead, people
> love it. It makes the code shorter, operations more concise and the
> whole thing is easier to remember.
The Ruby community does this and nobody else. It's possible in Python,
but it's called monkeypatching and is considered a last-case option.
I've been bitten doing this, so I'm twice shy.
> People are actually afraid only of Array.prototype augmentation,
> because they have been using them as associative arrays all this time.
I'm against builtin prototype augmentation (henceforth prototype
hacking) and I've never used array as an associative array. Because
prototype hacking isn't namespaced, doing it on objects that don't
belong to you leads to the potential of breaking other people's code.
With Object.prototype, the breakage is obvious and I was very happy to
see that yanked in 1.4, but the problem with Array.prototype is more
subtle.
Brendan Eich and the ECMA working group are once again active, so
we'll start seeing changes to JavaScript. Array is ripe for
improvement, so what happens if the language gets a builtin with the
same name as a current prototype extension and a different signature?
Will prototype change signature to match and break all the working
prototype code? I expect not, I'd anticipate a wrapper function that
would preserve signature. Now how does the rest of the javascript
world deal with that? They obviously won't be dealing with prototype
legacy code so they can use the builtin just fine, but what happens
when someone wants to use the scriptaculous autocompleter and pulls in
prototype? What if you don't fully control the final page environment?
I'll admit that the above scenario probably won't happen because I'd
expect the standards guys to be aware of prototype, but it could
happen and the possibility is enough for me to delcare prototype
hacking on objects you don't own to be evil. There are workarounds
like Dean Edwards' iframe trick, so it should be possible to hack
around situations like the above if you're aware of the problem, but
it wouldn't ever be a problem in the first place if prototype hacking
didn't happen.
> 2) namespace - Prototype is, in fact, somehow namespaced.
The complainers seem to think that somehow it's not... I don't care
about this because my stuff _is_ all namespaced, so I'll leave it at
that.
> YUI has everything namespaced, and everyone likes YUI. But everyone
> hates writing "YUI.namespace.module.bla.foo.bar()" to access a
> function. So what do people do?
I like MochiKit's solution. If you control the page, you export
everything so that you don't have to keep typing the namespaces. If
you're writing something to be reused, you can namespace your calls to
play along nicely with others.
If you're curious, I use TurboGears and MochiKit instead of Rails and
prototype, so my position is probably a bit different from most
subscribers. I started on prototype about a year ago, realized what
Object.prototype extensions implied, and jumped ship. I'm on the list
to keep tabs on scriptaculous.
Deco Rior
On Dec 1, 2006, at 1:32 PM, Karl Guertin wrote:
>
> On 12/1/06, Mislav <mislav....@gmail.com> wrote:
>> [Opening a class] is true OOP and that is what Rails does to
>> Ruby built-in types without anyone crying about it. Instead, people
>> love it. It makes the code shorter, operations more concise and the
>> whole thing is easier to remember.
>
> The Ruby community does this and nobody else. It's possible in Python,
> but it's called monkeypatching and is considered a last-case option.
> I've been bitten doing this, so I'm twice shy.
FYI
The Lasso community is also heavily OOP, although not a requirement
with LASSO.
Essentially, there is backwards compatibility to older scripting, but
the migration to OOP has been rapid since version 8.
Deco
tobie
Peter Michaux
Mislav wrote:
> 1) augment *.prototype - JavaScript is based on dynamic prototypal
> inheritance and object prototypes are available for writing with a
> reason. This way we can add utility methods directly to objects we need
> them to operate on. That is true OOP and that is what Rails does to
> Ruby built-in types without anyone crying about it. Instead, people
> love it. It makes the code shorter, operations more concise and the
> whole thing is easier to remember.
Rails and Prototype execute in two completely different environments.
In Rails the code needed to extend these built-in classes is already
on the server. With Prototype the added sugar has to be transmitted to
the client. Also there could be an exotic browser bug related to the
sugar code that is not detected during testing.
> --------------------
>
> 2) namespace - Prototype is, in fact, somehow namespaced. Its modules
> are namespaced, to be exact: DOM stuff is in Element, xmlHttpRequest in
> Ajax, and so on. There is no global namespace because it doesn't fit in
> with its philosophy - Prototype is a low-level framework aimed at
> making coding easier, not a nightmare. It also extends built-in objects
> and you can't namespace _that_.
I don't think you can say that Prototype is "somehow namespaced"
because it doesn't define it's own namespace and stick too it. If
using many different namespaces is considered namespcing then all
JavaScript is somehow namespaced. For no necessary reason functions
are attached to the Element object (not Element.prototype) and these
functions could have just as easily been in an object called
ProtoElement. I can't see how calling a library that augments built-in
prototypes can be considered namespaced at all. That is the ultimate
move against namespacing.
A JavaScript library doesn't have to be namespaced in green field
projects but the decision could be regretted later when third party
components are available but unusable do to the lack of namespacing.
Of course, using a library without namespacing in a legacy code
situation is asking for trouble.
> YUI has everything namespaced, and everyone likes YUI. But everyone
> hates writing "YUI.namespace.module.bla.foo.bar()" to access a
> function.
I don't hate it. It isn't fun like a circus ride but I do appreciate
the benefits.
> So what do people do? They bring often used functions to the
> global namespace and name them conveniently. In Prototype, you don't
> have to undertake effort to have that kind of convenience.
With a namespaced library the option is there for the developer to
make the appropriate decision given the particular page being
developed.
> --------------------
>
> 3) Event module - True, it is pretty basic right now. It doesn't do
> scope correction, work around Safari bugs, or provide the ability to
> remove all the observers from an element... Or does it?? See ticket
> #5786 [3] by Andrew and me that brings all this to Event, and more.
>
> This is open source. When you miss a feature you can either whine about
> how YUI is better on your blog, or you can pull up your sleeves and get
> it done. Event module is more than usable right now and is getting
> better, so it is certainly no reason to ditch Prototype, unless you are
> making a GMail-killer app or something on that scale.
I hope the situation of user contributions to Prototype is improving.
> --------------------
>
> 4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype
> is awesome!
I don't think it is awesome. I think the syntax is clumsy. Having to
define a function to run a loop is a major kludge to me.
> It reduces lengthy code full of endless loops
It doesn't reduce code length by much
http://peter.michaux.ca/article/48
and along with this minor reduction in loop lengths, much library code
has to be downloaded to implement the sugar.
> and closures you can easily get lost in otherwise.
A experienced JavaScript developer coming to a project using Prototype
for the first time will be confused by the iterators when for loops
could have been used. I can easily see how this argument can be
disregarded but the sugar iterators do not make loops look simpler to
everyone.
> It comes at a price, though -
> speed. Yes, using "each()" and friends (they all use "each" internally)
> can considerably slow your loop. There is a benchmark [4] by Marius
> Feraru; run it, observe the results.
>
> OK, let's power on our common sense now. Exactly how much iterations
> are we going to need, anyway, and at what rate?
With a slow computer and demanding animation or dragdrop behavior of
complex structures I want to have as efficient code as possible during
these operation. At these times you can stop using the sugar but right
now the sugar is part of the underlying Prototype and Scriptaculous
library so it is difficult to stop that sugar unless patches are
accepted to Prototype and Scriptaculous.
> It gets better. The ticket #6650 [5] proposes a speedup of Enumerable
> methods by using JavaScript forEach (currently implemented in Firefox
> 1.5).
Unfortunately Firefox is probably only 10-20% of general users so for
now and for some sort of relatively meaningless comparison multiply
the savings/excitement by 0.2 at best. Also this means that you will
have to have two versions of the sugar implementation.
If JavaScript 1.7 catches on in other browsers then in about 5 years
there will be real iterators available for use.
> --------------------
>
> 5) class inheritance - Currently Prototype utilizes Class.create() and
> Object.extend() to get things done. Why do people have a problem with
> this? OK, we're quite aware that this doesn't scale, but it served us
> so well all this time and it's going to get much better in Prototype
> 2.0 [6]. Remember, the "all-mighty" and powerful YUI doesn't have a
> class inheritance scheme other than native JavaScript prototype
> inheritance and manually juggling the prototype objects around when
> subclassing ... But it still works and scales [7] pretty well, doesn't
> it?
YUI has the best JavaScript inheritance mechanism I have encountered
that gives the closest Ruby-like behavior possible. It is simple and
reinforces the ideas of prototype based inheritance when a developer
is using it.
http://kevlindev.com/tutorials/javascript/inheritance/index.htm
http://peter.michaux.ca/article/1
http://peter.michaux.ca/article/49
http://peter.michaux.ca/article/50
> 7) API documentation - in the works [11].
For me, one of the most valuable software development steps is the
reflection and evaluation I must make when writing API documentation.
It forces me to review the product of my work and if I cringe even a
little when I am explaining any part of the API then I know I got it
wrong. It is the time where I can see if the API as a whole is
consistent. I think API documentation is probably more important then
tests because fixing the internals later is easier then asking people
to change their library calls.
> *Whew* There it is - all points covered.
But not debunked without tradeoffs that could be judged as
unacceptable. Every library will have tradeoffs.
For a long time I wanted and tried to like Prototype because it has
the Rails stamp of approval and tight Rails integration but I just
can't make it work for me. That's why I've gone my own way and started
a new library for use with Rails that can just as easily be used
outside of Rails and when I'm working with legacy code.
Peter
--------
http://forkjavascript.org
tobie
What is it exactly that you are trying to do? Drive Prototype users
away from Prototype to your own library?
I'm sorry, but I'm starting to find your attitude slightly displeasing
to say the least.
If you do not like Prototype, don't use it. If you have another library
to offer, please feel free to promote it, but are you sure it is
necessary to bash on Prototype to do so?
Regards,
Tobie
--
Tobie Langel
http://tobielangel.com
Mislav Marohnić
Peter,
What is it exactly that you are trying to do? Drive Prototype users
away from Prototype to your own library?
With Prototype the added sugar has to be transmitted to the client. Also there could be an exotic browser bug related to the sugar code that is not detected during testing.
Since when do we fear browser bugs? We will work around them
About namespacing, see my most recent thread. I'd like you to leave a comment on it...
A experienced JavaScript developer coming to a project using Prototype for the first time will be confused by the iterators when for loops could have been used.
That was me. I didn't understand Enumerable until Justin blogged about it. I found it strange at first - now I love it. You have to be open minded.
About the bottlenecks, we'll try to work on it. For large arrays and huge number of loops I revert to using for loops, but that's very rare.
YUI has the best JavaScript inheritance mechanism I have encountered
that gives the closest Ruby-like behavior possible. It is simple and
reinforces the ideas of prototype based inheritance when a developer
is using it.
I don't see why Prototype doesn't. It just has sugar added to it - Class.create(), Object.extend()
That's why I've gone my own way and started a new library for use with Rails that can just as easily be used outside of Rails and when I'm working with legacy code.
I've been reading your blog since before Fork. Your level of JavaScript knowledge is admirable. Perhaps with all that ideas how to make a better framework you can certainly come up with occasional patches/suggestions for the Prototype framework on the ticket system, too? It's far from hopeless, believe me ;)
Mislav
Peter Michaux
On 12/3/06, tobie <tobie....@gmail.com> wrote:
>
> What is it exactly that you are trying to do?
The Rails world has a bad practice of promoting only the positives.
This misleads people. Rails gives Prototype the stamp of approval by
default inclusion and the most some people might know about Prototype
is
<%= javascript_include_tag 'prototype' %>
If Prototype's front page contained a link to a page describing design
tradeoffs I think users evaluating the library's worth and
applicability would be much better served. The code shows these
features in plain JavaScript so why not just tell them quickly in a
little bit of plain English? If they find the tradeoffs acceptable
then it doesn't matter if they read them in JavaScript or English. It
is just that the English will make the evaluation much faster. Also
there are many clever Rails programmers that don't know even
intermediate JavaScript and eventhough they would understand the
tradeoffs as concepts if written in English they can't see them when
reading the Prototype code directly.
> Drive Prototype users away from Prototype to your own library?
No.
> I'm sorry, but I'm starting to find your attitude slightly displeasing
> to say the least.
>
> If you do not like Prototype, don't use it. If you have another library
> to offer, please feel free to promote it, but are you sure it is
> necessary to bash on Prototype to do so?
I think Rails users should be warned of the potential serious
consequences of using Prototype and investing time into learning to
write JavaScript with the Prototype way when that invested time would
be better spent learning how to write and understand usual JavaScript.
They will need these skills when they try and create a unique UI.
Peter
-------
http://forkjavascript.org
Peter Michaux
On 12/3/06, Mislav Marohnić <mislav....@gmail.com> wrote:
> On 12/3/06, tobie <tobie....@gmail.com> wrote:
> >
> > Peter,
> >
> > What is it exactly that you are trying to do? Drive Prototype users
> > away from Prototype to your own library?
>
> He has the right to criticize the framework. His points are valid, although
> he sounds like the library is completely hopeless - that's the part I don't
> like.
It is not completely hopeless. Prototype/Scriptaculous might be fine
for a green field project that will never use third party JavaScript.
I was taught to never say never.
> > With Prototype the added sugar has to be transmitted to the client. Also
> there could be an exotic browser bug related to the sugar code that is not
> detected during testing.
>
> Since when do we fear browser bugs? We will work around them
We should fear browser bugs. We can only work around the ones we know
about but we don't want to need to revisit working websites when a new
bug appears if we can help it. Adding unnecessary code only increases
the "length of the chain" and the chance of a weak link. It is true
that the Prototype sugar mostly involves only JavaScript 1.5 features
and not host objects. It is reasonable to expect that a browser can
execute the JavaScript language and so the sugar should not have
problems. However I think maintaining concise code that uses "short
chains" is a wiser approach over all.
> > A experienced JavaScript developer coming to a project using Prototype for
> the first time will be confused by the iterators when for loops could have
> been used.
>
> That was me. I didn't understand Enumerable until Justin blogged about it. I
> found it strange at first - now I love it. You have to be open minded.
I was open minded and after looking at the tradeoffs I made a choice.
It seems being decided and opposite to someone elses decision equals
closed minded. <shrug>
With Enumerable you get a different way of thinking that may make you
feel good when you program. However you get decreased performance, are
tied to a particular library for basic language function, that library
must be downloaded and any code maintainer must have knowledge of that
library to maintain the derivative code.
The decreased perfomance is the big hit for me. Why need several
function calls, a function definition and a try catch block for each
iteration when JavaScript has a for loop? I think this is working too
hard to save only a few characters of code and to feel good. My job is
to write the most robust code I can and the Enumerable stuff does not
support that goal.
DHH wrote a great April fools joke that I think applies to Prototype
use of sugar
http://www.loudthinking.com/arc/000582.html
> About the bottlenecks, we'll try to work on it.
The thing is you don't have to. Just use loops. Finished. The time
could be better spent on fixing bugs and improving workarounds or
refactoring other parts of Prototype.
> For large arrays and huge
> number of loops I revert to using for loops, but that's very rare.
>
> > YUI has the best JavaScript inheritance mechanism I have encountered
> > that gives the closest Ruby-like behavior possible. It is simple and
> > reinforces the ideas of prototype based inheritance when a developer
> > is using it.
>
> I don't see why Prototype doesn't. It just has sugar added to it -
> Class.create(), Object.extend()
>
>
> > That's why I've gone my own way and started a new library for use with
> Rails that can just as easily be used outside of Rails and when I'm working
> with legacy code.
>
> I've been reading your blog since before Fork. Your level of JavaScript
> knowledge is admirable. Perhaps with all that ideas how to make a better
> framework you can certainly come up with occasional patches/suggestions for
> the Prototype framework on the ticket system, too? It's far from hopeless,
> believe me ;)
You can watch YUI, Fork or any of the other libraries for workarounds
and novel ideas with nice implementation and migrate those changes to
Prototype. I want a namespaced library and so won't be spending my
time writing patches particular to Prototype. I think someone needs to
dive in and rewrite Prototype's implementation with more consistency
and call it Prototype 2 with some API changes if necessary. In the
rewrite, the Enumerable stuff could be provided but not actually used
by the library itself so perfomances can be best when needed. Along
the way all tradeoffs could be noted and consistent documentation
written. For someone that understands all of Prototype well and
another library like YUI this entire process might take a month. It
would be huge improvement and users of Prototype would know what they
are getting into when they start using.
Peter
-------
http://forkjavascript.org
Mark Holton
Annoyed as well,
Mark
Mislav Marohnić
This thread is strictly about Prototype, current problems and where it's headed
-M
Clay Loveless
> Please, keep the discussion about Peter and Fork on his thread
How about on his own list?
I'm preparing to unsubscribe from this list based on the level of
noise that has popped up in the last week.
Peter: Prototype and Scriptaculous got to be so widely used by being
good (or good enough) to satisfy the needs of a great many people. I
suggest you spend your time getting Fork to that point and gaining
converts through illustrated merit rather than spending your time
tirelessly evangelizing on a list that's dedicated to the projects
you're advocating *against*.
Enough already.
-Clay
--
Killersoft.com
Mark Holton
I want to hear about how people are making things happen with a library I enjoy -- Prototype + Scriptaculous
Thomas Fuchs
That brings to my mind:
http://dev.rubyonrails.org/report/21 (faults)
http://dev.rubyonrails.org/report/22 (unprocessed patches)
http://dev.rubyonrails.org/report/25 (untested patches)
Everything you see there is waiting for comments and tests--
so, anyone, please go ahead... :)
-Thomas
Thomas Fuchs
Am 01.12.2006 um 21:32 schrieb Karl Guertin:
> Brendan Eich and the ECMA working group are once again active, so
> we'll start seeing changes to JavaScript. Array is ripe for
> improvement, so what happens if the language gets a builtin with the
> same name as a current prototype extension and a different signature?
> Will prototype change signature to match and break all the working
> prototype code? I expect not, I'd anticipate a wrapper function that
> would preserve signature. Now how does the rest of the javascript
> world deal with that? They obviously won't be dealing with prototype
> legacy code so they can use the builtin just fine, but what happens
> when someone wants to use the scriptaculous autocompleter and pulls in
> prototype? What if you don't fully control the final page environment?
>
> I'll admit that the above scenario probably won't happen because I'd
> expect the standards guys to be aware of prototype, but it could
> happen and the possibility is enough for me to delcare prototype
> hacking on objects you don't own to be evil. There are workarounds
> like Dean Edwards' iframe trick, so it should be possible to hack
> around situations like the above if you're aware of the problem, but
> it wouldn't ever be a problem in the first place if prototype hacking
> didn't happen.
What are you talking about? We're not writing Prototype for some version
of JavaScript that might or might not arrive years from now.
If they really dare to break backwards compatibility, well, the worst
thing that can
happen is that we have to release a new version. I'm pretty sure
browsers will still
have release candidates and beta versions in the future, so there
should be plenty
of time to do so.
I'd trade in having.to.write.long.lines() for concise code every day.
-Thomas
RobG
> I totally agree. It's completely unprofessional, and distracting to
> self-promote your own little framework the way that you are.
Peter was responding about Prototype to a thread entitled "The future
of Prototype framework". His criticisms were valid and substantiated
with suggestions for improvement. His only mention of Fork was in
response to another post, his promotion of Fork was in an appropriately
titled thread prefixed by "ANN:".
You may note that the OP started the thread with:
"Lately we have witnessed some repeated Prototype criticism in
the thread about Fork by Peter Michaux."
I think Peter is entitled to respond. If you have criticisms of Fork,
let them be known or go to some other news group and air your views
there.
--
Rob
Andrew Dupont
I'd like to mention (once again) that nearly all criticism of Prototype
falls into two categories:
(1) Stuff it does that you don't like (augmented prototypes, shallow
namespacing, syntactic sugar). These are philosophy differences, and
they are not subject to veto. Prototype tries to operate under the
same general philosophy as Ruby, so if you don't like that philosophy
then there are other wonderful frameworks you can use instead.
(2) Stuff that shows a lack of polish, or stuff that doesn't reflect
well on a community. (Lack of documentation, unprocessed patches,
glaring bugs, little communication). I will acknowledge that Prototype
has room to improve in this area. But that's why we're doing something
about it. We've formed a Prototype Core development team *and* a
documentation team. Thomas has done a great job of responding to
patches and submitting bugfixes.
And even though Sam is not very vocal: I am. Justin Palmer is. Thomas
Fuchs is. Dan Webb is. We blog about Prototype all the time, and
we're able to give input into its long-term direction. If there's some
aspect of the the Prototype community (this mailing list, the IRC
channel, and the blogs of Core members) that you find lacking, let one
of us know. Don't feel like you're not being heard just because you
don't have Sam's ear.
Cheers,
Andrew Dupont
Karl Guertin
> What are you talking about? We're not writing Prototype for some version
> of JavaScript that might or might not arrive years from now.
Given that:
1. The language can change. I think 'years from now' is unlikely but
that's not important to the argument.
2. Prototype hacking is not namespaced.
I'm arguing that a future language change could conflict with an
enhancement in Prototype.
For example, let's say that the standards group desides Array.each
will take an array of arrays and appends the lhs array onto the end of
all the arrays passed as arguments (this is a pretty dumb idea, but
it's just an example).
The prototype maintainers either have to break compatibility with all
the prototype code out there or have to break Array.each for everybody
else. I don't like the idea of my code breaking in the future (I make
pages that wind up in public sector use, so an app running 6-7 years
is not farfetched) nor do I like the idea of my choices causing
someone else's code to break. It's the same scenario as javascript
libraries clobbering each others' prototype extensions but with the
language itself instead of a library.
I don't think this scenario is very likely, but it does illustrate why
I oppose prototype hacking on shared objects (Object, Date, Array,
String, RegEx, etc). This is a response to the original assertion:
> People are actually afraid only of Array.prototype augmentation,
> because they have been using them as associative arrays all this time.
I have never used arrays as associative arrays and I have a technical
reason for rejecting prototype hacking. People are free to decide that
scenarios like this are too remote to be worth considering for their
projects, and I expect most prototype developers will, but that
doesn't mean my position is invalid.
> I'd trade in having.to.write.long.lines() for concise code every day.
I hate writing namespaced code and only do it when my code is likely
to wind up in a mixed environment. I appreciate being able to make the
decision.
Andrew Dupont
> I don't like the idea of my code breaking in the future ...
> nor do I like the idea of my choices causing someone else's code
> to break.
This won't happen. There won't be new stuff added to JavaScript until
version 2, which will also include features like modules and
namespacing to allow code to run on its own island. For example, a
script will be able to use a copy of the "intrinsic" namespace (i.e.,
without whatever extensions have been applied by another script) if it
wants. Any future standardizing of JS will take into account the
difficulty of developing in a heterogeneous environment.
There are two sorts of dangers that Prototype presents: the *pragmatic*
sort (what if I have old scripts that do for..in on arrays, which
Prototype breaks) and the *theoretical* sort (the footprint on the
global namespace is not minimized, what if another script redefines
String.prototype.capitalize incompatibly, etc.). I acknowledge that
the pragmatic dangers are to be guarded from, but I simply am not
terrified by the theoretical dangers. Some people are, and that's
fine. That's why there's Dojo, MochiKit, and YUI. But so far I've
encountered *only one* pragmatic danger of using Prototype, and it's a
by-product of the incorrect code of third parties.
Mislav Marohnić
I'm arguing that a future language change could conflict with an
enhancement in Prototype.
Future changes that modify public APIs in JavaScript will break any other code as well as Prototype's. You're talking about 6-7 years from now - imagine what browsers will look like then? You will have Firefox 6, Opera 12, Safari 4, IE 7.1 and a ton of new stuff that I'm not even trying to imagine. This is not Java where you deploy in a known environment - you're deploying your script into the unknown and you cannot have that kind of security. You have to have unobtrusive code (if it fails, the application still works) that is maintained over time.
I don't think this scenario is very likely, but it does illustrate why
I oppose prototype hacking on shared objects (Object, Date, Array,
String, RegEx, etc).
I don't approve the usage of the term "hacking" when using a natural feature of the language. If we could "subclass" Array, Object, Date and others things would be different - unfortunately subclassing built-in types is a pain (Dean Edwards' blog). Therefore we're stuck with built-in types - at least we can enrich their APIs.
Also I agree with Andrew Dupont.
--
Mislav
Karl Guertin
> I'd like to mention (once again) that nearly all criticism of Prototype
> falls into two categories:
>
> (1) Stuff it does that you don't like (augmented prototypes, shallow
> namespacing, syntactic sugar). These are philosophy differences, and
> they are not subject to veto.
For the record, I do understand this and I have no desire to see
prototype changed. I only intend to point out that the philosophy
differences do not exist because people are ignorant, as implied by
Mislav in the OP, but stem from people operating under different
conditions.
tobie
;-)
Mislav Marohnić
I only intend to point out that the philosophy
differences do not exist because people are ignorant, as implied by
Mislav in the OP, but stem from people operating under different
conditions.
Peter Michaux
> On 12/4/06, Karl Guertin <gray...@gmail.com> wrote:
> >
> > I'm arguing that a future language change could conflict with an
> > enhancement in Prototype.
>
> Future changes that modify public APIs in JavaScript will break any other
> code as well as Prototype's.
I think the point is that being conservative and keeping to a
namespace will reduce the chance of broken scripts when the JavaScript
API is expanded.
> You're talking about 6-7 years from now -
> imagine what browsers will look like then? You will have Firefox 6, Opera
> 12, Safari 4, IE 7.1
:-)
> I don't approve the usage of the term "hacking" when using a natural feature
> of the language.
If programming hacking is something that exists then it occurs within
a language. To execute it must use the natural features of the
language. So hacking uses the natural features of the language.
> If we could "subclass" Array, Object, Date and others
> things would be different - unfortunately subclassing built-in types is a
> pain (Dean Edwards' blog). Therefore we're stuck with built-in types - at
> least we can enrich their APIs.
You can but it may not be pragmatic/prudent/wise knowing the language
API will expand. This is similar to extending Object.prototype which
will likely break other code. JavaScript lets you shoot yourself in
the foot constently. Programmer discipline is required.
Peter
--------
http://forkjavascript.org
Karl Guertin
> of the language.
I've called if prototype hacking for a while. I find it fits in with
the general idea of doing something expedient that can possibly break.
> This won't happen. There won't be new stuff added to JavaScript until
> version 2, which will also include features like modules and
> namespacing to allow code to run on its own island....
[snip]
> But so far I've
> encountered *only one* pragmatic danger of using Prototype, and it's a
> by-product of the incorrect code of third parties.
That's reasonable enough. When I initially made the decision in
JavaScript, Object.prototype was in use which was much less okay. My
current opposition is more theoretical, but I have, as mentioned, seen
a monkeypatch in Python backfire and cause a lot of problems for
people. When javascript grows namespaces in all the popular
browsers^W^W^W^WIE, consider my objection dropped.
RobG
If that is so, then you must think whoever decided to extend the
built-in Array object is also ignorant. If you don't accept that (and
clearly you don't), then your criticism is completely without merit.
The example of for..in is just the obvious case, the underlying issue
is that once you extend a built-in object, it is no longer available in
its original form. Anyone trying to create their own subclass, for
whatever reason, is stuck with the extended object. They have a choice
of accommodating the extensions or not using the library.
It has been stated here that a primary goal of Prototype is to reduce
the amount of code that a programmer must write, and that
considerations such as execution speed and architectural cleanliness
take a back seat.
Now that is fine, but to generalise that anyone affected by that
decision is ignorant is hardly reason argument. A much better response
is to accept the shortcomings of Prototype, make sure people using the
library are aware of them and work toward attenuating their effects,
either by suggesting work-arounds or fixing them at the source.
--
Rob
tobie
Using a for...in loop on an Array is bad practice / plain wrong (c.f.
http://www.andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/).
I wouldn't call somewhat using it an ignorant... but the fact remains
that he ignores that arrays should not be iterated over that way.
Seriously, I don't see how you can call that a shortcomings of
Prototype.
regards,
Tobie
Karl Guertin
> The example of for..in is just the obvious case, the underlying issue
> is that once you extend a built-in object, it is no longer available in
> its original form. Anyone trying to create their own subclass, for
> whatever reason, is stuck with the extended object. They have a choice
> of accommodating the extensions or not using the library.
You seem to have missed their argument. It is laid out pretty clearly
in the above posts and goes something like this:
"""
The only repeated problem reported by prototype.js users is for...in
loops on Array.
You can make arguments as to why a particular prototype.js design
decision is bad, but we don't hear about it causing problems. When it
becomes a problem, we'll fix it. Until then, practicality beats
purity.
"""
Unless you have an actual case where prototype is causing a problem,
reprimanding them on their design decisions is basically trolling.
RobG
> Rob,
>
> Using a for...in loop on an Array is bad practice / plain wrong (c.f.
You ignored the bulk of my post - I'll keep it simple.
If a library adds properties to built-in objects, it should ensure that
anyone using that library is aware of the extra properties and allows
for them where necessary. A library that doesn't extend built-in
objects doesn't have that problem.
> Seriously, I don't see how you can call that a shortcomings of
> Prototype.
You can regard it as a shortcoming or a feature, that point is moot.
What you do have to acknowledge is that it is a fact and that users
should be aware of it. When someone says "Oh, but library X extends
Array, String, etc." you say yes, with these properties... and we deal
with that like this... then it's up to the questioner to make up their
mind whether to continue with the library or not.
--
Rob
grundprinzip
your post is really great and I think you pointed out what is really
important if you use the prototype library. And since there was already
much said, I wont add much.
I'm using prototype for quite a long time now and not only for some
client side aesthetics but for real applications and its great.
The bad thing about prototype is the lack of centralized documentation
(even if there is a try [1]), but the good thing and the main important
point is that it behaves like you would expect it to do and this helps
development and improves the productivity of the developer.
Martin
[1]
http://encytemedia.com/blog/articles/2006/10/31/prototype-a-call-for-documentation
Thomas Fuchs
You're talking about 6-7 years from now - imagine what browsers will look like then? You will have Firefox 6, Opera 12, Safari 4, IE 7.1