> Because it's a graph database so it doesn't really fit naturally with SQL.

Interesting, but lacking in details. The trivial examples I see in posts like this always seem to map perfectly to SQL.

I agree, we should show more examples.

AQL was indeed inspired by XQuery. We made some user acceptant tests at the very start and used a version which was using keywords from SQL and a more descriptive approach with keywords from programming languages. At least our test users were mostly confused by a similar SQL-syntax but slightly different SQL sematic.

We talked to the JSONiq guys. They had a look as XQuery and AQL and made a similar decision.

https://www.arangodb.com/key-features#aql does a relatively good job explaining it. The examples are all fairly simple, in a real world app you have much more complicated queries and it's here where arango really shines imho. With SQL it's very easy to write inefficient queries by accident, whereas AQL is a lot more explicit.

they definitely don't. Search for "ᴜɴɪᴄᴏᴅᴇ ᴛᴇxᴛ" and you'll see the only matches are exactly that.

> I feel like there exists a market for getting start-ups launched on the right foot. Twelve weeks (480 hours) for $1,000,000 with a bonafide rockstar to get your concept not only up and running but well designed to be carried forward. Do you guys think people would pay that? If no, how much do you think people would spend?

I've been in this part of the market for a while (getting startups to launch). There are very few people who have that kind of money to drop on initial development, usually you're talking about 1/10 of that at most.

The companies that do have that kind of funds are not looking for an individual "rockstar", they're looking for a nice established company that gives them confidence and can be sued if things go wrong.

If they'd supported Firefox from the start everyone would be slating them for "crippling" Firefox, or they would have had a poor user experience that would turn a non trivial percentage of early adopters off the entire product. They cannot win here, it was a bug in FF, it is now fixed, presumably they'll stop blocking when the fix is more widely available.

They could have made the effort to make this work on firefox from the start, but someone decided the effort wasnt worth it.

The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works. Firefox is fast enough if you write code with it in mind.

...but hey, who cares about anything except chrome right? If someone visits play.google.com on an ipad and safari crashes screw them for not using android right?

Its Business Politics at play, not technical restrictions.

>The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works

Not really. And here's a list of arguments why it's okay to focus on one browser (at least at first):

1) It's in beta, so you want to get it right before focusing on making it work everywhere

2) Developing for multiple browsers adds overhead to developers. I imagine they like to utilise some experimental webkit features, which are either not available in Firefox/gecko

3) Related to 2), they would add a lot of overhead making sure the UI and UX is the same, using multiple vendor prefixes and workarounds for other things.

And just to point out,

>dont release product until it works

is probably the worst advice ever to give to people. You want people to actually test your application. You can never catch all the edge cases that can/will happen, in your mind, and sometimes your assumptions are wrong. This is a pretty basic concept or Lean UX etc.

I'm sure it's different for large projects, but for my own work, if I wait until the app is "finished" (or at least in a workable state) before working on cross-browser compatibility, I hate my life and want to die. YMMV, but I find that working on compatibility from the start is the way to go. That said, if there indeed is a big performance bug in Firefox, that would totally be a valid reason not to support it (for now).

My counter is that "fix it later" never comes. Unless business sees browser support affecting the numbers they will not allocate the time to fix it. Some dedicated developers might fix it by working over time but that's essentially free labor. It has to take a strong engineering department to say "we will not ship until it works".

It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products.

If you plan to support cross platform, do so from the start.

You can argue about feature parity and 'first user experiences' all you like, but practically speaking, if you don't support the target platforms from the start, you're dooming yourself to FOREVER have 1st class and 2nd class platforms.

You see this all the time in apps; flagship on iOS, rubbish half implemented android version that launches 6 months later and never always gets updates 3-6 later, broken, with bugs. Or vice versa.

I'm not in any way saying that you should to be cross platform, or what platforms people should support. That's a business decision each business has to make. ...but it's not a technical decision. Technically, if you know what platforms you support from the start, you can implement the product with that in mind.

I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms. I dare say, business people who make decisions but don't have to actually deal with the consequences of them.

I honestly feel for the Inbox team. I'm sure there a lot of really tedious days ahead of backporting and bugfixing ahead for them (if google decides to make firefox support a thing).

>It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products.

Maybe in GUI applications, but not so much in web browser applications.

>If you plan to support cross platform, do so from the start.

You are already close to automatically supporting all platforms. The point of "not supporting" a browser, is to avoid tedious and time consuming testing of said browser, because CSS and JS works differently in every browser (although close to the same in webkit browsers like chrome and safari).

>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms.

Again, your arguments might apply to a OS application, but not to web browser "applications".

Generally, I also subscribe to the mindset of: make it right for one OS. Instead of: make it shit for all OSs, but usable.

Finally. Going out of your way to support platforms that _might_ be used, for an application that you don't really know if people will use in the first hand, is absolutely idiotic.

You need to know how, why and if people actually will use it, before spending time and money on supporting multiple platforms/browsers.

Just to finish of,

>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through...

I've literally only heard this from people that have never developed for multiple platforms, and expect that "once it works on X, it must work on Y". It just isn't so. Implementations, however neat, always differ in GUI-land.

If you put 'applications' in 'quotes' when you refer to websites, we are so far from being on the same wavelength its not even worth continuing the discussion.

I can only recommend you seek additional input from your immediate peers before writing your next web 'application'.

(hint: the considerable negative feedback re inbox not working in firefox is the kind of bad press companies would rather avoid)

*experimental Blink features

> The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works.

Except that almost no one does it nowdays. MVPs, early launches, etc. Why Google should be held to one standard while every "innovative startup" is held to a completely opposite?

By the way, did no one read what Google itself has to say about Inbox? It's explicitly stated as not a replacement for GMail. They're playing around with UX idea. You can look at it as a very elaborate A/B test.

If it had worked in Firefox and Chrome, but not on Internet Explorer, what should they have done? Think about that...

> Its Business Politics at play

Or alternatively it's economics. Maybe someone, somewhere had to make a decision similar to "If we want a good experience that includes Firefox users from day 1 it will cost $x and delay launch by y weeks". And he had to sell that to his boss.

Even in a company as awash with money as Google, someone has to justify budget choices.

This is an ancient lesson in software development. IIRC back in the early 1990s there was a beta build of Microsoft Office sent out to early adopters with full debugging turned on, and one of them wrote a newspaper review about how slow the new version was, despite the adopter being explicitly told it was a debug build and would be slower. "It's just to show off new features, not new speed."

In other words: performance is a feature. And thus, not wanting to ship a product with an important feature missing should be understandable.

Quite. Performance is definitely a feature of Google Inbox and it's very much appreciated. I think it's an excellent tool, and the rapidness of action responses is definitely a huge part of that.

There are equally valid technical reasons for using `new`, so it's dogma

> There are equally valid technical reasons for using `new`, so it's dogma

I really don't want to get into this argument but that's not what dogma means. Dogma is something that comes from an authority as being undeniable but saying you can't or shouldn't use new isn't undeniable, it's deniable as you said yourself there are valid reasons for using new.

and now I hate myself. Thanks.

damn, I've been using that word slightly incorrectly for years, and now I hate myself. Thanks.

Whoa a pleasant exchange on the internet. Yay.

In your example you have two "bugs", you're not capitalizing the constructor name and you're not using `new`. I would have to make two separate mistakes to reproduce the issue you're talking about.

The only way I'd make the first mistake is if I was unfamiliar with `your-class`'s API, so nothing can save me there.

JSHint would catch the second one.

Nitpick, on the nothing can save me there part. This is arguably a failure of `your-class`'s API.

A file exposing a class SHOULD either wrap it: `module.exports = function () { return new YourClass(); }` or use `if (!(this instanceof YourClass)) return new YourClass()` guards in the constructor to stop users of a class having to worry about whether or not to use new.

At least this seems to be the convention many module publishers seem to adhere to.

Yeah, but that falls under epediaman's "Stop over-engineering. YAGNI!" quote.

If you want the benefits of `new` without exposing your interface, you should totally wrap it.

But if you're going to have boilerplate like that for code that not's performance critical (and most of it is not), why not just go for Object.create() and returning the instance yourself. Less action at a distance.

note that this pattern will break subclassing:

    var Person = User.extend({});

    var person = Person();
    person instanceof Person; // false!
    person instanceof User; // true

The pattern didn't break subclassing there, your code did by not continuing the pattern and then not using new :)

Personally, I only use this pattern for cases where it's more convenient not to have to use new (e.g. building declarative APIs for defining things) and let 'use strict'; catch the rest.

this part here is supposed to solve the problem with people forgetting new:

    if (!(this instanceof User)) {
       return new User(name, lastname);
    }

I'm pointing out that this doesn't work if you extend the class.

The point is - don't forget `new` because tricks like this will not save you, in fact this is arguably worse - you think you're getting a `Person` but you get a `User` with no immediate errors, at least if you forget `new` then you'll get an error straight away in strict mode.

I've using Js for quite some time, and the behavior of prototype chain and instanceof always give me headache when I'm trying to do simple inheritance...

For now, I'll keep using `_.create` to do Inheritance. Of course it means another library to keep using and more verbose. But whatever...

    var Person = function(){ User.call(this) };

    Person.prototype = _.create(User.prototype, { 'constructor': Person });

    var p = new Person();

    p instanceof User //true
    p instanceof Person //true

If that's Backbone's extend, that can be fixed:

http://bl.ocks.org/insin/raw/db5f79d7d97ee6200245/

Works fine with npm "inherits" module. Not that you should be using instanceof anyways...

"Stop writing prescriptive articles about software development when you're speaking from a position of ignorance"

There are many reasons to keep on using `new`, the biggest one is probably performance, `new Foo` will always outperform `Object.create(FooProto)`.

Really though, this kind of article just grinds my gears. There are so few absolutes in software development, articles like:

    "You should always X"
  

    "Stop doing Y"

almost always really mean

    "I don't actually understand X or Y"

> the biggest one is probably performance, `new Foo` will always outperform `Object.create(FooProto)`.

He's right, `new` is more than 10x faster in Chrome and Firefox for me at least:

http://jsperf.com/create-new

Why would it `always outperform` though? Seems like an implementation detail. Object.create should be faster since it doesn't run a constructor.

The ever-wonderful Vyacheslav Egorov has a nice article on this:

http://mrale.ph/notes/constructor-vs-objectcreate.html

I bet this is because most of JS compilers are optimized in lower level for certain "popular" tasks, developers use to do.

`new Foo` will always outperform `Object.create(FooProto)`

If I create an interpreter that changes `new Foo` to `$new(Foo)` where $new is a JS function that uses Object.create to do what the `new` operator does in spec (e.g., treat it as syntactic sugar) then it's unlikely that `new Foo` would outperform `Object.create(FooProto)`. Just because the current interpreters are hyperfocusing on `new` doesn't mean they can't make `Object.create` faster in the future.

All requiring `new` does is add an implicit requirement that the name of your function is actually `new X` instead of `X` with the added requirement that all aliases of the function be prefixed with `new `, which is not composable.

Yeah, `new` might be faster than not using it right now, but that's a bug in the interpreters. And for a lot of objects, your inner loop is not going to be in creation.

Probably the problem with your perspective is that you're still thinking about JS "interpreters", when we don't generally have those any more - we have JITs that compile JS to machine code.

`new Foo()` is faster because it can be compiled to more efficient code today and probably always will be. Your argument is a bit like the "given a sufficiently intelligent compiler" one, I don't care about what JS engines of the future might do, I care about my code's performance today.

I find it odd that you rail against absolutes and then immediately turn around and defend your own.

If you meant that new is faster today, say so. That's not the same as "will always outperform".

I said there are few absolutes, not that there are no absolutes :)

`new Foo` has simpler semantics than `Object.create(FooProto)` and therefore I believe it will always be faster. That performance gap can of course narrow, but I think `new` will always be the fastest. Happy to be proved wrong.

Every time I hear how using 'new is bad' (or "considered harmful") in Java or Javascript it just makes me chuckle. Refactoring is not hard with half-decent toolchain so adding extra complexity/indirection doesn't improve anything.

In most languages, I would agree with you. Unfortunately, I haven't encountered a "half-decent toolchain" in JavaScript – or at least a toolchain that would help me reliably and fearlessly refactor big bases of code.

Performance isn't really a big concern unless you're creating several hundreds of thousands of new objects per second. And I would question why you need to do that in the first place...

Perhaps he should've taken the "Constructors considered harmful" approach?

Another point against advice like this is that you're going to be forced to use the supposedly "bad" technique when you interact with the rest of the world.

For instance, if you want to use any of Google's Javascript libraries like their map api client, you're going to be using "new". So, now you've done a bunch of work to avoid using "new" but as soon as you step outside of your bubble, you're going to have to find a way to deal with "new" anyway. So, what's the point? Just use a good linter and be done with it.

Yeah, and you also have to use Google's ugly name spacing and global scope pollution instead of modern (sane) module approaches like CommonJS.

Following an old-school technique just because you might see it in some legacy code doesn't seem like a great argument.

Because it's a graph database so it doesn't really fit naturally with SQL.

Competitors like OrientDB use something that's nearly SQL but not quite, and it's the discrepancies between the two that catch you out. Arango's query language is pretty nice when you get used to it.

The one criticism I have of Arango is that they're doing a lot of wheel reinvention with foxx, when I think they'd be a lot better off leveraging more of the node ecosystem.

phpnode is talking about a long discussion we had about that topic – if you are interested in the reasoning, read here: https://groups.google.com/forum/?hl=de#!searchin/arangodb/No...

Except this isn't him "cheating", this is his preferred coding style, for readability!

To avoid scrolling, which he says he hates.