Mootools Prime

[adidi]

Can we get any news about the long awaited "prime" (mootools 2.0) ?
As I understand it will work with conjunction to Node.js mode of work ?

Is there any timeframe ? something to read besides github(which is empty in description)

[Arian Stolwijk]

You can read documentation here: https://github.com/mootools/prime/blob/master/doc/prime.md

More links:

https://github.com/mootools/elements

https://github.com/mootools/wrapup

https://github.com/kamicane/moofx

https://github.com/kamicane/agent

https://github.com/kamicane/slick

https://github.com/arian/prime-util

https://github.com/arian/elements-util

https://github.com/arian/elements-ui

https://github.com/arian/wrapup-webbuilder

Basically the last step is create some kind of website, which is still a little todo (if you think you can do something about this, please ping us on IRC), before releasing any "official" betas.

You can also find all those packages on npm, which are tagged and usable.

All those packages are using commonjs modules, like node.js does. That means you can install and require them like any other node package on npm. Of course not all packages, like elements, work in node.js. To get those to work in the browser, wrapup is used to build a JS file that is usable in the browser.

[Lee]

Is 'prime' meant to replace MooTools?

Does this mean that dedevelopment of MooTools will stop in favour of
'prime', or will the two co-exist?

One other question: how interoperable is 'prime' intended to be with the
ubiquitous (and imo ugly) jQuery?

TIA

Lee

[Arian Stolwijk]

Currently the MooTools Project consists mainly of MooTools-Core and MooTools-More. Basically two projects under the MooTools umbrella by MooTools developers. It just happens that more depends on core.

Prime and friends will be added to this, alongside mootools-core, to the MooTools Project. It just doesn't use mootools-core.

This means that it will not directly replace MooTools Core or MooTools More. To stop development of those projects would be bad because there isn't an easy upgrade path. Prime is basically an entire new project.

The reason we add new projects, instead of making a MooTools 2.0 that you can upgrade from, is that there are a few key concepts different, that wouldn't be possible using something like MooTools 1.x:

- Not extending natives (you can, if you want, with some extra code, but prime also provides a "chain" function).

- Doesn't "polute" the global object at all

- Uses commonjs/node modules

- Does not use Element.prototype, but uses a slim element wrapper

- Moofx is CSS3 transitions based, with JS fallback. This wouldn't fit in the Fx.* API.

Because of some of these features, like not extending natives, doesn't put anything in the global object, it can basically work fine with anything, and doesn't collide with other code, like jQuery, MooTools or Prototype. For example in some project I just use MooTools Core, which still works perfectly, together with moofx3 for animations.

--

[adidi]

When you say it will not polute the global scope u mean except for one or 2 objects which will have to be bind the window global no ?
like "exports"(which is nodejs reserve word) and "mootools" or "prime" ?

And about the commonjs/node modules - will you use also the bad practice imo of "require" ? which loads js dynamically ?

And one last question, the only hold back from the beta release is the site you mentioned in the previous post ? Do you have any dates for it ?

[Arian Stolwijk]

When you say it will not polute the global scope u mean except for one or 2 objects which will have to be bind the window global no ? 
like "exports"(which is nodejs reserve word) and "mootools" or "prime" ?

Short answer: no.

Slightly longer answer: depends how you convert the modules to the browser. Usually with wrapup or browserify. With wrapup you can choose to export to the global scope, or another object.

However if your main.js contains a domready, and that main.js requires everything else, you don't need any globals!

And one last question, the only hold back from the beta release is the site you mentioned in the previous post ? Do you have any dates for it ?

Once it's done.

--
 
 
 

[Lee]

Thanksfor the info. It's looking good, I hope it gets plenty of support.

On 23/01/2013 15:52, Arian Stolwijk wrote:
> Currently the MooTools Project consists mainly of MooTools-Core and
> MooTools-More. Basically two projects under the MooTools umbrella by
> MooTools developers. It just happens that more depends on core.
>
> Prime and friends will be added to this, alongside mootools-core, to
> the MooTools Project. It just doesn't use mootools-core.

> This means that it will *not* directly replace MooTools Core or

> <mailto:adi...@gmail.com> <mailto:adi...@gmail.com

> <mailto:adi...@gmail.com>>> wrote:
>
> Can we get any news about the long awaited "prime"
> (mootools 2.0) ?
> As I understand it will work with conjunction to Node.js
> mode of
> work ?
>
> Is there any timeframe ? something to read besides
> github(which is
> empty in description)
>
>
>
> --
>
>
>
>

> --
>
>
>

[dukeofgaming]

So, for making "classes", what is the ideal thing to use here?: prime or Class?

"prime" seems to supersede "Class", so in a sense, MooTools Prime seems to overthrow MooTools Core. The question now is who of these two mootools projects get the attention by the core developers?

[Pietro Gregorini]

Il giorno lunedì 21 gennaio 2013 19:58:39 UTC+1, Arian Stolwijk ha scritto:

Basically the last step is create some kind of website, which is still a little todo (if you think you can do something about this, please ping us on IRC), before releasing any "official" betas.

If you need some webdesign support for the new website, I could collaborate.

Let me know.

[pixel67]

link is broken on Prime website to download prime ?

[Sitthykun LY]

It works on Github

--
 
---
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 mootools-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Sitthykun LY
a little developer in the big world \o/
mobile: +85595 7788 39
skype: cityx9
twitter: sitthykun <http://twitter.com/sitthykun>
site: niyum.com

[Tony Brown]

Not for me, I can't clone it????

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "MooTools Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mootools-users/WplEUNMfjoY/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to mootools-user...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Sincerely, 

Tony Brown

twitter:   https://twitter.com/pixelBender67

 

[Arian Stolwijk]

http://mootools.net/test/prime/ is a WIP, so it's not ready yet, it needs some design love, further content and for download we want to use https://github.com/arian/wrapup-webbuilder

For now: "npm install prime" + wrapup (if you want to use it in a browser). Somewhere in this group I explained how you can get started.

--

[Arian Stolwijk]

git clone https://github.com/mootools/prime.git should work fine.

[Tony Brown]

Okay it just started working for me, thanks

I feel dumb, I was tweeting about prime this morning

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "MooTools Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mootools-users/WplEUNMfjoY/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to mootools-user...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tony Brown]

yep working now, don't know what happened but it was timing out a minute ago? and the link is broken on the site shouldn't you fix that>?

You received this message because you are subscribed to a topic in the Google Groups "MooTools Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mootools-users/WplEUNMfjoY/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to mootools-user...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Arian Stolwijk]

Which website are you referring to?

[Tony Brown]

It's the button on the left

http://mootools.net/test/prime/

[Tony Brown]

Oh I'm viewing on Chrome

[Sitthykun LY]

Ah!! Page not found.

[Arian Stolwijk]

Like I said, that is only a first test version that isn't finished yet.

Want it to be finished, send me a pull request :P https://github.com/arian/prime-website

[Tony Brown]

well you shouldn't have a download button on the site than? it looks bad when you are redirected to a 'page not found' page?

I love mootools so I don't want any more negativity than there already is, especially when I'm promoting the use of your work 

[Arian Stolwijk]

Because it's not ready, prototype, work in progress, whatever. I put it up there to show some people, see the /test/ thing in the URL?

So send me a pull request that changes this https://github.com/arian/prime-website/blob/master/pages/index.jade#L21 in something sensible :)

[Tony Brown]

Oh I see

[Tony Brown]

I suck at git lol

[Andree Christaldi]

Why doesn't mootools just go on a merge bonanza.

There's aloads of cool additions and bugfixes in the pull requests... why not, if there's no conflicts - cast a cursory glance of them and if they look okay.. just merge them.

If someone at some points finds out something is causing issues, then they can fix it and submit a pull request for it..   - Lets get development back on track.

Example of merge which should be done now: 

https://github.com/mootools/mootools-more/pull/1188

https://github.com/mootools/mootools-more/pull/1186

And so many more if you look through the pull requests..

I mean, if people take the time to add to Mootools and submit code - if it's added, then they may add more.. if nothing is added,when it's a bugfix . . . etc . . then they think, 'Whats the point?' 

[Aaron Newton]

So, a disclaimer before I answer this post. Years ago, I was a very active developer within the MooTools community. I wrote the majority of the plugins you see in MooTools More (originally found on my blog Clientcide). I wrote a book, I wrote the original docs for MooTools Core, I wrote the MooTorial, I blogged about MooTools a lot. But my life has changed and I'm doing other things and thus can no longer contribute as I did. I have a kid, a startup, and between those two I get about 5 hours of sleep and no free time for fun or hobbies. I'm happy, but MooTools is no longer something I have much time for. Such is life.

This disclaimer is here to hopefully make this next part sound less lame.

Why doesn't mootools just go on a merge bonanza.

Merging other people's code isn't something you just go push a button on github to do. 99% of the time the code isn't quite right. If it's a bug fix, you need to reproduce the bug the pull fixes so you can verify that the new code does indeed fix it. Most pull requests (including the two below) don't come with tests or docs changes (which only applies to new features), so what you get is a simple pull request that changes one line and supposedly fixes a problem but now you have to regress it to ensure that a) it does fix it and b) it doesn't break something else.

Much of MooTools has automated test coverage (though the test environment is a little tricky to get running - so much so that a long time ago I authored a Django app to do it for you: https://github.com/anutron/mootools-development - it's probably out of date now though) but not all of it has tests. Further, it's often the case that the bug fix is addressing something that the tests failed to cover anyway (otherwise it would have failed). And nevermind if the the bug fix is browser specific and fixes it for some browsers and breaks it for others.

Finally, MooTools has a code style and a standard of quality that the devs are beholden to ensure. All of this means that a pull request is often more of an example of how to fix a problem or add a feature that the devs have to then polish or rewrite, add docs for, add tests for, and then verify through testing. Being a committer makes these things your responsibility - sending us a bug fix (which the dev team DOES appreciate) is a wonderful contribution and gesture and the dev team doesn't expect everyone to follow the MooTools coding guidelines and to write docs and tests and stuff. 

So this is a long-winded way of explaining why it is that pull requests are not as simple as they seem.

Any contribution is a gift which is appreciated. But they often languish on github precisely because they are actually a lot of work.

Sadly, I no longer am able to do that work. This is why I've started encouraging people here; create a fork of the project and start pulling these things. Write the tests and the docs for the changes and prepare a release candidate. Make your own next version of MooTools and the next thing you know you'll be a MooTools committer.

-a

 

--

[Nathan White]

http://felixge.de/2013/03/11/the-pull-request-hack.html

[Sanford Whiteman]

> http://felixge.de/2013/03/11/the-pull-request-hack.html

Interesting post. It at first seems radical, but on further reading
Felix is clear that he means that quality, bug-free code is a
prerequisite for committer status -- and that status can still be
revoked. So while it's less despotic than the way some projects are
currently run, there are still those who make the rules and whose who
must obey them (I'm not saying this is a bad thing, just stating it).

As Aaron notes, there's a sticking point of code style and that, to
some degree, stands alone from code quality. It isn't a good idea to
bend code style just to get bug fixes in. If style rules are not
formally stated anywhere (and I mean a _lengthy_ explanation) I'd
hesitate to directly commit because I have my own approach to most
anything (beyond my love of ternary expressions, which I can suspend,
there are plenty of outright obsessions).

I would add that beyond code style and quality are wider project
traditions-cum-standards. I have recommended previously that people
look at the PHP Internals list so you can see that this major
open-source product emerges from a mixture of individual wins,
collaborative wins and bitter collaborative fails. We have run-ins
over the RFC voting process, the commenting process, pluralities and
majorities, you name it. And when it comes to features themselves, we
often debate what PHP "is," and what it "is not," and the verdict is
up to the oldest-timers and their choice can sound more like a grudge
than divine wisdom. (They are also due credit for so much of the
modern online experience, so this is not to take anything away from
them as they are -- or should be -- legends. Perhaps the fact that
youngsters respect Resig more than Rasmus forms part of the grudge.)

In this light, I point you to the most recent active issue on the
MooTools issue tracker. A user has noted that Core.Browser is broken
in one well-demonstrated mobile scenario. A core dev has said that
Core.Browser, which relies on navigator.userAgent, is deprecated
enough that it will not be updated; the implication is that neither a
pull request nor a self-commit would be allowed into the repo.
Won't-fixing a non-security bug in a deprecated module is definitely
sound. But what if we want to un-deprecate it at the same time that we
fix it? AFAIK, there is no community voting process for un-deprecating
a feature, so the idea of community committers is stopped in its
tracks by cases like this. Please understand that I see why the issue
was won't-fixed; I am just trying to broaden the discussion so that we
don't get too far ahead of ourselves with the new "UberOpenMoo" idea.
There are many, many rules and regs to think of.

-- S.

[piotr_cz]

How to use test Prime client-side?

- There are repositories with code out there.

- There is me having a bit of time to research which libraries to use for project and possibly sending some PRs.

But I just can't figure out how to use it without probably building it with Wrapup on Node first.