GNU ease.js | Hacker News Reader

GNU ease.js

gnu.org

52 pointsconductor61 comments

I'd like to remind everyone that some GNU labeled projects are not financially supported or commissioned by GNU. They are instead supported by individuals who, for whatever reason, identify with the GNU label and have decided to donate their work to the cause.

The comments on this post are super negative, and I think that is because people really don't like the GNU project. We don't even know if the author of this library is the person who submitted it to HN.

I would be a nervous wreck if I woke up one day to find my personal work submitted to this site, and have it trashed as thoroughly as it has been here. You don't have to like it or use it for your next project, but for the love of God, don't call it a shitty ugly abomination (to combine some of the comments here...)

The comments are super negative because it's a useless and ugly library, most of these things can be done with vanilla javascript.

I love the GNU project, but this thing is ugly.

Well, so be it. I think the comments here are unnecessarily mean. YMMV. I didn't want to call anyone in particular, or I would have been more specific about what I thought was wrong with the criticism posted here. You can criticize the technical aspects and applicability of the library without being insulting.

> ... it's a useless and ugly library, most of these things can be done with vanilla javascript. ... but this thing is ugly.

Your criticism is that "most of these things can be done with vanilla JavaScript." Great. What is the point of the rest of your message? Keep in mind what you have written here is fairly tame compared to things that others have said in this topic.

When people complain about how hostile "Show HN" topics are, keep this topic and its replies in mind. Can't we be nice?

EDIT: This work was written by one developer, in what I am guessing is his free time. This would be different if it was a large project backed by a group of people/company. We might as well have selected a project at random from GitHub. I hope all of your work is up to snuff, lest someone submit it and beat it into a pulp on the front page of (probably) the most popular/influential tech aggregator in the world.

Comments can be mean, but most of these things are true, i really appreciate the work of this guy, and maybe (i hope not) there are people using his library, but if you see it from a (experienced) developer's point this library shouldn't be used. If someday i have to maintain an application that uses this library it will be a really pain. As i said, i love GNU, but this library is a wasted effort to do javascript "easier".

> most of these things are true

that is like, your opinion, man

I think your comments suck though.

(I am the author of GNU ease.js.)

Wow, quite the negative response here. That said, this is something I was wholly expecting from the JavaScript community, so I am not swayed; I'm merely providing something that I found to be useful in the hope that it is useful to others. So thank you to those who recognized that.

I feel that many of the negative statements here could have been addressed if the posters had taken the time to understand why the project exists:

  http://www.gnu.org/software/easejs/manual/About.html

The framework exists for those who wish to have the benefits of Classical OOP using JavaScript without the need for a compiler; it provides a standalone library for something many frameworks currently do, but do so incompletely: their own class systems. If there is a feature of ease.js that you do not like, you are not forced to use it; it simply generates prototypes. Language and paradigm flamewars will always exist, but let's be respectful of those who want to "program into" their language (as Steve McConnell put it).

Note that GNU ease.js was created when Harmony was just barely getting off the ground, and it is still not released. Even after it is released, there will still be users who do not have the newest features. Part of the reason for GNU ease.js is to address the issue of consistency across all browsers. It works in IE 5.5 (although that wasn't intentional)---you don't have to worry about whether or not ES6 is supported. ES6 also doesn't address some concepts ease.js does.

  http://www.gnu.org/software/easejs/manual/Implementation-Details.html

Let me be clear---I have a strong understanding of the prototypal model, and it does have its uses and elegance. For those who want some of the features of GNU ease.js without the framework itself, I provided both the above link and this paper which demonstrates how OOP is generally done in ECMAScript (and its problems):

  http://mikegerwitz.com/docs/coope.html

GNU ease.js encapsulates those hacks. There's value in that alone.

To answer some of the Harmony-related questions: here is a reply to a question I received from another GNU hacker:

  http://www.gnu.org/software/easejs/misc/easejs-harmony-reply.txt

With regards to the licensing: RMS asked if I'd be willing relicense under the GPLv3+, because of their campaign against proprietary JavaScript. Let me be clear on this matter as well: I am an avid free software activist. I hope that people will find GNU ease.js to be useful, but only if they are writing free software.

  http://www.gnu.org/software/easejs/whyfreejs.html

Thank you, conductor, for posting the project---I appreciate input from the community regardless of its tone.

Learning a language is about more than just the syntax, it's also about learning the idiomatic way to program in the language. This framework appears to hide the true prototype nature of JavaScript by bolting on a class-based structure, going against the language features the designers already gave JavaScript for things like inheritance.

Admittedly, JavaScript has suffered from a lack of strong idiomatic principles. (But that has improved in recent years with things projects like CommonJS, RequireJS and Browserify)

While I admire the effort that went into a project like this, I can't help but wonder whether it will delay a developer's understanding of JavaScript rather than ease the transition into it.

I have to agree... I didn't even get that far and think to myself, this is horribly ugly... Not to mention much of the sugar is buried in strings. You'd be better off going with TypeScript or CoffeeScript that at least have similar support, with linters/tools in place. This seems like a hack waiting for a large broken codebase.

Well......

The next version of JavaScript will have you know class. .. So I guess the javascript designers are going against the nature of JavaScript by bolting on a class-based structure going against the language features the designers already gave JavaScript for things like inheritance.

Good point.

However, if this was a shim for some future language feature it would probably be a good idea. It doesn't appear to be and if it was widely used, would only add to the confusion once language support for classes did emerge.

Furthermore it appears to put variable name declarations within strings, which might further confuse editors/IDEs that already have trouble with the dynamic nature of the language.

I really don't mean to belittle as I'm sure a lot of effort was put into this project. It may serve a purpose somewhere and someone may find it beneficial. I just feel that it goes against the language constructs a little bit too much.

ES6 classes are just syntatic sugar for the way people already build constructor/prototype objects.

it's not bolt on. "class" means something subtly other than what you think it does, in this context, following in the long loved javascript tradition of looking eerily like java's syntax while behaving in weird utterly surprising ways. (surprising to a java developer).

But you know, you guys WANTED "classes" so there you go. ;)

Please no more of these. They have the worst impact on javascript "ides". Most barely understand prototypes, and once you use class abstractions like this or ExtJS they simply are useless unless they have specific integration with it. It's not feasible to ask of tool writers to work with every class emulating library out there, and its a constant drag on having anywhere near useful javascript tooling.

If you want a shitty Java reimplementation wrapped in arcane syntax to prevent a JS parser from choking on it, check out this library.

And top it off with the most misleading name you could think of!

that you think its java like shows that you dont understand the library or java or both.

what language do you think it's like?

The author's paper on this: http://mikegerwitz.com/papers/coope/coope.pdf

I'm fairly new to JS, and I started watching the Crockford on Javascript videos. He really presented prototypical inheritance and using JS as it was "meant to be"(?) well, as opposed to trying to shove in classical inheritance. Even with my limited knowledge, ease.js doesn't seem to be a good way to use JS...

This is to be taken with a grain of salt, as I don't really view myself as that great of a developer (iOS, Android, PHP, Postgres, and all things frontend) but ease.js makes js even more weird.

People already have a hard enough time dealing with a pseudo functional async language. Trying to lay formal OOP concepts on top of JS is an abstraction for which I cannot find an analogy.

I think the project is incredibly cool though, as I've always found "meta" programming like this to be fascinating, but this causes a somewhat serious problem:

When someone needs to go into a formal JS framework, take angular for example, they really need to unlearn all of the other JS tendencies that were absorbed over time. Switching from jQuery thinking to Angular thinking is hard enough, but going from ease.js to Angular is a horrifying thought.

In every context that you would find JS (Web dev and game dev in Unity come to mind), it will look and perform absolutely NOTHING like this.

Why? Javascript isn't class based. Why not embrace the paradigm of the language you're using?

ES6 adds minimal JS classes, which I'm a fan of. They're just syntactic sugar over:

    Animal = function () {};
    Dog = function () {};
    Dog.prototype = Object.create(Animal);

But this? This is an abomination.

that's Object.create(Animal.prototype), and they do add a little more, like a working 'super', and getting the .constructor property right.

I'm not sure what this really adds, and as it's GPLv3 why anyone serious would use it for anything.

Ok, looking through...holy hell it's ugly. I've never really felt the need to use public/protected in JS, and it looks inspired by PHP.

Bolting this stuff on on top of JS, in such a broken feeling way...I just can't see why anyone would use this at all.

"as it's GPLv3 why anyone serious would use it for anything"

Serious people never set out to produce GPLv3 works?

I totally grant the "this doesn't look like it's actually useful", though, although I've not been neck deep in JS for ages.

Deleted comment

You definitely do distribute the HTML, CSS, Javascript, and content, by sending it to the browser, for any reasonable definition of distribute. What you don't distribute is any server-side code.

> "and it looks inspired by PHP."

You're getting the order wrong here.

- It was inspired by Java.

- PHP OOP was also inspired by Java.

It's hard to argue that Java's OOP model is bad. It encourages clear code structure and works especially well for large project (for tiny projects you don't need OOP at all, anyway). This is why C#, PHP, this library and many more are based on Java.

Oh, BTW, let's keep digging:

- Java's OOP was inspired by Objective C.

- Objective C was inspired by SmallTalk.

It's always Lisp or SmallTalk, isn't that fun?

To summarize: Let's take the one thing the js actually does well, rip it out because it's too hard and "alien," and replace it with a verbose Java-inspired syntax.

Wow. Could someone explain why Coffee script doesn't trigger this much negativity? Is it because it doesn't look like java? From where I sit it is the same idea and all of the flame here applies to it too. Just wanna keep the haters honest. I like how immediate and simple JavaScript is. I started my career with it 15 years ago and I'm not who these metalanguages and frameworks are tar getting, but it's becoming clear that as a JavaScript developer I'm going to have to learn these because those who prefer other languages are using these "adapter pattern" techniques on applications that I will inevitably have to maintain or fix. In that respect, I can certainly see how this trend can breed negativity.

Another desperate attempt to turn Javascript into something that it's not meant to be.

GNU says, "us, too!"

Yet another JS framework.

Why would you introduce that distinction into what is an inherently dynamic language? "virtual" keyword in C++ is an option to avoid paying the cost for a polymorphic call (so it can be inlined at compile time and/or no extra pointer dereference is done). It's a compromise to allow incremental cost of language features--but in JavaScript?

There are certain optimizations that I am able to perform by knowing if a function is virtual or not---this is especially important in the Trait implementation.

However, the original intent is based on compelling rationale from C#. I cannot find the original article where the article explains the rationale, but aside from optimization benefits and self-documenting code, he makes the point that virtual methods are essentially callbacks/hooks into existing code; you therefore need to put careful thought into how to handle those virtual methods properly and expose the proper APIs.

That's probably the one part that really didn't make sense. But maybe he did it for sport.

Curious about performance overhead... Not seeing the benefits of this over something like Resig's Simple Class Inheritance?

See the test cases in test/perf; they can be run with `make check` (or `make test`).

With a name like that I thought it was yet another easing plugin but this... this is something else. I have a hard time thinking of an application for myself. It's not something I would want to learn and I would not work on a project which uses it.

It it even possible to enforce 'access modifiers' and 'constants' in any real way in javascript? Is this much more than syntactic sugar or is it useful (despite it's... aesthetic issues?)

that's been possible for years.

Pull your understanding of what javascript is out of 2005.

Gross. It's also GPLv3, that seems a bit restrictive for a class system.

The what now?

How is GPLv3 restrictive for a "class system" whatever a "class system" is.

I would love it if the programming languages I use were GPLv3. As a developer that would give me a lot more freedom.

Yeah, Gross! GPLv3 is so restrictive – I hate free software licenses, it gives you too much freedom.

You do realise that GPLv3 grants the user less freedoms than a license like MIT, right?

No, the GPLv3 grants the user more freedoms than a license like MIT - they can demand the source from someone who has provided them the binary. It grants potential distributors fewer freedoms - they must provide sources and cannot distribute under incompatible licenses.

When I said "user" I meant "developer". Most of my open source code is licensed under the MIT license because it grants developers more freedoms than a GPL-like license would.

Also, I believe that by allowing distributors to use your code without forcing them to release their code you don't restrict potential users' freedoms - if a company wanted to use your library in their project and your license is not compatible with it they will just find another project or write a similar one themselves. The result for the user is the same: they will not get access to the code.

For "developer" it is substantially more true than it is for "user", to be sure. In principle, the power to demand the source gives me more freedom as a developer too - where with an MIT licensed executable I might not be able to find the code - but I'll readily admit that that aspect of it, when the author means the code to be distributed, is not terribly likely to be important when stuff lives on GitHub or even SourceForge or whatever.

As a developer, though, I'd rather have more code I can read and learn from and tweak and borrow than yet another proprietary product that I'll probably ignore - even if you're giving me 10x more of the latter.

In the world of GNU any mention of "freedom" refers to end users.

…because, in case someone hasn't noticed already, there are are more end users than programmers.

And frequently programmers are users as well!

The "freedom" that GPL gives is qualitatively no different than the notion of "freedom" in a free country. Freedom in a free country does not legally allow me to take away the freedom and rights enjoyed by another citizen. I can still do so, but that comes with legal consequences. GPL is likewise.

No I don't ... because the GNU GPLv3 guarantees, more than any other license, user freedom. The only other license that might guarantee more user freedom in this case is the the GNU AGPLv3. Sorry, but the MIT license does little more than protect a developer from being liable, it does almost nothing to promote freedom.

Well, frequently components intended to be used so broadly, and which become more valuable with more users (because more people speak the language) get weaker licenses. There are pros and cons to this from most perspectives, but it's a (weak) surprise.

Thanks for this - looks like its well thought out and executed.

With thousand and one problems in the GNU software ecosystem one wonders what they are doing in a completely unknown terrain releasing such a redundant and unnecessary JavaScript library.

Their motive is clear, they wanted a free javascript framework.

But it's not a framework. It's a framework as much as jQuery is.

Why not use TypeScript? It offers similar features, without the extra overhead and ugly syntax.

Because... err... umn... Micro$oft is the devil!

Seriously though, I don't care much for typescript either... I'm okay with CoffeeScript as it brings as much to the table without having to type twice as much to get it.

This just seems like a sick joke foisted on people who are too lazy to learn a slightly different paradigm.

God why is it so ugly. If they made it into a language that compiles into JS, it might be good, but why this?

And a bunch of people coming out of their caves to tell us how JavaScript's quickly cobbled up hacky prototype system is a design by God himself, and everything else is the Devil trying to trick us into his Java ways... Sigh.

Which is why the next versions of JS (ES6 and ES7) will have:

1) Modules (namespaces)

2) Classes

3) Member visibility

Whoops. Ignore the cognitive dissonance and continue with the flame!

Now. While the library linked here isn't the prettiest thing I've seen, I immediately get it. And I can immediately start coding in it and get the expected behavior.

This, in itself, is a huge feature compared to the awkward incantations one has to do in barebones JS to do OOP (of any kind). Even the fact it's string based doesn't make it inferior to some of the other unreadable stuff I've seen by people doing JavaScript "properly" (or so they think).

So, I say kudos about that. Here we have an implementation solving a practical problem in a practical way. No plot twists and surprises.

I prefer TypeScript, but this one doesn't require a parser, so it has its benefits.

I assume this message is aimed at me. I'm not worried about ES6. ES6 classes are just syntactic sugar over prototypes, so it'll still confuse the FUCK out of java, c#, c++ and flash developers, because they are still SEMANTICALLY weird and confusing to people used to classical inheritence.

So I'm happy about that. As long as Java developers are unhappy with something, I likes it.

The awkward incantations you speak of are indeed awkward, I will admit.

I mean, how fucking confusing is

    Object.create({ your prototype here });

am I right? This is much better:

    MySpecialFramework.extend({ my prototy.. .*ahem* class here! })

Reply on news.ycombinator.com