3 ms·

> it is super easy to program with javascript. It would be more honest to say that the weird js design, its lack of features and ridiculously small stdlib made

> it is super easy to program with javascript. It would be more honest to say that the weird js design, its lack of features and ridiculously small stdlib made it harder to do anything complicated at the time (no ES6 or webpack, remember ?). Hence, not good tooling existed for relational databases: no decent abstraction layer, migration lib or ORM. Lost of languages had a 2 liner to pop an sqlite db without needing to install anything, but JS didn't even have that. So here you are, with thousands of front end devs that were just learning to declare their variable correctly, coming to the server. They had the choice between a technology that needed a lot of boiler plate to get anything done, and provided a painful experience with many early errors. Or something that just seemed to work out of the box. You just dump your thoughts in it. You don't need to think. No error back. It just says "ok". Seemed is, however, important here. The first years of mongo, it failed miserably, but you only saw it down the road of the projects using it. And of course the inexperience of the css wizards using it as a "dump-my-data" store prove to be a terrible curse. At the time, if you said any of those things, people would have called you an old grumpy looser that didn't want to live in the future. But they learned that, just like "var" was important to avoid bugs instead of using your variable whenever you felt like it, deciding of a formal schema was, even for document data store, an important thing to do. Fast forward, the JS community has now matured and include modern constructs, a rich ecosystem and people with way more experience. Mongo has changed its design and has now sweet spots use cases. But we still don't have good tooling for relational DB in JS. And it's still important to have an explicit document stating which schema you use for your document store. Schema less means you can do whatever you want. It doesn't mean, however, that you should.

kapv89 8y ago
True that Node.JS didn't have, and still doesn't have a 2 liner to pop an sqlite db. But what it did have(a few years after its launch) was a pure-JS sqlite client which can leverage V8's event loop and libuv to make parallel execution of db-queries a trivial operation. There is a lot of mettle in Node.js for server side programming. PS: have you looked at TypeORM(http://typeorm.io/ http://typeorm.io/)
- sametmax 8y ago
  NodeJS event loop is fantastic. However, it's not that relevant for most db workload. We had the same debate in Python: do we async our db libs or keep using threads ? Experts say: http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/ http://techspot.zzzeek.org/2015/02/15/asynchronous-python-an... And this is despite the way the Python community adopted libuv with the uvloop lib. TypeORM does look super nice, thanks. Does it handle well introspection ?

kapv89 8y ago

True that Node.JS didn't have, and still doesn't have a 2 liner to pop an sqlite db. But what it did have(a few years after its launch) was a pure-JS sqlite client which can leverage V8's event loop and libuv to make parallel execution of db-queries a trivial operation. There is a lot of mettle in Node.js for server side programming. PS: have you looked at TypeORM(http://typeorm.io/ http://typeorm.io/)

sametmax 8y ago
NodeJS event loop is fantastic. However, it's not that relevant for most db workload. We had the same debate in Python: do we async our db libs or keep using threads ? Experts say: http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/ http://techspot.zzzeek.org/2015/02/15/asynchronous-python-an... And this is despite the way the Python community adopted libuv with the uvloop lib. TypeORM does look super nice, thanks. Does it handle well introspection ?