25 years of working with it and I still hate JavaScript. Its behavior is unpredictable, I can only figure out what my code is going to do by running it.

“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.

> Sorry for the rant. On the contrary, thanks for it! I haven't been developing with Javascript that long but I also share same feelings and worse. On top of that there an astonishing number of frameworks that all claim the same: fast and under N KiB in size. On top of that people always on the edge using the latest craze out there, just because it is trend. It feels like Java in 2000 or C++ in the 90's but much worse. But the cherry on top are the TypeScript fanatics. I do pretty well with JS and maybe a light framework on top of it, thank you very much. I do not need TypeScript nor its guarantees. Why? Well because if you comply to your interfaces and add tests and docstrings that is enough to have things in place with decent robustness. When I see something like this:

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.

> When I see something like this

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.

> Where do you see something like this?

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?

> 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?

> Luckily, we don't have to conduct this thought experiment...

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.

TypeScript solves one single problem and is pretty good at it given the dynamic complexity of JS language. Trying to justify its usage as "fix-all band-aid" and then not liking the tool because it can't do that is not very productive. You can use wrong ideas, wrong patterns, no tests and have spaghetti code in literally every other language, that's not something for TypeScript to handle.

> You're implying that with TypeScript you will get your codebase spaghetti free

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.

Types make expectations on behavior explicit instead of implicit. They nay not feel needed when you feel like you master the language, but they sure do help communicate and quickly grok some aspects of the code without having to interpret it in your head(which might be easy when you've just written it but less so in many situations).

Aside from C++, you can also have typing atrocities in Java, and I bet in C# and other strongly typed languages I haven't tried, too...

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.

C++ has a much more complicated (Turing complete) type system than C# and Java.

Lol yeah the TypeScript syntax is insane. It's great for primitive types and simple inheritance and extensions, but the generics and stuff... unreadable

It seems weird to want NextJS to be a batteries-included backend framework, when it's not even a batteries included frontend framework. NextJS offers SSR and a router and that's about it, if you need client side data fetching you will still use React Query / SWR, if you need heavy client state management you'll use Redux / Zustand, you probably want an UI library so you'll have to install Bootstrap / HeadlessUI / Radix etc. Everytime you start a NextJS project you must go through library shopping even for frontend stuff

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

I agree that maybe NextJS could do with more 'batteries' included, for things like Auth, and could do a better job for providing (lowercase H) hooks for client-side data fetching (given its existing get*Props APIs), but I think it's realtively wise for NextJS to not have much of a say for things like UI component libraries. I don't think it makes sense for NextJS to ship with like Bootstrap - I don't want to use it!

> 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.

I do not even begin to suggest in my comment that NextJS is batteries-included, nor that I want it to be. Maybe you're addressing someone else's comments.

I think the OP is talking about Nest, not Next FYI

Have you tried adonisjs (https://adonisjs.com)? It is the "node version" of Laravel. I find it very easy to use, especially as coding is not my main career.

I like it a lot and I do think it is the best backend option for node at the moment. I really think it has great potential.

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.

Fwiw, for a long time, Laravel was solely developed by Taylor Otwell. It is only within the last few years that he hired a few devs to help him.

Worst part for me is seeing sibling teams at my company fail miserably and live behind schedule and struggle a lot because they’re building full stack products/applications with it. And most of them don’t even realize how much they’re missing from Laravel/rails like frameworks.

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.

It’s not free though. I’m sure you get a lot but you also lose a great deal by writing weird client side-only JS where you imperatively reach into the DOM with decoupled selectors.

I don’t have that problem, because I still use reactive frontend libraries in the frontend.

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.

> Worst part for me is seeing sibling teams at my company fail miserably and live behind schedule and struggle a lot because they’re building full stack products/applications with it.

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.

I was buying into your observation until I remembered that consider those other frameworks you mentioned to be bloatware

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.

This isn't a "JS" problem. A consistent story/UX around common tasks isn't "bloatware". Queuing jobs on the backend, managing CRUD-ish stuff like native objects, multi-part file uploading (including CORS management, storage as blobs in the DB if you need it), user/auth management, sending mails, and so on really is just the basics.

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.

> 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

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.

These applications can be done in any of those frameworks.

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

Have you done any real work in Laravel, Rails or Django?

plenty in rails

was impressed by laravel

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

My theory on the lack of a main framework with both JS and PHP is that they are both languages designed for the web already. Because they have so much included, frameworks are mostly just arranging what’s already there which creates a low barrier to entry for new frameworks.

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.

But PHP has Laravel, which many devs sing the praises of, and has had other very big frameworks widely used at enterprise scale...

It does now and it’s definitely the closest thing to a ubiquitous framework for PHP that we’ve had available.

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.

Next is far from battery included, right now I'm trying it (not the first time, I used it to make static sites before) to make a back end and and have been bitten multiple times by the fact that the same files can be bundled differently on back-end and front-end. For example `next-auth` generates the page `/api/auth/signin` (yes a page behind `/api`) and when I tried to hit it. I got a complain about a knex dependency. Obviously they never expected anything behind `/api` to appear on a front-end bundle, but here it is, they default to such a page.

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.

Wait until in addition to authentication, you have to also add translations and validation messages and make all of this work together nicely, with ssr too.

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.

To me, the biggest problem with javascript as a backend language is - especially in large teams: people tend to mix backend code with frontend code after a while.

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.

> If I could ask Tech Santa for something this Christmas, it would be a batteries-included TypeScript web framework that will be adopted massively.

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.

It still blows my mind too that there isn’t a single opinionated framework. Imagine how much further forward JS would be. Rails is still an order of magnitude more productive than anything we have tried on JS, but everyone asks for JS because easier to find people. Truly maddening that JS somehow grabbed the popularity crown.

Because everyone has different opinions on what an opinionated framework around JS (especially server+client) should look like... Not to mention how many front ends are loosely coupled to backends written in a different platform/language.

I hope that redwood.js become a rails like framework for JS ecosystem.

Isn't there at least Tails and Sails?

Have you heard of Remix? https://remix.run

Checkout https://www.mandarinets.org/ if typescript + deno is acceptable.

I have been using Java and .NET stacks for about 20 years now.

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

I actually can't wait to get my hands on .NET after years of developing my backends in JS and Python. I've read the docs, watched some tutorials and played around with code, and it looks and feels dope. To be honest, for smaller projects I will probably continue to reach out for something JS. But for anything more serious I will be using .NET Core.

.Net has changed significantly since WebForms ASP+ backend... MVC reshaped things and this has been refined, Core -> 5+ has also changed things a bit... it's not like it's the same code you worked with two decades ago.

Except that most of the same code keeps working, and even between classical Framework and Core, most concepts keep working even if the APIs, and configuration files, are a bit different.

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.

The point is, you wouldn't normally start a .Net project today the same as you would in 2002. Personally, I jumped to separate html+js and using ashx until MVC came out, because WebForms was a mess. In the end, it's not like it's the same, even if a lot of the same code might work (unless you're using WCF or many other things that broke along the way).

It is still the same framework, and most stuff still works.

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.

So, you've taken a project from 15+ years ago in .Net and run it in .Net 6+?

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

Not because contrary to the npm junkyard, the ecosystem values stability.

Thankfully only have to deal with JavaScript on the browser.

So after touting something you can do, you've never actually done it.

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.

.NET and Java definitely are when compared against many fashionable alternatives, naturally you can come up with corner cases like projects using remoting or RMI, while ignoring their ecosystem stability versus those alternatives.

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.

The lack of batteries-included frameworks don't mean it's not impossible. But it might means 2 things:

- 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".

Rails is special in that, arguably, Ruby wasn't otherwise a massively adopted language, at least not on the scale of others. RoR drove Ruby adoption in a very unique way.

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.

For me - it's massive churn due to newer versions generally being incompatible with the earlier ones, and being pushed out fast.

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.

Is it the culture? For years the people (Microsoft, Apple) who would have naturally pushed standard ways of doing things in javascript front end, actively neglected it. So lots of much smaller entities had to invent their own ways of doing things. That culture persists on the back end.

I think it might partly be due to the culture around how large or small libraries tend to be. Node grew up with NPM, and with it came the culture of building things from tiny parts. Most libraries have usually had a single focus, and even a lot of the batteries-included options today still depend on other major libraries instead of reinventing the wheel. I think that culture sorta naturally leads to XKCD-style “15 competing standards”.