3 ms·

My personal picks would be: - React for the front end (https://reactjs.org https://reactjs.org) - Node.js for your back end (https://nodejs.org https://nodejs

My personal picks would be: - React for the front end (https://reactjs.org https://reactjs.org) - Node.js for your back end (https://nodejs.org https://nodejs.org) - Deploy using Adapt, which ties your front and back end together using React-like components. (https://adaptjs.org https://adaptjs.org). - (Optional) If this project is larger or commercial, definitely use TypeScript on all 3 of the above (http://www.typescriptlang.org/ http://www.typescriptlang.org/) [Disclosure: I'm a maintainer of Adapt, but a strong believer in the React model and ecosystem]

jiofih 7y ago
> 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 7y ago
  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 7y ago
    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...
nickthemagicman 7y ago
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 7y ago
  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.
surfertas 7y ago
Why do you advise TypeScript as a definite for larger or commercial projects? Thank you very much.
- mterrel 7y ago
  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-typescript-to-boost-dev-productivity-81044d72a57f https://medium.com/hackernoon/3-reasons-why-we-use-typescrip...
  - surfertas 7y ago
    Thanks a lot for the response. I will take a look at your blog.

jiofih 7y ago

> 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 7y ago
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 7y ago
  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...

nickthemagicman 7y ago

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 7y ago
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.

surfertas 7y ago

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

mterrel 7y ago
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-typescript-to-boost-dev-productivity-81044d72a57f https://medium.com/hackernoon/3-reasons-why-we-use-typescrip...
- surfertas 7y ago
  Thanks a lot for the response. I will take a look at your blog.