Hi Tor, I couldn't agree more, I think that some simplicty in DOM manipulations have been lost these past years.
-- Clément On Sunday, March 31, 2019 at 2:06:43 PM UTC+2, Tor wrote: > > Hi, > I'm a long time MooTools user who finally feel that I can start migration > from my MooTools based client-side code to ES6. > > I've had strong reasons in the past to use MooTools and if it was still > maintained I would keep using it and I haven't found a replacement that > works as well so I'm going to migrate to vanilla javascript and not rely on > a javascript library be that Angular, React, Vue, jQuery etc etc. > > I'm after the same kind of coding experience (and user experience) I've > had with MooTools so I'm basically just going to drop MooTools and fill the > void with ES6 classes and a few DOM manipulation helper classes that will > support method chaining without extending the Window, Body or Element > prototypes. I think I will do something similar with Array and Object. > > The first step was to update +100 or so classes that used the MooTools > Class functions into ES6 classes. This was very quick and to be honest I > could have written a program that would have done this for me. Now I simply > relied on a lot of query/replace. > > The second step was to replace every Thenable class with methods that > return Promises. This was very simple. I used the reset-able functionality > of Thenables but since my system uses mostly immutable objects it wasn't > hard to just always create new Promises when needed. > > The third thing I'm currently doing is replacing all Request calls with > the fetch API. I consider writing an adapter for the fetch API that looks > like the MooTools Request classes but I also don't want to introduce an > extra layer of abstraction if not needed. I won't be able to do simple > query/replace here so it will take a little longer to do it manually. I've > got about 200 calls to Request and most are with my own Request.REST class > but none of the calls have anything fancy going on so worst case scenario > is just rewriting them all with fetch syntax which won't take too long > really. > > The last (hopefully) thing that I need to do is replace all code that does > DOM manipulation. This is going to be the big problematic part of the job. > MooTools make DOM manipulation so simple in a way that javascript out of > the box simply does not. I don't want to extend the DOM in the future > though so I'm looking into the smallest possible framework that I can write > to 1) render elements and 2) hydrate html generated server-side. > > The reason I'm writing this is that I want to report that I so far haven't > bumped into any problems replacing MooTools with ES6 but I also haven't > gained much in doing so. I think that MooTools is extreamly underrated > these days and the only reason I'm doing this refactoring is to not get > stuck in old code as ECMAScript develops in the future. If there was a > stronger community around MooTools we could have written a thinner version > of MooTools that uses ES6 and I would have been first in line to use it. As > it stands I will most likely never use a framework that couples things as > strongly as I think React and Vue does. I want to have full control over > the data flow and how the DOM is updated with my own rendering code and > view and widget abstractions. > > / Tor > -- --- You received this message because you are subscribed to the Google Groups "MooTools Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
