ANNE Stack – Angular JS, Node, Neo4J and Express | Hacker News Reader

ANNE Stack – Angular JS, Node, Neo4J and Express

42id.com

34 pointssheldor33 comments

Mentally I've classified stacks into the same category as turn-key: not worth bothering with. ANNE might be a good choice for the types of problems you face, or your specific workflow. As for the rest of us? We probably have our own unique stacks.

The concept of stacks died alongside the last relevant stack: LAMP.

It is a nice article on Neo4J, but there is virtually nothing on why you would use node, express or angular. Most likely because practically anything else could take their place.

Yes.

Even if the stack is what you would use anyway, the stack could use different versions of the parts you would use.

Stacks were absolutely great back in the day, when getting getting all the moving parts required some legwork. I remember the LAMP installer for Windows - I was up-and-running and making a PHP app in minutes. One of the most usable pieces of software to come out of the open source community, it was great.

These days those moving parts are usually an "npm install", "go install" or "apt get" away. Meaning that this:

> different versions

Becomes significantly more important than having a single install bundle.

Eugh, Neo4J. Before you start using a graph database, ask yourself, what proportion of my queries are going to require complex graph traversals? If the answer isn't 'a metric shitton', then you might do better in choosing a more traditional datastore.

I could not disagree more. Neo4j has got to be the most intuitive, simplistic database structure on earth. The php client is amazingly optimized, even for super small datasets, it murders sql. The graph visiualizer is beautiful and extremely helpful. I might even argue that it has better documentation than SQL because it's all in one place with instructional videos and tutorials. If you live in silicon valley, you can go to their office for "office hours" and they give you pizza and beer and teach you how to use it. It so simple and easy to use a child could do it.

Simple and easy is not really what I'm looking for in a database. I mean sure those are nice, but they are orthogonal to the important issues, which I'll loosely classify as power. A lot of people flocked to MongoDB based on the promise of ease-of-use plus scalability, but then realized there's no free lunch, and actually learning SQL was a small price to pay for the power of modern RDBMSes. They partied hard with their schema-less designs, pushing code faster than anyone ever thought possible, right up until they learned the purpose and value of data integrity.

This is not to say that Neo4j is just an overhyped fad DB, but saying that the structure is "intuitive [and] simplistic" is not confidence inspiring.

Last time I used Neo4j in production with NodeJS we had only a few thousand nodes, and our heaviest query, which equated to a 2-table-join sql query, took up to 3 seconds to complete. We abandoned it and went with postgres...

I still have nightmares of the terrible, terrible RDF graph database we used at my last job.

We just used a godawful custom-written wrapper around Jena (we open-sourced it, and I thought about linking it, but I'm hesitant to tie this account to my real-life identity).

Oh, and we created our datastores by editing Google Sheets, because our wrapper around Jena also had the ability to parse Google Sheets as RDF stores. Eventually, we moved on to XLSX documents and finally to TTL, but we still did everything by hand.

I disagree, I've been dabbling with OrientDB (graph database) and found that while graph databases have its own set of complexities, at the end of the day, you get a bit more structure and depth with graph databases.

If you're structuring data with hierarchies, graph databases are highly dependable. Not that you can't do this with SQL it's just more difficult. Not to mention that relational databases have costly JOIN's which is not a thing for graph databases.

I'm convinced people are learning and inventing new components just so they can invent new stackronyms. I'm starting a new project using Angular, Node, and for some reason I can't quite put my finger on, a combination of Apache and Lighttpd.

edit: Actually, I realized this needs a storage component, and obviously that would be LevelDB, so I could lose Lighttpd, which was redundant anyway.

Ah yes, the ANAL stack. It's really nice, if you can talk your boss into allowing it.

said before, saying it again - I still like backbone + underscore templates better than AngularJS. When written using standard JS patterns I find that stack easier to work with, coupled with whatever (usually either Django or Loopback) on the backend.

tens of thousands of apps have been developed with Backbone,that's not an issue.But tens of thousands of app have been developed with jQuery only too,you understand what i'm getting to.

That people have managed well enough for years without monolithic frameworks?

then let's talk about management cost of these projects doing well enough.It's never good enough.

that doesn't mean its because of the chosen framework. i would love to see actual breakdowns of productivity on a similar project performed by a single team, once with angular once with Product B, by a dev team who is equally capable in Angular as they are Product B.

The difference between project A with angular and project A without angular is that project A team without angular would need to develop its own framework, its own coding style,conventions,... been there done that.

I would just say "framework" instead of Angular.

That said, it seems the real issues that frame works solve are those of teams who are unable or unwilling to establish their own set of coding standards and thus fall back on using some other team of dev's coding standards.

I'm not saying that's a bad thing - I'm all for frameworks on the backend, and like I said above, I'm for (loose) frameworks on the frontend (backbone + underscore).

I don't mind standards, but I'm against Angular becoming the standard because its not very good.

Hey can we not just make up stacks that spell things?

Believe it or not, each one of these components are choices you should make an independent educated decision about, and then make sure that those educated decisions integrate well. Integration with best-in-class solutions is A criterion, but not the only one.

Like, can you imagine someone using a stack like this to build a to-do list app, just because?

Also, what I'm seeing is someone lumping one of the best graph databases I've seen in with some utter schlock technologies just to force a catchy analogy to a separate anagram.

Node: yes

Express: yes

Neo4J: why not

Angular: rather not

Angular: meh

Express: no

Neo4J: rather not

Node: fuck no

My point: your opinion is exactly that... everyone has their own, and it's as useless as mine, in these comments, until you add some weight behind it.

And to you as well, why would you not recommend Node.js?

It's perhaps developers fault, but my company recently adapted node.js and usually when you rewrite an app it is much better than the older one, not in our case, the app crashes on average every 30min in production, looks like express comes with a monitor that restarts the app which implies that this happens often enough to warrant such program. We also had situation when the monitor just died and nothing was there to restart it.

This can happen, but it shouldn't happen. There is probably something wrong with your app.

It sounds like you guys are not handling errors well. One can write a broken server in any language. Node-restarting tools are purely for the use case usually covered by crashing threads in other languages- that of shit really going wrong.

How about explaining your reasoning to give it more credibility?

Not trolling, but I am rather curious. Why Angular: Why not ?

Angular 1.x is complicated and kludgy, IMO. It's not bad but it had a steep learning curve. Angular 2.0 should alleviate those problems. I've been using Aurelia a bit here and there and like it a lot. I think Aurelia's rigid, opinionated structure is clearer and succinct than Angular's more "framework" approach.

IMO angular is bloated and I absolutely despise using their weird template markup.

I understand people's distaste for Angular, but it often really is the best solution.

why angular? because once you understand the framework it's totally RAD. You can build complex applications in a matter of hours , and you don't even have to think about the app architecture , everything has to be in a certain place. AngularJS comes with a lot of battery included and for every task there is an angular module.

Why not angular ? hmm i'd say , the angular team fucked up with version 2.x announcement. I personally don't like this atScript/Typescript thing ,It's no longer safe to begin an angular project that will have to be maintained for years as devs don't really know if angular 1.x will still be maintained by Google 2,3,4,5 years from now.

With 1.x if you were into jQuery plugins, you could easily include them into any angular project which makes development really easy. You don't need to write classes or stuff like that, just write a function , put a bit of markup into the HTML and voila, you have a functional angularJS app.

I'm still using angularjs because it's just the best MVC framework out there.React isn't a framework but a view engine. React doesn't solve any architectural problem other than the view.

'React doesn't solve any architectural problem other than the view'

Fair enough. But, when coupled with a flux implementation (like Reflux) and a router (like React Router), what do you find missing in the React toolkit?

This is your brain. This is drugs. This is your brain on drugs.

Any questions?

Reply on news.ycombinator.com