Asked

Choosing a tech stack

Hello,

I have a product I want to build. It is going to be a stock image site to sell photographs.
I have begun to create an admin page with chunked image upload and it works great even if just very few features has been implemented so far. Basically just image upload, thumbnailing with watermarking, exif extraction, login and metadata forms about the images.

The last two months basically I have gone back and forth on what tech stack I should use for this site. Right now its written in Vue for frontend and node for the backend. I will probably switch over everything to nuxt for the main site anyway because I need good SEO for individual image pages.

The thing is, I have a lot of experience with javascript (years) and consider myself a very senior developer in that regard. I know its warts and to it I have used MongoDB for many years as well.

But lately I have been looking at a completely different language called Elixir and it's web framework Phoenix. I don't have a lot of experience with it but it comes with a bunch of pros for me for at least this project:

Pros:
  • It's very scalable and is server side generated with state only on the server (with liveview), so it is much less code to write.
  • Development speed should be faster, since it's less code and only one state.
  • SEO is for free, I don't need to do anything special since it's based on the old request->response mindset
  • PostgreSQL seems a lot better than MongoDB for the most part and it got a very good integration with Ecto which I have used and is very nice.
  • A lot of complicated stuff comes for free, like live image upload and authentication
  • If a process crash, it doesn't crash the entire app like in node (altough, one could use the cluster module etc to circumvent some of that). Elixir is simply a much more stable language.
Cons:
  • I have to learn a lot of new things. I need to learn the language, which I have begun to, I have to learn the framework and postgresql.
  • I feel like all my javascript knowledge gets "wasted" and since I do javsacript dev on my day job, I have to context switch.
  • There really is not a good way to create image thumbnails, although easily circumvented with calling a bash script or a python script etc.
  • Some easy stuff takes much longer to do since I am not used to the functional way of doing things, even if I see potential with it my knowledge is lacking.
  • I know all the warts and problems with javascript development and how to circumvent them. I don't know any warts of this new language so I will most likely fall in some common issues which I would not do doing javascript.
  • Creating a "SPA" probably gives the users a bit more first class web experience, perhaps.

The questions I want answered is:

  1. How do you choose a tech stack and what should I choose in this scenario?
  2. How do you keep focused on the product itself and not being such a nerd like me and get distracted by the implementation details?
The main issue I have is that the grass seems to always be greener somewhere else and I keep looking.

Thanls for your time and possible answers!

Best regards,
Markus

I love dogs, simplicity and transparency.


Building simple SaaS tools.

Use tech stack which you know already. If you start learning a new one, it will take you 3x more time to build your product.

Made many products. Failed always. But never gonna give up. 🤩🚀

I can only agree to that. In this early stage, the tech stack doesn't matter. So choose the one that you are familiar with.

Over the past 2 years, I tried many web frameworks/backends/tools/... until I came up with my current stack. It always took me weeks to really get going. Now I keep my stack because it literally takes ~10mins to have everything set up to start working on the actual idea. And I'm using this all the time. (just FYI: React/Redux + Snowpack + Tailwind + Firebase)

I read a tweet lately (couldn't find it) where a maker said that you should not care about the tech stack at the beginning. At this point in time, it is about product evaluation. When the product starts to grow (customer-wise), then you will have time to switch (and a good reason to do so).

That being said. It's always good to learn something new. Extend the horizon, and maybe see whether the other language helps you to achieve more. It's also fun and challenging. Even if your first site takes 3x longer (which it will). (Still, it might lead to frustration as you are not working on your actual product idea)

I love dogs, simplicity and transparency.

Thanks for the answers,

I guess you're right. My idea was only that it would be a bit tougher at first but that it would increase my productivity long-term since I don't have to build a SPA which is more complicated and time-consuming than only building a traditional backend app.

With liveview you would get a kind of hybrid that feels responsive as a SPA but with all the traditional web app building benefits.

I did a test like two months ago, and building a chunked image upload with vue took me several days but with Elixir it took me hours even with my inexperience. Maybe the comparison isn't fair though, since I built everything from scratch with vue/javascript but used a pre-built library for elixir.

Altough not perfect of course and other more simple things would take me much longer.

I'm a roboticist exploring web dev. Otherwise, I do improv, Jiu Jitsu, and podcasting.

I'm pretty new so take my opinion with more salt than usual.

I would optimize for the long-term. Maybe I'm reading too much into it, but it sounds like you're a little burned out of the stack you're using. I think it's important to work on things consistently, and you may make more progress using the stack that lets you work fastest, but you may get more burned out and then be less motivated to work on projects for a while afterwards. In the long-term, you may get less done.

If it were me, I'd try a minimal prototype in the new fancy language (and probably my best language for comparison). See how it feels and see if the advantages seem as large or as promising, and decide from there. From my perspective, this kills a few birds with one stone: you're less curious about the grass over there, you get to evaluate your new tech, and you may have a better idea about how to structure your implementation. That being said, it does cost time.

Hopefully this helps.

👋 Join WIP to participate