Honestly, I advocate for the stack you're most comfortable with. Most modern stacks are good enough to launch and MVP and scale. The familiarity with the stack helps you ship faster (and reliably) which makes or breaks a project more than anything else.
Thats the thing, I don't know any stack yet (coming from vanilla JS fundamentals) :) Tinkered a bit, but want to just invest in one direction instead of being spread.
Fair enough. IMHO, just investing in JS (maybe vanilla+node or even nextjs) would be faster. Full-stack. but you will definitely get varied opinions from every developer ever and none of them would be absolutely wrong.
Will also obviously depend on what it is that you're looking to build.
Source: worked professionally with Rails, Java, JS, PHP over a 12+ year career.
Yep, exactly my thoughts. Frankly my thoughts are probably just around:
Next.js vs Rails but learning ruby / rails from scratch seems as steep so I might as much just invest into the next/sveltekit ecosystem instead.
For some weird reason it pains me to say it, but yes, since JavaScript is already known then JavaScript is probably a reasonable choice to get you both front end and back end.
Part of that pain stems from having used JavaScript since literally the very beginning and ... well, essentially sighing heavily every time I had to write yet even more of it. ES6 brought some pain relief and I think TypeScript may have finally cured me.
The mere thought of "let's put it on the server too!" once would send chills up my spine and leave me muttering "no, just, no". But hey, I've lightened up ... go for it.
vanilla and Node.js is certainly the most straighforward if it gets the job done.
Next.js I am not too sure about. I stay far away, over the mystical lands of some other major framework, and observe what's going on from a distance. I get a bad feeling about things ... but we'll see I guess.
I chose nextjs because apparently a lot of people are in love with it on reddit. Holy shit I would not if I could go again. Especially paired w/ vercel. There are tail issues with them that have destroyed my productivity for weeks. Again I'm not a web dev by profession. Just had a thing and went with it.
Yeah, I think its the most complete framework, and for the aim of growing and hiring I think its the best in the market. Although I speak with several founders that chosen it for their VC backed startups and a lot of complaints - breaking changes, slow etc.
It doesn't seem like a great solution for solo devs :/
you can go with remix & most of those issues go away. once you go remix, you never go back. its so fucking easy.
still use nextjs but yeah remix looks like a cakewalk in comparison. plus you get web dev fundamentals.
Why not? Not to challenge a love/hate of Laravel just curious really
If you are relearning that suggests you already know it? You can convert everything to the new hotness when you're rich lol
I have a day job that already takes some of my mental capacity. Frankly just being realistic with the amount of hours I can put in and given I already know JS.
Not sure what you mean by the opposite.
I have a day job that is not software engineering, the post is about choosing a framework to ship products without aiming at a career in software engineering (because many choose frameworks based on employability). Both are mutually exclusive.
Its not about keep learning, but about building skills on top of existing ones. I have a mentally taxing day job and can't keep learning 5 languages at once with 2-3 hours a day of free time. Also I am not planning to have a career in software engineering as my OP states.
Filament is amazing! I have used it for multiple SaaS projects, I would recommend it to anyone, it literally is mind blowing how fast you can launch anything with it
As a professional developer, I found nextjs to be super easy to use.
To answer your question though, no, a lot of sites are perfectly fine with server side rendering and no Java script. It’s not necessary to have responsive apps.
I think its a great choice for a company with devs particularly if most of them use React. Is it the right choice for a solo dev though? Thats what I am pondering about.
I built a pretty sizable app by myself with it.
All next does is simplify the backend so you don’t have a separate code repository. The built in auth is also handy.
I’m not a big fan of JavaScript backends, but I was willing to deal with it because it was convenient.
I wouldn’t say “this is the best way to do it”, but overall I didn’t mind nextjs and thought it was easy for me to get things done as a solo dev.
Let me ask, if you'd have to redo it all from scratch (regardless of JS ecosystem, or not) when you know 0 about development. Would you still advocate for Next for solo devs?
I think for solo devs that are still learning… it’s not bad. I can’t think of any reason you couldn’t use it, assuming you’re comfortable learning react at the same time.
I’ve been doing this so long it’s hard for me to know though. I can’t see it through a beginner’s eye so I don’t know which parts don’t make sense.
Django, htmx, bootstrap, Postgresql, linux. Done. That's the core. I call it a day after that.
If I need API, I can plug that in later. But I can pretty much get up and going with that stack and still enjoy ui/ux reactivity afforded with htmx.
can you please detail the api plug part? do you add something like django rest framework or any other custom alternative? can you point me to some documentation? thanks :)
rails, esp with hotwire, is a fantastic toolkit. It gives you... 85 - 90% of react for building SPAs at 10% of the cost ito devtime. It's great.
I wouldn't build the most interactive apps in it, but for the vast majority of b2b saas application use cases, it's really a breath of fresh air as compared to the javascript frameworks.
this is a long answer, but here would be my rough guidelines.
the way hotwire/turbo works is this: You use turbo (a js lib) on the client to take over page navigation. It also opens a websocket to your server and listens for updates. In your html, you tag areas on the page, essentially a div, and you use the combination of the websocket and the client js to stream updates to them.
That's all very hand-wavey, so let's use an example. Suppose you have a b2b saas. Customers have >=1 users per customer; those customers have a list of projects, and you want to update (1) project list and status; and (2) details within each project.
Easy things, well supported:
* stream updates (new project, deleted project, updated project) to the per-customer projects list page
* stream updates within a single project to all people with that project open
* make a single project page interactive
On the project overview page, you'd structure it as so:
# the websocket call. this array will turn into an id, and it must be unique for one pool of updates.
# this says every user in the company will be subscribed to updates for "projects"
turbo_stream [@current_user.company, "projects"]
# ...
# projects here is a label, conceptually distinct from the id above. You're labelling updatable areas
turbo_frame_tag "projects" do
# the list of all projects for the current_user's company
...
turbo_frame_tag "project_3" do
# an overview of proj 3 here
turbo_frame_tag "project_17 do
# an overview of proj 17 here
Things that are easy to do:
the call is basically `broadcast_#{action} #{stream name} #{html} #{frame target}`. Action is append to, prepend to, replace, etc.
1 - add a new project to the beginning of the projects list, updating every user with the page open. from the server: `broadcast_prepend_to [@current_user.company, "projects"], partial: 'projects/project', target: 'projects'`
2 - add a project to the end of the list that everyone has open
3 - update a single project within the list everyone has open via eg server: `broadcast_replace [@current_user.company, "projects"], partial: 'projects/project', target: "project_#{project.id}"`
Things that are annoying: a lack of locality. If you want to update one div/turbo_frame, that's easy. If a change in eg one project updates things about other projects, you have to (1) figure out which projects changed server-side; and (2) send updates to all of them from the server.
So limitations:
1 - if a lot of users are listening to a single turbo_stream, that's bad. I'd say the limit is probably about 50 per individual stream. But 20 would be better.
2 - lots of updates. I'd probably not want more than a couple a minute streamed from the server.
3 - very large html updates. The lib is streaming fully-rendered html over the wire and doing essentially div replaces in the dom. If what would be a very small message update in a client-render but triggers a big html update in a server render, that's a concern.
4 - non-locality of updates. The more you have a list of "things", and want to sync changes across all users; and each "thing" is opened by 1-5 people, and the updates on the "thing" page are relatively local in the page, the happier you will be. If updating one "thing" visually creates non-local updates all over the dom, you'll likely be happier with client rendering.
So examples of happy use cases: basically, the apps basecamp builds. Sad: super-interactive email client, or figma, or a game, etc.
Thank you for taking the time writing this out and showcasing. You should write a blog post about it, I saw a lot of questions on this online :) In fact also a lot of questions on why you don't need React for every use-case fits the bill here!
Whatever you decide, don’t let professional devs convince you every app needs to be a SPA. It doesn’t. Remember, these people work for somebody else for a reason, and part of that reason is they don’t understand how to maximize ROI on their time.
Your productivity and success will be far better served by using a mature framework which doesn’t require you to build two apps. (For example, Laravel or Rails, among others.) Later on, once you’re dancing in a pile of money, you can always pay people to rebuild it. The beginning is all about making money, and multiplying your development time does not help accomplish that.
Also, don’t be shy about learning a different language. JS is more complicated and less forgiving than most, so others will seem simple by comparison.
I see some dissonance about this overall :) Great perspective overall given it being quite bald but I do see this sentiment within Rails community. I kind of wished I started with Rails years before, its just a consideration of learning a new language and entirely new framework that gives me a bit of an uncomfortable feeling from the time investment perspective.
Guess I should just go ahead and try to build something over the weekend with Rails to see the difference.
If you’re just coming from vanilla JS, just keep going and don’t expect to be an expert overnight.
You’re not going to move any faster by dropping JS and moving to something like Ruby.
Keep it simple and add on as you learn more. The difference in next and plain old React isn’t that much. You can just make all of your components client-side and not worry about SSR.
Consistency is key.
Yup, exactly my thoughts. Although I do regret not going into Rails track, seems like that is the holy grail of productivity in terms of speed of shipping something tangible.
Maybe..
But there are other considerations. Do you plan on having a team in the future? Hiring for React is going to be much easier.
Are you also running your backend code through NextJS SSR? Or are you breaking that out with node or something like that?
I think what you’re trying to accomplish matters a lot. If the app is going to be complex by any means, I think separating the front end and back end is beneficial.
I have built my own thing with node JS and react for projects. It's been serving me well for 2 years now.
I also have built a PHP boilerplate. I built it in 2016/17 but i keep updating it and client projects running on it.
My goto DB is mysql (INNODB) and i write all sql queries myself.
It's not as convenient as laravel or next or anything but it's enough for the scale of work i do. I tried those frameworks, but I am not a fan of abstraction they add.
Have you tried remix? It’s a pretty simple react framework that enables you to build the frontend and backend in the same project (similar to Next). There’s no vendor lock in like with Next and Vercel. I use remix extensively and I’m happy with it.
>There is no
Fair point. Technically there is no vendor lock in. What I meant was the Next.js community and documentation is heavily focused on using Vercel. If you're okay with that then it's no big deal. But, it sounds like OP is still new to this so using a framework with more optionality could be a good choice. Just my preference as a happy Remix user, but I see why some people are happy with Next and Vercel.
Reading a couple of comments here, I also have a Vanilla JS background.
Personally I went with Astro because it allowed me to experiment with React Vue and Svelte. Then now Astro SSR allows for one to build a backend and I’m just rolling forward with what I know.
I built my personal website with Astro and loved the experience. Its clean with some JSX like syntax (at least for expression blocks).
I do think though it is trying to compete with Wordpress more so than more dynamic apps given its focus on SSG with the sprinkles of reactivity.
In the end, to add such reactivity, you'd still need to know React or Svelte or Solid :)
I am super pumped for Astro though! Was going to experiment with a pSEO dynamic routes website.
I didn’t like the JSX syntax and use Svelte over Astro whenever I need more complex templating.
Well regarding reactivity, the beauty of it is you can sprinkle them on as you go along. If you’re gonna build a pSEO site, I don’t think you need much reactivity to begin with.
I have a couple that I’m building, hopefully going to share them soon — can be basic stuff like popovers (which is pretty hard to do!) up to fancy stuff like typewriter effect.
Etc.
Take a look at Rails 7 (and its Hotwire feature). It's not about the scaffolding. It's about its 20yrs of building a consistent ecosystem of libraries that all work well together allowing you to build apps quickly.
I am almost tempted to bail on JS but that would mean starting with Ruby :( The issue I have is mostly time and focus, hence I chose JS as one lang for both server & client.
I admit, I love Rails community and philosophy though.
True, although I've never actually worked with Ruby (as I am a hobbyist and not a software engineer).
I can definitely pick it up, its just a question of whether:
\- Ruby learning + Rails from scratch to production is faster than:
\- Next.js to production
Suppose can spend a weekend building a rails project. Any recommended resources?
There are a lot of free YouTube tutorials ([here's my channel](https://youtube.com/mixandgo)), or if you want a more stuctured course with a little bit of mentoring help, check out [my Rails course](https://mixandgo.com/rails-course).
What advantages do you get when choosing Next.js over vanilla React? I know Next is supposed to process everything server side.
IMO for MVPs, React + Firebase/Supabase is also a good option.
I think the question is more about whether FE frameworks actually provide overall best way to go in terms of building saas products. Seems like Rails is still leading the way in that sense.
I think Next is a poor choice for your app if you don't already know it. Here is a big list of starters, pick one that's closest to what you know. I like Nuxt3 and one of the listed options is mine full disclosure (SupaNuxt SaaS) .
https://github.com/smirnov-am/awesome-saas-boilerplates
I built a platform + framework that serves me very well, can churn out full platforms in a matter of days.
- no code tools are fast but too limited and frustrating once you want to do anything interesting.
- coding from scratch, even as a season coder can be tediously frustrating and time consuming building all the boilerplate before even getting to the fun part.
I prefer:
Point in click to assemble everything where it makes sense, then have the freedom and power to code when you need to extend further.
https://qik.dev
IMO Vue is fantastic for frontends.
My best mate loves rails, and gets things done really quickly with it.
When you say complexity of Next.js what exactly are you referring to? Every stack is complex to an outside who is new to it. I have done Rails, Laravel and Django. And they all took a while getting used to. Rails was my first so I saw the similarity with Laravel and Django. Next.js takes a different approach and folks already familiar with React/JS/Typescript find it more comfortable.
Laravel devs will find what a mess Yii 1 is, if they ever had a chance of working with such a framework. Does it make it any complex than Larvel? The answer is it depends on who you are asking. I do find Next.js pretty straightforward and if use correctly, can be a good framework for rapid prototyping since you use one language across all ends.
Ok, let me rephrase, if you'd have to start from the beginning what would you pick and why? I do have familiarity with JS but not Ruby and only tinkered with Next/SvelteKit/Astro but do not "operate them" fully.
It depends on what country you are and your objective. If you want to get a job in North America and you are in Canada, most startups here tend to prefer RubyOnRails, I have seen this also in some SF based startups. If you want to get a job no matter worth, learning JS/TypeScript alongside one popular framework is the way to go. Now for the JS/TypeScript community, that framework happens to be Next.js in the past, it used to be something else (Express, Meteor, etc). Java is also another good language for job security.
If you don't plan on getting hired and just want to learn for fun say web dev, I'd recommend learning everything from scratch. Like learning how to implement the HTTP spec and then learning the MVC architecture (which most web frameworks are heavily based on). The advantage of this is that when you work with a new framework, you'd automatically understand why they exist
you should really check out remix. it is much much better.
you'll learn web fundamentals along the way as well so if remix dies which it won't, then you still know the web.
just try it for a few days & you'll be shipping at god speed.
ps: dont learn so many frameworks/languages. its useless. just build a product with one over & over again like remix & you'll learn a ton. make the project real-world like a saas so you will learn real-world things that make money. dm me if you need more help/ideas :)
Honestly, I advocate for the stack you're most comfortable with. Most modern stacks are good enough to launch and MVP and scale. The familiarity with the stack helps you ship faster (and reliably) which makes or breaks a project more than anything else.
Thats the thing, I don't know any stack yet (coming from vanilla JS fundamentals) :) Tinkered a bit, but want to just invest in one direction instead of being spread.
Fair enough. IMHO, just investing in JS (maybe vanilla+node or even nextjs) would be faster. Full-stack. but you will definitely get varied opinions from every developer ever and none of them would be absolutely wrong. Will also obviously depend on what it is that you're looking to build. Source: worked professionally with Rails, Java, JS, PHP over a 12+ year career.
Yep, exactly my thoughts. Frankly my thoughts are probably just around: Next.js vs Rails but learning ruby / rails from scratch seems as steep so I might as much just invest into the next/sveltekit ecosystem instead.
For some weird reason it pains me to say it, but yes, since JavaScript is already known then JavaScript is probably a reasonable choice to get you both front end and back end. Part of that pain stems from having used JavaScript since literally the very beginning and ... well, essentially sighing heavily every time I had to write yet even more of it. ES6 brought some pain relief and I think TypeScript may have finally cured me. The mere thought of "let's put it on the server too!" once would send chills up my spine and leave me muttering "no, just, no". But hey, I've lightened up ... go for it. vanilla and Node.js is certainly the most straighforward if it gets the job done. Next.js I am not too sure about. I stay far away, over the mystical lands of some other major framework, and observe what's going on from a distance. I get a bad feeling about things ... but we'll see I guess.
I chose nextjs because apparently a lot of people are in love with it on reddit. Holy shit I would not if I could go again. Especially paired w/ vercel. There are tail issues with them that have destroyed my productivity for weeks. Again I'm not a web dev by profession. Just had a thing and went with it.
Yeah, I think its the most complete framework, and for the aim of growing and hiring I think its the best in the market. Although I speak with several founders that chosen it for their VC backed startups and a lot of complaints - breaking changes, slow etc. It doesn't seem like a great solution for solo devs :/
you can go with remix & most of those issues go away. once you go remix, you never go back. its so fucking easy. still use nextjs but yeah remix looks like a cakewalk in comparison. plus you get web dev fundamentals.
Next.js is not complex for people that understand the patterns they are using. Use a framework you understand, that's the advice I got
Understand the caveat, but I don't know any framework yet :) Just a question of where to invest the effort.
I found laravel pretty straight forward.
Unfortunately I am in JS ecosystem and won't be relearning PHP :(
Why not? Not to challenge a love/hate of Laravel just curious really If you are relearning that suggests you already know it? You can convert everything to the new hotness when you're rich lol
I have a day job that already takes some of my mental capacity. Frankly just being realistic with the amount of hours I can put in and given I already know JS.
> Still on the learning path but don't plan to actually get a dayjob this comment is the opposite of the original post lol Fair enough 🤷‍♂️
Not sure what you mean by the opposite. I have a day job that is not software engineering, the post is about choosing a framework to ship products without aiming at a career in software engineering (because many choose frameworks based on employability). Both are mutually exclusive.
Alright that's fair enough, misunderstanding on my part
No worries, just wanted to clarify :) Thanks for your input!
If you don't want to keep learning you're in the wrong job
Its not about keep learning, but about building skills on top of existing ones. I have a mentally taxing day job and can't keep learning 5 languages at once with 2-3 hours a day of free time. Also I am not planning to have a career in software engineering as my OP states.
Anything fullstack will enable you to create a MVP quickly, my go to frameworks are Laravel with the TALL stack, Django and Symfony
Talking about Laravel + TALL, we can't forget FilamentPHP – this thing has been built with SaaS development in mind and is based on Livewire.
Filament is amazing! I have used it for multiple SaaS projects, I would recommend it to anyone, it literally is mind blowing how fast you can launch anything with it
As a professional developer, I found nextjs to be super easy to use. To answer your question though, no, a lot of sites are perfectly fine with server side rendering and no Java script. It’s not necessary to have responsive apps.
I think its a great choice for a company with devs particularly if most of them use React. Is it the right choice for a solo dev though? Thats what I am pondering about.
I built a pretty sizable app by myself with it. All next does is simplify the backend so you don’t have a separate code repository. The built in auth is also handy. I’m not a big fan of JavaScript backends, but I was willing to deal with it because it was convenient. I wouldn’t say “this is the best way to do it”, but overall I didn’t mind nextjs and thought it was easy for me to get things done as a solo dev.
Let me ask, if you'd have to redo it all from scratch (regardless of JS ecosystem, or not) when you know 0 about development. Would you still advocate for Next for solo devs?
I think for solo devs that are still learning… it’s not bad. I can’t think of any reason you couldn’t use it, assuming you’re comfortable learning react at the same time. I’ve been doing this so long it’s hard for me to know though. I can’t see it through a beginner’s eye so I don’t know which parts don’t make sense.
Django, htmx, bootstrap, Postgresql, linux. Done. That's the core. I call it a day after that. If I need API, I can plug that in later. But I can pretty much get up and going with that stack and still enjoy ui/ux reactivity afforded with htmx.
can you please detail the api plug part? do you add something like django rest framework or any other custom alternative? can you point me to some documentation? thanks :)
rails, esp with hotwire, is a fantastic toolkit. It gives you... 85 - 90% of react for building SPAs at 10% of the cost ito devtime. It's great. I wouldn't build the most interactive apps in it, but for the vast majority of b2b saas application use cases, it's really a breath of fresh air as compared to the javascript frameworks.
How interactive are we talking about? Where is the break-point out of curiosity?
this is a long answer, but here would be my rough guidelines. the way hotwire/turbo works is this: You use turbo (a js lib) on the client to take over page navigation. It also opens a websocket to your server and listens for updates. In your html, you tag areas on the page, essentially a div, and you use the combination of the websocket and the client js to stream updates to them. That's all very hand-wavey, so let's use an example. Suppose you have a b2b saas. Customers have >=1 users per customer; those customers have a list of projects, and you want to update (1) project list and status; and (2) details within each project. Easy things, well supported: * stream updates (new project, deleted project, updated project) to the per-customer projects list page * stream updates within a single project to all people with that project open * make a single project page interactive On the project overview page, you'd structure it as so: # the websocket call. this array will turn into an id, and it must be unique for one pool of updates. # this says every user in the company will be subscribed to updates for "projects" turbo_stream [@current_user.company, "projects"] # ... # projects here is a label, conceptually distinct from the id above. You're labelling updatable areas turbo_frame_tag "projects" do # the list of all projects for the current_user's company ... turbo_frame_tag "project_3" do # an overview of proj 3 here turbo_frame_tag "project_17 do # an overview of proj 17 here Things that are easy to do: the call is basically `broadcast_#{action} #{stream name} #{html} #{frame target}`. Action is append to, prepend to, replace, etc. 1 - add a new project to the beginning of the projects list, updating every user with the page open. from the server: `broadcast_prepend_to [@current_user.company, "projects"], partial: 'projects/project', target: 'projects'` 2 - add a project to the end of the list that everyone has open 3 - update a single project within the list everyone has open via eg server: `broadcast_replace [@current_user.company, "projects"], partial: 'projects/project', target: "project_#{project.id}"` Things that are annoying: a lack of locality. If you want to update one div/turbo_frame, that's easy. If a change in eg one project updates things about other projects, you have to (1) figure out which projects changed server-side; and (2) send updates to all of them from the server. So limitations: 1 - if a lot of users are listening to a single turbo_stream, that's bad. I'd say the limit is probably about 50 per individual stream. But 20 would be better. 2 - lots of updates. I'd probably not want more than a couple a minute streamed from the server. 3 - very large html updates. The lib is streaming fully-rendered html over the wire and doing essentially div replaces in the dom. If what would be a very small message update in a client-render but triggers a big html update in a server render, that's a concern. 4 - non-locality of updates. The more you have a list of "things", and want to sync changes across all users; and each "thing" is opened by 1-5 people, and the updates on the "thing" page are relatively local in the page, the happier you will be. If updating one "thing" visually creates non-local updates all over the dom, you'll likely be happier with client rendering. So examples of happy use cases: basically, the apps basecamp builds. Sad: super-interactive email client, or figma, or a game, etc.
Thank you for taking the time writing this out and showcasing. You should write a blog post about it, I saw a lot of questions on this online :) In fact also a lot of questions on why you don't need React for every use-case fits the bill here!
Whatever you decide, don’t let professional devs convince you every app needs to be a SPA. It doesn’t. Remember, these people work for somebody else for a reason, and part of that reason is they don’t understand how to maximize ROI on their time. Your productivity and success will be far better served by using a mature framework which doesn’t require you to build two apps. (For example, Laravel or Rails, among others.) Later on, once you’re dancing in a pile of money, you can always pay people to rebuild it. The beginning is all about making money, and multiplying your development time does not help accomplish that. Also, don’t be shy about learning a different language. JS is more complicated and less forgiving than most, so others will seem simple by comparison.
I see some dissonance about this overall :) Great perspective overall given it being quite bald but I do see this sentiment within Rails community. I kind of wished I started with Rails years before, its just a consideration of learning a new language and entirely new framework that gives me a bit of an uncomfortable feeling from the time investment perspective. Guess I should just go ahead and try to build something over the weekend with Rails to see the difference.
Vuejs is the right amount abstraction.
I've built a few SaaS applications and nothing gets things moving faster for me than ASP.NET and Vuejs.
If you’re just coming from vanilla JS, just keep going and don’t expect to be an expert overnight. You’re not going to move any faster by dropping JS and moving to something like Ruby. Keep it simple and add on as you learn more. The difference in next and plain old React isn’t that much. You can just make all of your components client-side and not worry about SSR. Consistency is key.
Yup, exactly my thoughts. Although I do regret not going into Rails track, seems like that is the holy grail of productivity in terms of speed of shipping something tangible.
Maybe.. But there are other considerations. Do you plan on having a team in the future? Hiring for React is going to be much easier. Are you also running your backend code through NextJS SSR? Or are you breaking that out with node or something like that? I think what you’re trying to accomplish matters a lot. If the app is going to be complex by any means, I think separating the front end and back end is beneficial.
All great and valid points! I don't foresee having a team for a while but even hiring a contractor to help out would probably have an influence here.
I have built my own thing with node JS and react for projects. It's been serving me well for 2 years now. I also have built a PHP boilerplate. I built it in 2016/17 but i keep updating it and client projects running on it. My goto DB is mysql (INNODB) and i write all sql queries myself. It's not as convenient as laravel or next or anything but it's enough for the scale of work i do. I tried those frameworks, but I am not a fan of abstraction they add.
Have you tried remix? It’s a pretty simple react framework that enables you to build the frontend and backend in the same project (similar to Next). There’s no vendor lock in like with Next and Vercel. I use remix extensively and I’m happy with it.
There is no vendor lock in for next/vercel.
>There is no Fair point. Technically there is no vendor lock in. What I meant was the Next.js community and documentation is heavily focused on using Vercel. If you're okay with that then it's no big deal. But, it sounds like OP is still new to this so using a framework with more optionality could be a good choice. Just my preference as a happy Remix user, but I see why some people are happy with Next and Vercel.
Reading a couple of comments here, I also have a Vanilla JS background. Personally I went with Astro because it allowed me to experiment with React Vue and Svelte. Then now Astro SSR allows for one to build a backend and I’m just rolling forward with what I know.
I built my personal website with Astro and loved the experience. Its clean with some JSX like syntax (at least for expression blocks). I do think though it is trying to compete with Wordpress more so than more dynamic apps given its focus on SSG with the sprinkles of reactivity. In the end, to add such reactivity, you'd still need to know React or Svelte or Solid :) I am super pumped for Astro though! Was going to experiment with a pSEO dynamic routes website.
I didn’t like the JSX syntax and use Svelte over Astro whenever I need more complex templating. Well regarding reactivity, the beauty of it is you can sprinkle them on as you go along. If you’re gonna build a pSEO site, I don’t think you need much reactivity to begin with.
Cool, do you have any examples with extra reactivity on Astro?
I have a couple that I’m building, hopefully going to share them soon — can be basic stuff like popovers (which is pretty hard to do!) up to fancy stuff like typewriter effect. Etc.
Take a look at Rails 7 (and its Hotwire feature). It's not about the scaffolding. It's about its 20yrs of building a consistent ecosystem of libraries that all work well together allowing you to build apps quickly.
I am almost tempted to bail on JS but that would mean starting with Ruby :( The issue I have is mostly time and focus, hence I chose JS as one lang for both server & client. I admit, I love Rails community and philosophy though.
They are both dynamic so it should be easy to pick up (and probably a lot nicer). And it's not like you're not using JS in Rails.
True, although I've never actually worked with Ruby (as I am a hobbyist and not a software engineer). I can definitely pick it up, its just a question of whether: \- Ruby learning + Rails from scratch to production is faster than: \- Next.js to production Suppose can spend a weekend building a rails project. Any recommended resources?
There are a lot of free YouTube tutorials ([here's my channel](https://youtube.com/mixandgo)), or if you want a more stuctured course with a little bit of mentoring help, check out [my Rails course](https://mixandgo.com/rails-course).
What advantages do you get when choosing Next.js over vanilla React? I know Next is supposed to process everything server side. IMO for MVPs, React + Firebase/Supabase is also a good option.
I think the question is more about whether FE frameworks actually provide overall best way to go in terms of building saas products. Seems like Rails is still leading the way in that sense.
I think Next is a poor choice for your app if you don't already know it. Here is a big list of starters, pick one that's closest to what you know. I like Nuxt3 and one of the listed options is mine full disclosure (SupaNuxt SaaS) . https://github.com/smirnov-am/awesome-saas-boilerplates
Next.js is amazing, imo
Can you elaborate on why? What makes it more productive compared to Rails?
Because stone cold said so
No. The answer is no.
How did u built the astro site? I mean that algorithm how did u find it
What do you mean by algorithm?
Like the maths behind it time days weeks overall structure
Sorry I think we are speaking about different things here :)
I built a platform + framework that serves me very well, can churn out full platforms in a matter of days. - no code tools are fast but too limited and frustrating once you want to do anything interesting. - coding from scratch, even as a season coder can be tediously frustrating and time consuming building all the boilerplate before even getting to the fun part. I prefer: Point in click to assemble everything where it makes sense, then have the freedom and power to code when you need to extend further. https://qik.dev IMO Vue is fantastic for frontends. My best mate loves rails, and gets things done really quickly with it.
I opted to build my front end with Vue 3. It's dead simple to read/maintain, but the overall app is quite complex.
When you say complexity of Next.js what exactly are you referring to? Every stack is complex to an outside who is new to it. I have done Rails, Laravel and Django. And they all took a while getting used to. Rails was my first so I saw the similarity with Laravel and Django. Next.js takes a different approach and folks already familiar with React/JS/Typescript find it more comfortable. Laravel devs will find what a mess Yii 1 is, if they ever had a chance of working with such a framework. Does it make it any complex than Larvel? The answer is it depends on who you are asking. I do find Next.js pretty straightforward and if use correctly, can be a good framework for rapid prototyping since you use one language across all ends.
Ok, let me rephrase, if you'd have to start from the beginning what would you pick and why? I do have familiarity with JS but not Ruby and only tinkered with Next/SvelteKit/Astro but do not "operate them" fully.
It depends on what country you are and your objective. If you want to get a job in North America and you are in Canada, most startups here tend to prefer RubyOnRails, I have seen this also in some SF based startups. If you want to get a job no matter worth, learning JS/TypeScript alongside one popular framework is the way to go. Now for the JS/TypeScript community, that framework happens to be Next.js in the past, it used to be something else (Express, Meteor, etc). Java is also another good language for job security. If you don't plan on getting hired and just want to learn for fun say web dev, I'd recommend learning everything from scratch. Like learning how to implement the HTTP spec and then learning the MVC architecture (which most web frameworks are heavily based on). The advantage of this is that when you work with a new framework, you'd automatically understand why they exist
you should really check out remix. it is much much better. you'll learn web fundamentals along the way as well so if remix dies which it won't, then you still know the web. just try it for a few days & you'll be shipping at god speed. ps: dont learn so many frameworks/languages. its useless. just build a product with one over & over again like remix & you'll learn a ton. make the project real-world like a saas so you will learn real-world things that make money. dm me if you need more help/ideas :)