How many of you are using JavaScript for your whole stack?

I used all JS to build/maintain Zigpoll (https://www.zigpoll.com) and JQBX (https://www.jqbx.fm). So far there are no bottlenecks that have been uncovered. I started off as a frontend developer so sticking with JS throughout the whole stack gave me a lot of flexibility and less friction when it comes to building new features. Full stack looks something like this (if you're interested):

• React (Frontend, only if necessary. Vanilla JS for the homepages for instance).
• Express JS (Server)
• Utility Node scripts that run via CRON for maintenance and other misc tasks
• MongoDB (I use Atlas but you can get a lot of milage hosting your own instance).
• React Native for Mobile apps (we have an android and ios app for JQBX)

This keeps everything 100% in JS from the DB to the Server to the Browser. We haven't gotten to this point yet but it should make hiring decisions a bit easier as well since you can just hire JS specialists and forget about the BE / FE divide.

My background is on a ruby/rails stack, but for my current project, I've jumped in the deep end with full JS stack and have to learn everything pretty much from scratch:

• Next.js, with served Express
• Apollo GraphQL (server and client)
• Heroku mostly, and some DigitalOcean, because I generally don't want to manage infra myself

Next.js actually takes care of a lot of the boilerplate, and dealing with SSR, so it was somewhat easier than expected to get things done.

We do, next.js SSR react, nodejs backend made up of lambdas, api gateway and dynamo db, also working on a react native app so full stack es6 bitcompare.net

You are not likely to got any bottlenecks any time soon. Unless you're trying to do some ai or heavy number crunching, you'll be fine. I've worked at many companies that run node for hundreds of thousands of customers with no problem. If there is some crazy intense processing you have to do early in that locks the thread, you can delegate that work to another service written in whatever language is appropriate for the task.

That doesn't mean you won't have to think about how to architect your services as your demands increase just as you would if you were running in Java or C#. But you should just work with what is most ergonomic to you while you get your idea validated a-sap and making some cash-money😆.

I used an entire JS stack to build Pivalink (https://pivalink.com). I think the main reason I made that decision was because it was what I am most proficient with, so it allowed me to build out the MVP very quickly, but it's also a largely performant stack. With regards to your scaling and bottleneck question, I've also worked on a number of teams that built their entire product line in JS-only tech and they've always been able to scale it exponentially without issue. I think like with most technologies, if it's done right (i.e. with scaling in mind as you architect stuff initially), you shouldn't run into any real bottlenecks.

In terms of specifics for my personal stack, I used:

• React (For anything UI)
• ExpressJS / Node.js (for the server / microservices / lambas)
• MongoDB (for the database layer)

My background is in .NET, but for sideprojects I'm using Typescript on both ends and I love it. If you're not planning on doing heavy calculations or image processing it's perfect.

Node.js+Apollo server+React is probably the most frictionless way to implement React + SSR.. and you also can write end-to-end integration tests with this stack

Personally, Javascript gives me nightmares. Yes I know it is required on the frontend but if I can avoid it, I do. So I don't use nodejs at all. The closest I have got to loving JS is through vuejs. But the entire build system (npm/webpack and all that) still gives me nightmares. I use it but VERY unwillingly.

I use vuejs in the front and nodejs in the back.
I have past experience with very large scale system that was in node and it worked very well. The parts that were not in node where those that had to run heavy algorithms or that had rich ecosystem in other languages (hacking tools and frameworks that require os low-level access are more popular in phyton then in node)

I use Node.js/Express/GraphQL for backed, Angular for frontend, Cordova/Ionic for mobile, and MongoDB for the database.

So far, I've not run into any issues when scale and JavaScript. I think it is very possible to have a large scale JS SaaS. I've heard of a couple large companies using Node.js for high-scale products.

I have a few projects where pretty much all my code is javascript. My main stack today is:

• Postgres for database
• AWS for Infra manged by the Serverless framework
• Serverless Framework with Nodejs for backend
• React for frontend hosted in S3

It's so much easier to start and manage projects this way, a lot less boilerplate to do. For mobile, i also use React Native, so javascript all the way! :D

It does have some challenges like i had to learn AWS Cloudformation for the infrastructure and AWS has a lot of limitations that i pretty much learn to go around one by one.

One thing that is important to talk about is that i have a financial system in javascript that i had some challenges but nothing that it couldn't be fixed. Other than that, all my production projects are actually going great, including the financial one!

my entire stack at https://podshownotes.com is javascript. So far so good with me, haven't hit any issues that couldn't be solved with javascript

Thanks for asking the question, these answers are great 👍

I used to do everything in JS, too. First it was Backbone+Node, later React + Node. I've never seen a case where Node can't scale, though Java, Golang , Elixir or low level languages have a considerable edge.

The reasons I've moved away from Node are productivity and ease of reasoning about more complex code bases (TypeScript will help with the later, also)

I'm using React + Capacitor to make an iOS/Android/web app!

Vuejs for the front and nodejs express on backend. With few lambdas we at helpninja.com fully running on js stack

Do you use Knex.js and/or an ORM like Sequelize or Objection.js?

I read Netflix moved from Java to Node so they could scale with less hardware. Maybe someone else can confirm that. Netflix is responsible for ~40% of ALL Internet traffic.

My preference is also using Javascript whereever possible.

I use meteorjs for quick setup of my MVP's, like https://read15minsaday.com and https://meetingtasks.com.

I don't event need to think in 'Backend' and 'Frontend'. Just type all in Javascript, that's it.

Scalability is important but also don't to earyl optimization. Especially if you are an indie founder like most of us here, you should focus on validating your idea first.

If you have traction, you will have time (and even money!) to think about scalability.

Yes. I have a full stack framework I built myself that's backed by PostgreSQL database, queue workers, command line tools, webpack built in, and uses GraphQL with React server rendered and rehydrated on the frontend.

Js can definitely scale. I work for a company doing JS for its backend in a service that gets thousands of requests a day. Also there’s threading now, which helps.

You may have to throw up a load balancer and use some type of managed cluster eventually, but you’d probably have to do that anyway.

Also, as at least one person here mentioned, doing your app as serverlesly as possible (e.g. API Gateway, lambdas) helps to scale out of the box, but it's a completely different paradigm, and you can't really do a relational DB serverlessly. However, the serverless model does help a lot scaling your API layer.

If you're interested, Production Ready Serverless by Yan Cui is a great course in designing completely scalable, serverless systems. But again, it is a paradigm shift.

I use Next.js for the frontend and Express for the backend in combination with PostgreSQL. It is quite an easy stack to master and can do almost everything. npm just has a package for everything.

For hosting, I use DigitalOcean (Homepage, Referral Link). It is just a $10 instance but actually that is more than enough.

At work, we also use a full-stack JavaScript stack with Node.js in the backend (also using express) and in the frontend React.js.