Hi Korbinian, On Tue, Sep 14, 2021 at 11:36 AM Korbinian Bachl < korbinian.ba...@whiskyworld.de> wrote:
> Hi, > > I've read the article about rails 7 and the way of its javascript multiple > times - yet I'm not 100% sure I understood everything - but for me it > sounds somehow awesome. You'll seem to end up getting a choice: > 3 choices to be exact. > > A, use rails as an api backend, meaning you can have your custom JS FE > framework you like like e.g. Angular, React and so on... > B, Turbo/Stimulus via an import-mapped Hotwire, meaning you seem to be > able to have encapsulated components that get made production ready on the > compile time and auto enable high dynamic pages - this will be the default > C, manual and classic kind of JS development and bundling via a bundler > you choose as rails chose the way to "embrace" JS development from its > version 5 on (https://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/) > - this was the "old" default > > > In any way of thinking about it I really do like the choices that get > offered here and the way the people behind rails try to adapt to reality. > Now, if I think about my own development today its very much different to > what I did when I started over 10 years ago to use wicket. > Nowadays you are often "forced" to use some kind of frontendtech and > wicket - at least to me - seems to be not flexible enough if you have to > use certain webcomponents or techniques. Wickets Ajax is great as long as > you stay in that "pure" usage mode but when you leave it... it gets kind of > unintuitive - at least for me. > When I had the need to create a connector piece of software (that also > needs an webinterface) a year ago I ended up using micronaut as the base. > It was awesome how fast I could do some REST and JSON APIs. When I then > needed a webfrontend I fast learned that wicket wouldnt be easy to use if > it would be even possible at all! > Why? Well, since its a connector for an SAP system it was necessary to use > the SAP stuff and thats supplied by webcomponents ( > https://sap.github.io/ui5-webcomponents/) - and if you want to have it > working dynamically you can use already ready react version (thats > maintained as well) or do all from scratch by yourself (obviously not > really possible). Of course wicket is still a webframework but shouldnt it > be easy to integrate it with todays JS flow? > > I mean if I look at the wicket 8 doc here ( > https://ci.apache.org/projects/wicket/guide/8.x/single.html#_an_example_of_integration_with_javascript > ) what I have to do to connect it to my custom JS is far away from beeing > intuitive or easy IMHO. > Even if I look at the JavascriptHeaderItem here > https://ci.apache.org/projects/wicket/apidocs/9.x/org/apache/wicket/markup/head/JavaScriptHeaderItem.html > then there is not even a way to prioritize it anyway - Nor how to handle it > if multiple components add some reference to the same JS sources (no, the > String id doesnt cut it enough). JS Versions? Or this jQuery nightmare? - > yep, I had this as well leading to disable the jQuery in wicket at all and > instead do it in the HTML template part as the version mismatch that might > occur could breake some things... I even faced situations where the > ordering of header items changed between compiles/ deploys. > > What really would be necessary IMHO is that you could have some global JS > variable in your wicket page where all necessary things like callback url, > possible functions etc. are propagated in the header before any (!) > headerItem is even used (so basically on line 1 after <head>) so that you > can simply pick up the config needed and dont require that > AbstractDefaultAjaxBehavior dance. I mean you can embedd a react app easy > on the page. The problem with wicket occurs the moment you need to "talk" > to the page by loading data, writing data etc. > > I love wicket for static and simple dynamic webapps and pages - it would > be cool if it could somehow embrace todays JS worklow anywhow. > >From what I've understood you know just some parts of Wicket and this makes you think some things are hard or even imposible. Have you considered using Wicket's mounted resource ? it is something similar to plain Servlet, but you have access to RequestCycle, Session and Application. Check http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/ for some examples and the "localized" resources at https://examples9x.wicket.apache.org/mappers/. You can even go one step further and use WicketStuff RestAnnotations ( https://github.com/wicketstuff/core/tree/master/wicketstuff-restannotations-parent) - an integration between Wicket and JAX-RS. This way your React/Angulat/Vue/... frontend could talk to the backend without dealing with Wicket.Ajax (and jQuery), which is a convenience for talking to Wicket behaviors/components (something you seem to not need anyway) for this use case. About positioning things in the <head> - have you heard of <wicket:header-items/> ( https://ci.apache.org/projects/wicket/guide/8.x/single.html#_header_contributors_positioning) ? But this won't be needed too if you make Ajax calls to mounted resources. And yes, Wicket is not a silver bullet that you should use for all types of applications! Whenever you have specific questons about Wicket please ask at us...@wicket.apache.org! We will try to help you or even recommend you another library/framework when Wicket is not the best solution! Martin > > my 2c > > > > > > ----- Ursprüngliche Mail ----- > > Von: "Andrea Del Bene" > > An: "dev" <dev@wicket.apache.org> > > Gesendet: Montag, 13. September 2021 13:15:29 > > Betreff: Re: Rails 7 features > > > Thanks Martijn! Could point out which features you consider "palatable" > for > > Wicket? Sorry but so far I hadn't the chance to read the article in > depth. > > > > On Thu, Sep 9, 2021 at 5:38 PM Martijn Dashorst > > wrote: > > > >> > >> > https://world.hey.com/dhh/rails-7-will-have-three-great-answers-to-javascript-in-2021-8d68191b > >> > >> Somehow I think that a couple of these features would be a great fit for > >> Wicket. > >> > >> But I don't know if they are easy or neigh impossible to implement. > >> > >> Martijn > >> > > > > > > -- > > Andrea Del Bene. > > Apache Wicket committer. >
