DEV Community

Cover image for Choosing a tech stack for your startup?
guledali
guledali

Posted on

Choosing a tech stack for your startup?

If you could choose a dream tech stack to work with for your startup. What would that be and your motives behind it?

Top comments (9)

Collapse
 
itsjzt profile image
Saurabh Sharma

Frontend:

  • svelte/react.js
  • static typed language reason Ml (typescript would be fine but I love pipeline operator)
  • not server side rendered (they cause a whole array of bugs that can't be found elsewhere)
  • auth without backend setting cookie for you.
Collapse
 
devpato profile image
Pato

Did you know the creators of react are pushing heavily non server side rendering this year with React?

Collapse
 
itsjzt profile image
Saurabh Sharma • Edited

Oh, that's great.

next.js is good but

  • 2 ways of accessing cookie,
  • http only cookie problem
  • fetching in isomorphic way is hard, ex: if you call from front end cookies are included but that's not the case with calling from server you need to pass cookies manually
  • if something fails hard to add a debugger like you used to in normal react / node codebase.

tl;dr SSR have lot of edge cases

Collapse
 
sansseryph profile image
Kyla • Edited

Granted that I'm still newer in the Web Dev part of my career, but PRVN has been working really well at the consulting agency I'm at:

P - Postgres
R - Rails
V - Vue
N - NGINX

The motive is to work with a stack that's fun to work with and works well. I've worked in a few languages in other parts of my career but nothing has made me as happy as Rails has. :)

Collapse
 
guledali profile image
guledali • Edited

My type of stack! Ruby programming was made for programmer happiness

Collapse
 
sansseryph profile image
Kyla

Indeed! And not only does Ruby/Rails make me happy, but the community of people around those tools have been incredibly welcoming and uplifting! That was (and still is) an important factor when I was trying to pick a direction I wanted to go with my personal career in web dev.

Collapse
 
deciduously profile image
Ben Lovy • Edited

C++ and JavaScript. Both have massive ecosystems and massive talent pools, and both have proven themselves on a variety of workloads and scales and will continue to dominate in the industry for the foreseeable future.

Or, if I already had a handful of smart, dedicated folks who knew the language and were expected to stick around a long time, Common Lisp.

Collapse
 
guledali profile image
guledali • Edited

In my case it would have been Elm and in the backend. I probably would have with some kind of service like firebase and cloud functions. My motives behind this tech stack is hiring people of all level and people of a different background. What's nice about Elm is very few people actually know it which is great and firebase and cloud functions is an "easier" approach for backend.

It would be amazing if there was a ruby on rails as service, Iike the relational database, restful architecture and many other feature rails gives. I think firebase is the most mature in this area and I'm aware of AWS Amplify, yeah and maybe a bit of graphql in there. If I ever have plans of scaling this thing.

Having an easier architecture is really important for me, when you have complex system what ends having you suddenly need more techy folk to maintain your system like senior engineering and I'm bit fed up with that.

Also Elm is language, if you go with something like react or vue.js. The chances are 5-10 years from now you may have to rewrite your entire codebase to something else, you would have to do some rewritten any way.

Collapse
 
kendru profile image
Andrew Meredith

I would use Go on the back-end and ClojureScript on the front-end. As much as Go is not my favourite language to write, I am productive in in, and it is great for the kind of quick and dirty code that you need to be a fast-moving startup (although it cleans up nicely as well). I would choose ClojureScript for the front-end because - even though I have a lot of experience writing JS - ClojureScript is still more productive, and it gives me things like immutable data and an opinionated functional paradigm by default, so there are fewer unimportant design decisions to make. JavaScript, on the other hand, leaves to many questions open: how will I build this code? what babel plugins will I use? what UI framework should I use? should I write in an object-oriented or functional style?