I can really buy into using JavaScript on the back-end as a concept, especially with TypeScript - it has the potential for a great DX, and good performance characteristics for most web applications. But I personally can't get over the "bring-your-own-everything" aspect of it. I don't want to think about ORMs, auth, etc. at the start of every project, and change the pieces of that puzzle every couple of years.

People talk about the instability of front-end frameworks but I think the back-end is even worse. If I could ask Tech Santa for something this Christmas, it would be a batteries-included TypeScript web framework that will be adopted massively.

“classes are objects!” I’m good. Just look at the local state of a JS app when it’s running in a debugger, the amount of global state you’re presumably supposed to keep track of.

All these transpiled compiled webpacked source mapped etceteras make it even worse, more indirect, more automagic, more unpredictable.

All this turtles-all-the-way-down flexibility JS provides isn’t necessary for a programming language, other languages accomplish the same tasks without it. The cherry on top is that you’re forced to use it basically because it’s baked into the web.

Sorry for the rant.

type NestedPartial<T> = { [K in keyof T]?: T[K] extends Array<infer R> ? Array<NestedPartial<R>> : NestedPartial<T[K]> }

Honestly, WTF is that? Do I need THAT in JS to write good code? How much time do I need to spend to get up and running and learn that thing? But again, some people are blindly praising it as the silver bullet to robust FE code... To me that looks C++. Good luck with that. If one thing I wished to not be out there is TypeScript.

Edit: Also sorry for the rant.

Where do you see something like this? It's rather unusual for app developers to write code like this; such code tends to be abstracted into libraries.

> Honestly, WTF is that?

A nested partial, as the name of the type helpfully suggests. I.e. a type that will check whether a deeply nested object, which has just a subset of the fields of a parent type, still has fields that are compatible with the parent. Should be useful if you want to deep-merge such a fragment with the full object, thus overwriting a subset of full object's fields.

I have seen that code in Stackoverflow. Someone was asking something about it. I do not have the link, just grabbed the snippet some long time ago. The point is not where does that come from, the point is it can exist and if I need to deal with it I need to do a deep dive in something that I do not have interest nor energy to invest on and in the mean time slows me down considerably.

> A nested partial, as the name of the type helpfully suggests...

Ok, good for you that you can proficiently understand it! Note that I'm not saying this in an arrogant way, honestly good for you that you have another tool in your belt, which is something always valuable.

I just do not want to deal with that (same that I do not want to deal with type hints in Python, I don't need it) but I increasingly see the industry (in general terms) praise for it. I prefer to stick to: "If it walks like a duck and it quacks like a duck, then it must be a duck".

Think about TypeScript the other way round. What if TypeScript wouldn't be out there? What can you do to bring more stability to your FE code?

Luckily, we don't have to conduct this thought experiment, we lived it from the release of JavaScript in 1995 to the release of TypeScript in 2012. The result was a decade and a half of spaghetti JS scripts and JQuery and unstable frontends. Universally true? No, of course not, it's always been possible to write good frontend code, but people who do that have been exceptions, not the rule.

> The point is not where does that come from, the point is it can exist and if I need to deal with it I need to do a deep dive in something that I do not have interest nor energy to invest on and in the mean time slows me down considerably.

Look, I completely disagree with you about the value of types, I think they're an incredible tool that rules out the existence of an entire class of bugs which are incredibly common in JavaScript frontends. But you don't have to agree. You don't have to like types, and you don't have to like or use TypeScript. But it's a tool that allows me to reinforce the basic structure of a webapp so that it's reasonably stable with far less work than vanilla JS. You seem to object to the existence of TypeScript and don't realize you can just... not use it?

You're implying that with TypeScript you will get your codebase spaghetti free which is obviously not true. You can have a code base that hasn't a single type error and yet be full spaghetti. This also holds true when working with any framework, backend or frontend.

> TypeScript and don't realize you can just... not use it?

I don't but the places I've seen TypeScript code bases still suffered from much more critical issues than type issues. Like using wrong ideas, wrong patterns, no tests, spaghetti code, but hey you know what? We use TypeScript and is great, and believe it or not that is becoming the rule, not the exception.

I am not. I'm saying I don't have to imagine a world without TypeScript, I've lived it.

> You can have a code base that hasn't a single type error and yet be full spaghetti. This also holds true when working with any framework, backend or frontend.

Sure. I don't disagree. I'd still rather have the codebase without the type errors.

No one is saying TypeScript is as robust as a baked-in typing system, but it's a godsend for ~98% of code one writes in JS.

Full-stack javascript sounds cool for small side projects but I want to have the freedom to write my backend in wathever technology I want, and I think many company do as well. I think the focus should be a robust frontend framework with modern features (SSR, data fetching, client routing etc.) and I'm hoping SvelteKit will be this framework

> Full-stack javascript sounds cool for small side projects but I want to have the freedom to write my backend in wathever technology I want

You do have this freedom though! Doing full-stack javascript is a choice you can make with that freedom.

But i also think it is still not there. It’s missing a lot of things when you compare it to Laravel itself, the documentation is not as great and the community is still near non existent. In the Laravel world there are a ton of top quality third party packages for example. There are very few for Adonis and they don’t have a certain future imho.

Worst part is that it is 99% developed by a single person and if that person burns out or for some reason is not able to work anymore on it, you’re screwed. This is pretty important and I don’t think this is a problem with Laravel or rails, as there are huge companies using it and a lot of contributors.

But I really look forward to a world where Adonis becomes as popular.

And don’t even try to mention to them Laravel/Rails is easier because they’ll crucify you or call you a dinosaur or something.

But hey, they’re so proud of js all the things.

Not using next.js doesn’t mean you’re in the stone ages doing query spaghetti.

I just don’t use nextjs as a full stack or backend framework. Right tool for the job and all of that.

It's certainly possible to do it, but the time and resources it could take to do so will most likely differ. If it's an estimate/deadline driven culture, then it's likely that not having lots of historical data for how long certain things could take will result in mismatched expectations and bad planning.

Iteration and setting smaller goals could help, but it obviously will not always be the best solution for shipping things fast, especially if nobody has bothered to create useful packages or components in other projects beforehand that could be reused.

Though most technologies will have similar challenges, just in different aspects and to different degrees.

> And don’t even try to mention to them Laravel/Rails is easier because they’ll crucify you or call you a dinosaur or something.

Frameworks that focus on server side rendering and full stack development are pretty nice, though they can also be problematic in some regards sometimes.

For example, lots of folks out there who are running Mastodon instances or GitLab instances (Rails apps) run into issues with hardware requirements and scaling once they need to support larger userbases. Then again, the speed of iteration is hard to beat and for smaller projects (like my homepage, for example; but also most CRUD apps and such out there), either is probably okay.

However, I've also seen the other side of this in the Java ecosystem - an application that uses Spring and PrimeFaces, which has gotten harder to maintain and work with with each passing year. In part due to the frameworks themselves not really being the hot new thing anymore and not getting lots of attention, but also because scaling and keeping the performance good as the project grows is nigh impossible, though in part both because of how the project has evolved, as well as how all the components are integrated.

Similarly, if you have an API for your back end instead of doing server side rendering, you can easily create multiple front ends (in case you happen to use AngularJS and want to migrate to something more modern, or one of those other old libraries that went nowhere and were abandoned/deprecated), or even integrate with mobile apps and so on.

Though I have to say that even some of the full stack frameworks do some things nicely in that regard, since with Rails you can just append ".json" to your endpoint and get something pretty usable out of it! Plus, they lend themselves really nicely to codegen, at least for simpler cases (e.g. using Rails generators).

Overall I guess what I'm trying to say that solutions that will result in lots of coupling can be problematic. Tread carefully.

The node stack isn't that complicated, and the things that become complicated have preventative solutions (nvm to pin node versions and environments in isolation, pin packages to specific versions)

I can acknowledge that large applications often become unwieldy, not unique to JS but not helped by JS, but I still considered these to be system design problems. The way I develop my own applications is very streamlined to serve a lot of people and generate revenue in a 1-2 step funnel, and is very different from having to maintain some pre-revenue venture backed companies’ 30-step funnel because they want to data mine everyone and sell the promise of engagement to raise even more capital. The latter becomes difficult to juggle.

Of course you can a la carte your own solution together every time, but the API at every different layer is almost guaranteed to be markedly different, the level of testing, support, size of the userbase/ecosystem is unknown, and every minute you spend debating those solutions, wiring them together, maybe creating abstractions so the API "feels" more native, etc is time you are *not* spending writing the actual application.

Finding other developers to work on your homegrown potpourri who won't screw up because they don't fundamentally understand object storage or DKIM constraints when sending mail or can't optimize a query better than the ORM or whatever will be difficult, and even harder if you want to find one who can do that AND nail down which parts of the underlying infrastructure (k8s, DNS, message queue, distributed k/v store, whatever) may or may not be responsible for a problem surfacing for 3% of your users is a harder and harder ask.

You're free to consider DRF and backend Rails and .NET and the rest to be "bloatware". I am not a web person in any way, so I don't have a horse in this race, but I am/was a backend/infrastructure person who has repeatedly had to help "full stack" web devs out of shooting themselves in the foot because they don't understand OIDC/SAML or service lookups in k8s or service meshing or DNS between geo-distributed clusters or how to write an INNER JOIN or you name it.

The "bloatware" lets web devs ("full stack" or not) concentrate on solving their actual problems instead of spending time and getting behind schedules re-inventing comprehensively solved wheels.

Would love to hear the opinions of those that have to maintain applications made "your way" after you leave. Hopefully you're documenting and testing it to the same level that Laravel, Rails and Django are, and hopefully the size of your company compensates for the lack of community around it when the problems show up and you're not there anymore.

Node and dependencies are not complicated, there are best practices to avoiding making them complicated.

was impressed by laravel

and the people I encountered using Django were not doing anything impressive but I could see the potential

With Ruby, Rails prepares the language for the web. The framework is needed as an enabler. Same with Python and Django.

Nothing to back this up other than personal experience though. Just a theory.

Maybe it will turn out to have the staying power that Rails has had with Ruby and become “the way”? For a long time there were nearly as many PHP frameworks as JS.

How about the fact that no one ever has a clear answer on where to put your global server objects, like singletons? connection pool or socket.io server?

In all my search I only ever came to some example where they put the prisma object on `global`. Why do they have to do so instead of just have it the export of some module? If it's because the handler is "serverless" wouldn't that make it a different `global` every time? There is absolutely no explanation on their website on why such trick has to be done for such basic need.

It’s a total nightmare. The only ones that would deny this is madness are those that have never used a real full stack framework and don’t know what they’re missing.

Looking at next.js for example. There are so many ways to fetch data for a page: getStaticProps, getInitialProps, getServerSideProps and the API handler (I hope I didn't miss any now). Each single one of those uses their own naming concepts (context vs req/res, query vs params). It is very easy - especially for newcomers to the frontend - to break things or leak data by not following the concepts of the frontend.

By dividing backend and frontend on a language level, you get a clear boundary on an API level which helps developers having a clear focus on their actual problem scope.

I guess you could solve the problem by having two node.js applications: one providing API endpoints and one taking care of the view. By then, I'd just switch to a properly type-safe language for the backend.

I'm not really a fan of Typescript as a backend language and I think I'd lose a lot of the niceties I get from things like Go, Java, and Rust if this happened.

I took would love a world where I could write Go sensibly and get a fully functioning frontend. This is done rather nicely in TUIs, which follow a lot of the same rules as CSS. It's the part that JavaScript fulfills on the user side that's cumbersome to replicate.

I'm also not sure I'd call frontend deps "unstable" as much as "rapidly evolving", which gets weird when you're constantly playing catch up in that domain of knowledge.

No need to jump into framework of the month for backend.

One can keep doing MVC just as always, no need to jump into Razor Pages with code behind, or the minimal APIs designed to cater to JS devs.

Just like JakartaEE isn't fully 100% Java EE, yet most stuff works the same way.

Web Forms is deprecated since around 2010, while 12 years old MVC is a matter of creating a new .NET Core project, even WCF is now mostly supported on CoreWCF as Microsoft has forced to support it.

Windows developers don't like Python 2 vs Python 3 experiences, and have voted multiple times when Microsoft tries to play Apple.

This is hardly like FE frameworks having been doing since jQuery.

Comment last week during a PR, why are we still using webpack instead of XYZ.

You can run JS from 15+ years ago in the same vein.

Thankfully only have to deal with JavaScript on the browser.

I have had to touch. Net code that hasn't been updated in years and bring it current. It isn't fun.

By the same token, I lost about a week and a half recently updating a front end project that was started about 5 years ago.

I'm either case, .Net is definitely not the panacea you seem to assert that it is.

It is still MSBuild, Maven and Gradle after all these years, three major IDEs, most libraries just work, there are hardly talks about why we are doing it all wrong and use framework XYZ or build system ABC instead and so on.

- Production codebase is really hard to extract into reuseable libraries.

- There're too many standards on the same things.

Rails is a success for one of reasons, is, DHH is the main leader, no "competitive standards".

PHP, Python, Java are massively adopted languages where you can name a leading batteries-included framework or two. There were different reasons for converging into a leading framework (ex: the case of Spring may be very different to that of Django), but that convergence happened.

JS/TS? No real convergence 14 years after the introduction and massive adoption of Node.js as a backend runtime. Why not? Beats me.

Whenever I do start using any kind of JS framework and go through the process of researching best practices, ecosystem of related packages, etc., in a year or two that is largely irrelevant. Thus, the next time I need to start a JS project, it doesn't matter to me whether I'll pick the same or a different framework du jour, I will have approximately the same amount of (re)learning to do.

Compare that with Django, where little changes in years (one data point, I recently upgraded a legacy SaaS from Python2 and Django 1 to Python3 and Django 4 and it was a few days' work). This means every time I work with Django, I learn more about the ecosystem and it's easier for me to just start new projects in it as well.

Vite-plugin-ssr describes itself as "Like Next.js/Nuxt but as do-one-thing-do-it-well Vite plugin.". I use it for https://github.com/inlang/inlang. The control and ownership of the underlying rendering techniques is truly relieving and enables us to run static sites + a high dynamic (client-side rendered) app in one monolith instead of the typical static site + app.domain.com split.

other than that, no gatchas i encountered. i would choose vite-plugin-ssr again.

SvelteKit was more exciting to me before I discovered Remix, which seems to simplify things even further and make them so nice. The entire API is very small, but powerful.

But if you need serverless/microservice for your existing app of any backend type, nodejs is low friction and highly productive.

https://www.smashingmagazine.com/2022/07/new-pattern-jamstac...

Also, halfway through they decided to push a new Next.js version (still in beta) so you''ll need to move all your `/pages` to an `/app` folder, with a completely new structure.

I wanted to learn something new so that's fine, but something like Rails, Django or Laravel would have allowed me to develop way faster. I'm quite disappointed.

I am working on dev-first localization infrastructure after being frustrated with i18n from a dev perspective myself. Your remarks seem like they fit into the infrastructure approach I am taking. See https://github.com/inlang/inlang

Next.js does have an API functionality so it can also be used to create a full-stack app.

I wish I could love Next’s API routes as much as the rest of the framework.

The author is seriously suggesting Next.js to build a company website.

In a lot of "website" scenarios, it makes much more sense to choose a CMS like WordPress, Drupal, Django-cms etc.

In case of a custom application development, frameworks like Ruby on Rails, Phoenix/Elixir or Django is usually a smarter choice.

Next.js is not necessarily a good fit for every problem, and it may be more suited to a specific subset of problems than is often assumed.

There are massive, hyper-scale websites built on Next.js: Walmart, Nike, Hulu, Notion, just to mention a few. [1]

Are they not "serious" to you?

[1] https://nextjs.org/showcase

Frankly, I hate working with raw HTML/CSS. It sucks. Using TSX is such a better developer experience. I'm much more productive in a nextjs app, even if it's just static, than I am with plain old markup.

There's no reason why you can't use those with a JS framework though. A CMS for the website content team to modify content, with a static site builder process that runs when content changes is a very common approach. You can use Next for that. And it can be entirely static, with no JS delivered to the end user at all. That gets you all the benefits of a CMS, with all the benefits of a static website, and none of the security hassles of running a public-facing Wordpress site.

I'm not super opinionated on what people pick other than advising to not get tunnel vision and only consider one language. Also, static code generation and server side rendering are two very different beasts. Server side rendering of course can be as simple as just a static code generator where you don't actually persist the output (i.e. it's dynamic). But usually there's a bit more to it and you get server side views, caching, and a whole lot of other stuff that people forget about that is actually needed in a server application such as logging, database and other middleware integration, authorization and authentication, etc. Once you figure out you need all of that, a "lightweight" framework that isn't particularly good at any of that might not be the obvious first choice.

It's why javascript is much less of a mainstream choice on servers than it is in browsers. Yes you can use it and lots of people obviously do. But there are countless other very mature and well established technologies that you can choose from as well. And most of those can do server side rendering pretty easily as well as it is not that big of a deal to actually implement. If you need it.

I think the specific attraction of javascript based frameworks for frontend developers exploring getting into backend functionality is that they can use the same tools and frameworks that they were already using client side. Specifically react users seem to be looking for ways to use react on servers.

While a JavaScript framework like React can be used to build a company website or CMS, it is often not a good idea to use React to do this.

Off course this is highly context specific and depends on the particular requirements of the "company website". Without a strict definition of what it is, it will be always a discussion about an ambiguous and moving target.

The choice also depends on the technical knowledge and experience. For someone with years of experience with Javascript and really an expert on it, it might be still a smart choice. Or maybe we are not talking about 1 developer but a team of 10 developers etc.

I was just trying to suggest that this is not often the case.

Hi, I'm the author :). I wanted to highlight this recommendation has the modifier "If you'd like to learn something new". This very subjective recommendation is solely based on the exciting mix of rendering options, the vast popularity, and my preference for JS and React.

You're spot-on when you emphasize that there are web applications that are a different beast anyway and websites that run perfectly fine with a CMS in the background.

That's exactly the point I see...? To build a website (as opposed to a web application) with mostly static content and maybe some interactive embedded content, do not use N*xt.js. Use a CMS or static site generator or whatever instead. Without any fancy client-side URL routing and whatnot. Just let the browser do its thing.

That being said, some frameworks support a SSR-only approach or even static site generation. That's also fine IMHO. Just use what you like! If you like Ruby on Rails, why not? Angular SSR? Gotcha.

I tried multiple tools like Jekyll and Hugo but found them terribly clunky. Then I found Astro and now I'm happy. Reasonably similar to SPA frameworks, but generates a static site.

I attempted to start a (personal, but with commercial aims) project using Nuxt about three weeks ago, as I'd had good experiences with it in the past. It's not been at all fun - whereas with Nuxt2 it felt like I could get up and working quickly, it's been weeks worth of playing whack-a-mole fixing errors. Settled back to Vue3 and got up and running in a few hours.

Sveltekit certainly looks interesting. I've tried to get excited about React / Nextjs in the past, but while the concept feels solid, I guess I've always felt like Vue was a better implementation of the concept.

SvelteKit might offer a slightly higher DX by being the new kid on the block that learned from NextJS and Co. The big difference is just Svelte vs React. Svelte is delighting to use but a headless UI library, or generally good UI lib is missing and JSX has its advantages. The advantages of JSX being more flexible and better TypeScript support. I decided to go with Solid for a new project. Solid combines Svelte's easier reactivity and JSX. More about the rationale behind choosing Solid can be read in an RFC I wrote https://github.com/inlang/inlang/blob/main/rfcs/002-tech-sta...

It allows you to decide about ssr/ssg/csr per route and has an overall nicer approach to reactivity.

https://www.npmjs.com/package/nust