You can directly read the summary if you'd like to avoid the explanation,
I became a Vercel (formerly known as Zeit) fanboy and
someone who wanted to join their team somewhere around April 2019 when I first
discovered Zeit.co for app deployments and also found out
that most of what I used in terms of libraries and even tools were actually
built by them 1
And I've attempted writing to them a few times in terms of joining the team but
with no success of any response so I'm just going to assume it's a No,
getting back to the point.
Talking about the foundational framework of TillWhen and a lot of my web apps,
mini tools and also the reason I mentioned Vercel first. Vercel is responsible
for the Open source framework Next.js which is a SSG (Static Site Generator)
based on React much like Gatsby. The reason I picked Next.js was simple
yarn create next-app <app-name>)
These points aren't unique to Next.js anymore but then the newer frameworks
don't really offer anything significant to make me shift to them, If I had to
jump out of Next.js I'd jump to Nuxt which is for Vue and just use React as is
for other projects, I've given Gatsby a try but I guess I just prefer Next.js.
Well, I always say that you decide on tech stack based on intention of what you
are building and the target you wish to achieve while building it.
If the target is to learn, you're better off choosing a tech you haven't
used ever. This is how you understand where the tech prevails and where it's
going to be a bad option.
If you choose to build a quick prototype, you choose the tech you are most
familiar with, this can be a really old tech and probably obsolete at this point
but if you are just testing out an idea or working on seeing if the product is
going to gain any traction, you still use what you know has worked for you in
If you choose to build for production, you take the prototype or concrete
requirements and figure out and experiment with tech that was built for this
Eg: I built a static generator from scratch for my blog, doesn't mean I'd do
it for a client. I'll pick up a battle tested (Wordpress, Ghost, etc) to be my
base and hand them that, this can be a bit heavier but is a lot more stable in
the long run. On the other hand while doing this you also get ideas as to how
you can improve your own scratch built tools to fit more and more scenarios.
True, now the reason for that is most of what I build is to act as quick
prototypes of a certain idea that I had or something I wish to see and
re-implement just to understand what's going on in the code when a dev actually
built it and if I can improve it. Good examples of this are
Hen , Colors,
Pending, other mini tools that I've built over the years. I
do use each of them but they aren't unique concepts and just exist because
something from some app inspired me and I just wanted to get down and build a
clone to understand it and this is where it's fine to use a fallback default
stack, which in my case happens to be Next.js
The stack may differ for everyone. You might be a Angular + Phoenix or React +
Koa or a RoR + React/Angular monolith person, doesn't matter.
Let's take Hen into consideration here, it's a simple live preview for component
code written in React.
nnumber of imports that come with the added framework ? Nope.
I could build Hen with just vanilla JS or just React and that's more than
enough. As a matter of fact Hen is built with just React,
Hen Experimental on the other
hand is the repository that holds the unstable and testing code for the original
Live Preview attempt and was written in Next.js.
Point to take from this?
Prototype with a fallback stack and build/re-build it with the shortcomings
and advantages with a stack that finds a nice middle ground
You may or may not have to do this with every app you build but it's generally a
good idea to find out what the app requirements need , build a dummy version
with tech you are quick with, this can even use existing codebase from previous
projects etc etc etc, you get the idea.
Again, you might not have to switch the entire stack and as the experience grows
with various technologies you might not even have to build the prototype for a
certain set of functionalities, you just know what will work well and what won't
but to get there you'll have to experiment first and not take people's word for
it (conditional but generally helps to increase your own knowledge and build an
I used to have Hyper as my primary terminal,
pkg to create executable node binaries,
ms to handle millisecond formatting and
no I wasn't sponsored to say this, I actually did use all these libs a lot
back then and I had already tried next.js at this point but it was still not
production level as a few issues stopped me from using it for prod. Oh and
there was release and also I did get inspired by their design system a few
You can create a huge mess if you write long api paths and don't follow
entity based standard while writing routes. ↩︎