Some Good answer
Well, this is the kind of generic questions, which put you in bad mood! Still, I would like to give you an answer.
It depends!
It depends on a lot of factors. Size of the team, Complexity, cost involved and a lot more which vary based on the company!
For example, for a freelancer, who is familiar with PHP, he would prefer to go with PHP with any JS MVC Framework with Bootstrap/Foundation to cover mobile aspect!
See, as I said, it depends! Try to give out more information next time you ask a question!
2.
Well, it will depend on the values we want to deliver to the customers. Today, Single Page Web Application is on the rise because SPA eliminates page refreshing behaviors in the browser when the user navigates from one view to other views through performing actions on the page (e.g. click buttons, links, etc), which in turn delivers a desktop-like experience to the user.
A web SPA also opens an opportunity to the team to re-use the codebase by building it into hybrid mobile Android/iOS applications or even as a cross-platform desktop application that runs on Mac/Windows/Linux machines. This would help your team moving faster delivering your front-end solutions to your customers which use various devices.
Personally, I’d like to follow on this trend due to its advantages and the stacks that we can use to deliver this experiences are Angular.js, Angular 2 or Reactjs. As for building the web SPA into a desktop application, we could use Github Electron to achieve this. Ionic Framework v1, v2 or React Native can be chosen for producing a hybrid mobile application that runs on iOS & Android phones/tablets, from the webSPA’s codebase.
As for the backend App (API) development, personally, I’d like to use backend development stacks that could free me from setting up & maintaining servers/ containers either on the cloud or on-premise. Today, we do see such this stack: The Serverless framework. This framework will allow us to deploy our Web SPA files into AWS S3 Bucket and host it in there without requiring us to set up express, Apache, IIS servers (because AWS S3 Bucket can host static webpage & web SPA app now).
Also, the framework could help us simplifying our efforts deploying our Node.js Backend logic by hosting our logics on AWS Lambda. During the deployment, it also prepares endpoint routes to each of the deployed AWS Lambda functions, by defining them on AWS API Gateway. Thus, it freed us from setting up our own EC2 in AWS or setup Nginx Reverse proxy as our API Gateway. Serverless & AWS Lambda + API Gateway get our jobs done on this part.
3.
Backend/Frontend: Node.js, TypeScript + Babel, React + Redux, redux-saga, Immutable, Redis, Postgresql, Amazon Web Services (Elastic Beanstalk, Lambda, S3, SES, VPC, RDS, Elastic Cache, Route 53, CloudFront), web pack (only for lack of a better alternative)
Mobile: Probably React Native.
4.
Again and again, I see young developers asking the same question and making the same mistake.
Technology stack for businesses is like politics for engineers.
In other words – it doesn’t matter. Moreover, you can’t answer that question without more information about a project.
Business requirements, budget and a team experience first > tech stack second and never vice versa.
Only those questions will determine a tech stack:
- What project will you have?
- What architect, tech lead do you have?
- What team do you have?
- What technologies are they very good at?
- How easy and cheap it is to find a good engineer with that technology X in your region?
- What is a history of that technology, how stable it is?
- What is the future of that technology, is it reliable, will it exists after 10 years?
- What is your budget?
- How much time do you have?
- If your goal is to have fun, build own project and not a business, and you want to discover something new, then again, it doesn’t matter. Take whatever you don’t know and jump into it.
For mobile apps – native tools always should be used, i.e. Swift 3 for iOS and not hybrid crazy JS everywhere.
For back-end, I am using PHP7 because it was made for that simple use case and because I am working with it for almost ten years. For front-end, I am using vanilla JS (ES6 now) since it is a powerful and simple tool to script the browser and it is the only way to “speak to browser”. With a solid knowledge of these technologies, you can move mountains and you are always flexible, may add as many abstractions, frameworks, and libraries on top of it anytime.
