[mterrel]

My personal picks would be:

- React for the front end (https://reactjs.org)

- Node.js for your back end (https://nodejs.org)

- Deploy using Adapt, which ties your front and back end together using React-like components. (https://adaptjs.org).

- (Optional) If this project is larger or commercial, definitely use TypeScript on all 3 of the above (http://www.typescriptlang.org/)

[Disclosure: I'm a maintainer of Adapt, but a strong believer in the React model and ecosystem]

[jiofih]

> Use React’s declarative JSX syntax, JavaScript components, and a rich component library to build, deploy, and operate your <NodeService>

Im sorry but why would someone want to use a templating language to configure infrastructure? It’s like using CSS syntax for defining an HTTP API. Doable, but... why? It’s not any easier to pick up or reason about than any existing configuration language.

On React + node, this assumes no rendering on the server, plus you’ll need to pick your own state management solution, data layer, http framework, router, and a whole host of secondary tools, which will comprise about 96% of your actual development time.

[austincheney]

A template language suggests something that uses code points to inject dynamic values. JSX is a bit more than that in that it bundles a template plus the corresponding assigned logic. It is more of a component language than a template language.

At any rate the reason why somebody might want to do this is purely because its declarative. I prefer imperative programming myself, because I want to know exact what the logic is doing from reading the code, but many people don't think that way. Many people want to know what is happening without being overwhelmed by how its happening and they need the code to communicate to them in exactly that way.

[mterrel]

In my opinion, the power of the React/JSX model is really about allowing you to declaratively specify everything that can/should be specified that way. But then also allowing you to selectively use imperative constructs where they're needed, all while making it fairly seamless to move back and forth between the two at any level of abstraction.

Of course, with great power comes great responsibility...

[surfertas]

Why do you advise TypeScript as a definite for larger or commercial projects? Thank you very much.

[mterrel]

In a small project, it's pretty easy for one or two devs to mentally keep track of the codebase and also makes any refactoring fairly quick.

As a project gets larger (more code or more devs), each dev spends more and more time figuring out what the correct types need to be when using various internal APIs. Refactors get harder because it becomes harder to know whether you've correctly found and changed each place that was needed.

And although all projects have this to a certain degree, one typical goal of a commercial project is a higher quality bar for software while still optimizing amount of effort to get that quality. (And commercial projects are often larger too.)

TypeScript helps with these issues (and others). In my opinion, it increases developer productivity for all but the smallest JavaScript projects. It's a combination of both the static typing and the tools available that help the dev immediately, as opposed to waiting for a compile or test run.

I'm actually passionate enough about the topic that I have an old blog article about it: https://medium.com/hackernoon/3-reasons-why-we-use-typescrip...

[surfertas]

Thanks a lot for the response. I will take a look at your blog.

[nickthemagicman]

I have never been a big fan of javascript on the backend(or the frontend for that matter but we have no choice).

A 200 l.o.c. promise chain vs a 10 liner in Python or PHP or Ruby?

Just feels dirty to me.

[priomsrb]

You shouldn't need promise chains nowadays since async/await is available. Also, I'd be interested to see 200 lines of idiomatic JS being written in 10 lines of idiomatic Python, PHP or Ruby if you have an example.