Tapestry 5
  1. Tapestry 5
  2. TAP5-486

Switch Tapestry's built-in JavaScript support from Prototype to jQuery

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 5.1.0.0
    • Fix Version/s: None
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      Like rats deserting a sinking ship ...

      This is not a definitive requirement; I've created this issue to promote discussion.

      It's quite likely that a move like this could be accomplished quite smoothly for users who are meerly consumers of JavaScript components; authors of JavaScript components would have to make some changes.

      Possibly we should code the jQuery stack from the get-go to NOT use the $() method, but instead use j$(). That extra character to type could make all the difference is allowing a smooth upgrade, where jQuery becomes the default, but prototype/scriptaculous can still be used.

      Possibly a new annotation, @PrototypeSupport for components to ensure that the Prototype libraries are available for compatibility?

        Activity

        Howard M. Lewis Ship created issue -
        Hide
        Dan Adams added a comment -

        As a user who just completed a complex project with heavy javascript interaction, a number of new javascript classes, as well as extensions to the existing javascript classes I'm 100% against this. I think this is actually big enough that it breaks T5's promise of backwards compatibility. For applications like the one I'm talking about, javascript is a core part of the application just like the Java APIs and replacing prototype w/ jquery would be like replacing T5 IoC w/ spring. In fact, it's probably would actually be worse since the javascript stuff (especially ajax and anything in IE) is much harder to test than anything in the java layer. This may be a large enough change that it would mean the application could never be upgraded to T5.1 or above which would be a huge bummer and an indication of broken backwards compatibility.

        Show
        Dan Adams added a comment - As a user who just completed a complex project with heavy javascript interaction, a number of new javascript classes, as well as extensions to the existing javascript classes I'm 100% against this. I think this is actually big enough that it breaks T5's promise of backwards compatibility. For applications like the one I'm talking about, javascript is a core part of the application just like the Java APIs and replacing prototype w/ jquery would be like replacing T5 IoC w/ spring. In fact, it's probably would actually be worse since the javascript stuff (especially ajax and anything in IE) is much harder to test than anything in the java layer. This may be a large enough change that it would mean the application could never be upgraded to T5.1 or above which would be a huge bummer and an indication of broken backwards compatibility.
        Hide
        Robert Zeigler added a comment -

        I'm with Dan. This is a major change. The @PrototypeSupport is a nice idea, except that it requires more than minor amounts of work for authors of complex applications; backwards compatibility, to me, means that if I absolutely have to make changes, those changes should take less than 30 minutes for a single developer to make for a complex app. For example, I recently upgraded a dependency in a complex application from cayenne 2.0.4 to cayenne 3.0M5. Although the change resulted in various "deprecated" warnings, the application still functioned correctly without any further changes on my part, meaning that I could fix the warnings at my leisure. So if we were going to change the default js library, the change /has/ to be done in such a way as to make the burden of the change shouldered by tapestry, and not the end-developer. I think @PrototypeSupport is an /interesting/ idea, but it's one that requires too high an "activation energy": too much effort. If you're going to make the change, then I think that you should spend time developing a tapestry js api into which various framework can be plugged. This idea has been proposed before; I never much cared for it; more cruft on top of cruft. But if you want to switch the default js library to jquery, then this is the way to go. That way, previously written applications can override the default library contributions and contribute prototype, instead. There could even be a small "t5prototype" library that does this contributing for you, so all you have to do as a user to maintain the previous behavior is include the extra dependency. That's my $0.02.

        Show
        Robert Zeigler added a comment - I'm with Dan. This is a major change. The @PrototypeSupport is a nice idea, except that it requires more than minor amounts of work for authors of complex applications; backwards compatibility, to me, means that if I absolutely have to make changes, those changes should take less than 30 minutes for a single developer to make for a complex app. For example, I recently upgraded a dependency in a complex application from cayenne 2.0.4 to cayenne 3.0M5. Although the change resulted in various "deprecated" warnings, the application still functioned correctly without any further changes on my part, meaning that I could fix the warnings at my leisure. So if we were going to change the default js library, the change /has/ to be done in such a way as to make the burden of the change shouldered by tapestry, and not the end-developer. I think @PrototypeSupport is an /interesting/ idea, but it's one that requires too high an "activation energy": too much effort. If you're going to make the change, then I think that you should spend time developing a tapestry js api into which various framework can be plugged. This idea has been proposed before; I never much cared for it; more cruft on top of cruft. But if you want to switch the default js library to jquery, then this is the way to go. That way, previously written applications can override the default library contributions and contribute prototype, instead. There could even be a small "t5prototype" library that does this contributing for you, so all you have to do as a user to maintain the previous behavior is include the extra dependency. That's my $0.02.
        Hide
        Martin Strand added a comment -

        I would love to see jQuery instead of Prototype, we use jQuery for our .NET apps so we have a lot of jQuery code already. Not that it's difficult to "port" code between the two, but it would be nice to reuse the exact same components without having to load two rather large js libraries on a T5 page.
        It also feels like jQuery is more widely used, with a huge number of plugins available.

        However, as Dan points out, such a switch could break the promise of backwards compatibility.

        Show
        Martin Strand added a comment - I would love to see jQuery instead of Prototype, we use jQuery for our .NET apps so we have a lot of jQuery code already. Not that it's difficult to "port" code between the two, but it would be nice to reuse the exact same components without having to load two rather large js libraries on a T5 page. It also feels like jQuery is more widely used, with a huge number of plugins available. However, as Dan points out, such a switch could break the promise of backwards compatibility.
        Hide
        Dan Adams added a comment -

        It may be worth noting that my objection has nothing to do with whether or not I like jquery. I actually like it quite a bit.

        Show
        Dan Adams added a comment - It may be worth noting that my objection has nothing to do with whether or not I like jquery. I actually like it quite a bit.
        Hide
        Howard M. Lewis Ship added a comment -

        Excellent points all. This looks like it needs to be tabled until we have the ability to support multiple different JavaScript stacks, and a lot more besides, as we need a way for components to request diffrerent JavaScript stacks. Looks like staying with Prototype is the right way for now.

        Show
        Howard M. Lewis Ship added a comment - Excellent points all. This looks like it needs to be tabled until we have the ability to support multiple different JavaScript stacks, and a lot more besides, as we need a way for components to request diffrerent JavaScript stacks. Looks like staying with Prototype is the right way for now.
        Hide
        Igor Drobiazko added a comment -

        I think the switch from Prototype to jQuery is the worst thing we can do for Tapestry now. I have spoken to a lot of people who are raising concerns about Tapestry's back compatibility. Usually this is the only reason not to use Tapestry. Tapestry has to restore the developers' confidence. Some time ago a decision (for using Prototype) was made, now we have to live with it.

        Show
        Igor Drobiazko added a comment - I think the switch from Prototype to jQuery is the worst thing we can do for Tapestry now. I have spoken to a lot of people who are raising concerns about Tapestry's back compatibility. Usually this is the only reason not to use Tapestry. Tapestry has to restore the developers' confidence. Some time ago a decision (for using Prototype) was made, now we have to live with it.
        Hide
        Joost Schouten added a comment -

        A switch would mean a lot of work on a few project for me too. So a switch would not get my vote. One thing that I would find interesting is to change the tapestry.js, and some of the other included *.js files into an thin interface like wrapper that does not rely on any framework. Then pull out all javascript into a seperate module and contribute the javascript module of your choice.

        This way nothing needs to change from the way it currently works with prototype (assuming prototype as the default), but it does allow to "plug in" any other framework, like jQuery or MooTools. Martin Reurings actually proposed a similair solution back in 2007

        http://mail-archives.apache.org/mod_mbox/tapestry-dev/200710.mbox/%3COF6624565C.DAD9BA14-ONC1257369.00426459-C1257369.0044067F@porsche.co.at%3E

        Cheers,
        Joost

        Show
        Joost Schouten added a comment - A switch would mean a lot of work on a few project for me too. So a switch would not get my vote. One thing that I would find interesting is to change the tapestry.js, and some of the other included *.js files into an thin interface like wrapper that does not rely on any framework. Then pull out all javascript into a seperate module and contribute the javascript module of your choice. This way nothing needs to change from the way it currently works with prototype (assuming prototype as the default), but it does allow to "plug in" any other framework, like jQuery or MooTools. Martin Reurings actually proposed a similair solution back in 2007 http://mail-archives.apache.org/mod_mbox/tapestry-dev/200710.mbox/%3COF6624565C.DAD9BA14-ONC1257369.00426459-C1257369.0044067F@porsche.co.at%3E Cheers, Joost
        Hide
        luna Guo added a comment -

        jQuery has thousands of plugins that i can use them easily without much javascript experience.I can't leave it .Even i've written some code using prototype,i have to include jQuery for using a lot of UI components.There's hundreds kb of javascript for a page.
        I think the javascript lib tapestry include must be small and a lot of UI can be find.I like jQuery's "Write Less, Do More".
        To use a small one,and never change it to another again.We don't want to lean/use so many javascript frameworks.

        Show
        luna Guo added a comment - jQuery has thousands of plugins that i can use them easily without much javascript experience.I can't leave it .Even i've written some code using prototype,i have to include jQuery for using a lot of UI components.There's hundreds kb of javascript for a page. I think the javascript lib tapestry include must be small and a lot of UI can be find.I like jQuery's "Write Less, Do More". To use a small one,and never change it to another again.We don't want to lean/use so many javascript frameworks.
        Hide
        Adrian added a comment - - edited

        +1 for a thin wrapper/interface approach allowing different javascript frameworks to be plugged in. jQuery is my preferred library but I don't agree in forcing people to switch from Prototype. Need to also stop Prototype taking ownership of the $ symbol, I shouldn't really have to write $j or j$ everywhere.

        Show
        Adrian added a comment - - edited +1 for a thin wrapper/interface approach allowing different javascript frameworks to be plugged in. jQuery is my preferred library but I don't agree in forcing people to switch from Prototype. Need to also stop Prototype taking ownership of the $ symbol, I shouldn't really have to write $j or j$ everywhere.
        Hide
        Fernando Racca added a comment - - edited

        Standing from the point of view that i prefer jQuery to prototype, i would like to see (Tapestry 5.2? ) a move into breaking down what the core web functionalities, from those that depend on Javascript, particularly any extensions, such as Prototype. But plain switching to jQuery is even worse.

        A web framework shouldn't be tied to specific javascript/effects library such as Prototype+Script.aculo.us

        By extracting out all the components that rely heavily on dynamic javascript behaviour into its own module, you divide and conquer. With a small layer of abstraction on the core functionalities when needed, and on top of it, allow people to use the javascript framework of their choice, and encourage more people to actually add support.

        I originally posted this message in the mailing list, and now i can see that there is some consensus about moving towards an abstraction layer.

        I back this comment from Kristian Marinkovic

        "this unique approach would give Tapestry 5 a competitive advantage over other web frameworks as it could support multiple javascript libraries."

        Show
        Fernando Racca added a comment - - edited Standing from the point of view that i prefer jQuery to prototype, i would like to see (Tapestry 5.2? ) a move into breaking down what the core web functionalities, from those that depend on Javascript, particularly any extensions, such as Prototype. But plain switching to jQuery is even worse. A web framework shouldn't be tied to specific javascript/effects library such as Prototype+Script.aculo.us By extracting out all the components that rely heavily on dynamic javascript behaviour into its own module, you divide and conquer. With a small layer of abstraction on the core functionalities when needed, and on top of it, allow people to use the javascript framework of their choice, and encourage more people to actually add support. I originally posted this message in the mailing list, and now i can see that there is some consensus about moving towards an abstraction layer. I back this comment from Kristian Marinkovic "this unique approach would give Tapestry 5 a competitive advantage over other web frameworks as it could support multiple javascript libraries."
        Hide
        Michal Buczko added a comment -

        The only thing that tapestry needs is stabilization. I'm developing my own application over 1 year in tapestry 5 with extensive use of javascript and it drives me really mad to re-implement parts of my javascripts each time when tapestry updates from 5.1.0.x to 5.1.0.x+1. And now I hear about switching from prototype to jquery!

        please decide here what the tapestry 5 is: stable framework for wide community or a never-ending-beta-toy for few developers. Even hardcore developer's patience has its limits. Changing the same thing 100 times because of minor updates starts to be irritating.

        There are lot of issues reported which are imho much more important than wasting time on swtiching from one js library to another. I would love to see tapestry described as a superb fast & stable tool, but let's be honest: who will use this framework for serious job if it changes constantly each month and number of jira tickets rises exponentially?

        Show
        Michal Buczko added a comment - The only thing that tapestry needs is stabilization. I'm developing my own application over 1 year in tapestry 5 with extensive use of javascript and it drives me really mad to re-implement parts of my javascripts each time when tapestry updates from 5.1.0.x to 5.1.0.x+1. And now I hear about switching from prototype to jquery! please decide here what the tapestry 5 is: stable framework for wide community or a never-ending-beta-toy for few developers. Even hardcore developer's patience has its limits. Changing the same thing 100 times because of minor updates starts to be irritating. There are lot of issues reported which are imho much more important than wasting time on swtiching from one js library to another. I would love to see tapestry described as a superb fast & stable tool, but let's be honest: who will use this framework for serious job if it changes constantly each month and number of jira tickets rises exponentially?
        Howard M. Lewis Ship made changes -
        Field Original Value New Value
        Comment [ There's no rationale for having Java developers dictating what Javascript framework front end developers should be using. Surely the way forward is to decouple the two to allow developers to plug in ANY framework they want into Tapestry.

        Prototype is not the best framework out there. I suspect Java developers only picked Prototype because it uses the word 'Class' which give them a warm fuzzy feeling. ]
        Hide
        Howard M. Lewis Ship added a comment -

        Being addressed as TAP5-999.

        Show
        Howard M. Lewis Ship added a comment - Being addressed as TAP5-999 .
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Assignee Howard M. Lewis Ship [ hlship ]
        Resolution Duplicate [ 3 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        888d 8h 50m 1 Howard M. Lewis Ship 08/Jul/11 02:03

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Howard M. Lewis Ship
          • Votes:
            22 Vote for this issue
            Watchers:
            21 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development