- 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.
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.
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.
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.
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.
“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.
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.
The reason ts can be unreadable is actually same to why haskell, scala, ocaml etc are: the type systems are much more expressive so people keep pushing it.
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.
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.
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.
was impressed by laravel
and the people I encountered using Django were not doing anything impressive but I could see the potential
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.
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.
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.
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.