Hacker News Reader

Comment by volaski | Hacker News Reader

If the goal was to get more developers, I would just go with say.. Rails (or node, or even Java!) and pgsql. Why use all these hipster technologies? But who says it's because of the technology stack you're using? Maybe people are not motivated enough NOT because of the tech stack but because that's how it's supposed to be. That's a big and risky assumption thinking that you'll get more developers if you switch to react/flux/rethinkDB. Also, why is this the top priority when you're seriously considering quitting the project because you have no money? You should be either: 1. out there raising investment; 2. Get more users to use your product so you can raise investment; 3. Actually generate revenue so you don't need investment.

View on HN

I started a project the other day, started writing the basis for an isomorphic/universal/whatever it is now app (all the app starters out there are miserable), spent two days on it...eventually realized that trying it is going to slow me the hell down and make sure I quit my project before I even start.

You can fix legacy later when it's time. And let's be honest, there are proven, good web applications out there using <that stack you're used to> that are in reality no worse than node/whatever, just not as hip.

I love react for the pure frontend and I'm still using it there for many pages (except the ones I want to just be static), but I'm sticking to my python roots for a backend and I'm 100x more productive.

Hey check this out:

https://github.com/tylerkahn/isomorphic-es6-react-martyjs-to...

This may help you out. I created this after also struggling to find a good isomorphic example app.

Two huge things I think they're all missing:

1. Some sort of backend DB integration. It's very hard to figure out how people are interacting with NodeJS databases other than MongoDB these days, frontend alone isn't the issue. Sequelize + postgres for example would be great to get an app up and running I expect, including things like connection pooling. (Bookshelf seems okay too, but I don't like it purely because it seems to automatically infer attributes from the database, which makes coding harder as you'll need to hit the REPL or schema to know what's coming out). In addition, webpack is easy to get running. Making it sane from a module size perspective (dead code elimination...etc) is harder.

2. Test coverage. Unit + integration. There's a million test runners, mock frameworks, etc etc out there. It's not trivial to get something you know is sane working (more so from integration side). Not to mention new-style imports entirely break most frameworks like rewire in my experience, so I wouldn't encourage their usage.

And, well, for me I KNOW those answers for python (I haven't done that much nodejs backend work since ~2013. I've used the node ecosystem exclusively for frontend since, a lot), so it's a lot more simple for me to get started.

The model I was shooting for was having your API be an independent HTTP rest service (whatever framework/language you want) with the nodejs server consuming it to render the initial view and then the client also consuming it in order to carry on with execution.

Martyjs (and the marry-express module) makes this very easy to do in that you can write your application without having to consider the context in which it is running (server or client).

I think the backend DB integration is a separate concern from how to build isomorphic js apps.

In terms of test coverage I don't have much experience testing js apps so I can't speak to the pain points there.

Yeah, I think that's a reasonable model where it will make sense since the client/backend can actually be more or less identical, since they'd both just be consuming REST.

But that's a pretty painful way to start a project as well. /shrug

Check this out for frontend in python: https://github.com/zoofIO/flexx

Reply on news.ycombinator.com