Next, Nest, Nuxt Nust?(twilio.com)
twilio.com
Next, Nest, Nuxt Nust?
https://www.twilio.com/blog/comparing-nextjs-nestjs-nuxt-gatsby
122 comments
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.
“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.
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? 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?
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, 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.
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.
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.
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.
As a fan of typescript, I have to say, no you can't be THIS crazy with types in C++, C# or java
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.
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.
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
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.
> 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.
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.
[deleted]
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.
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.
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.
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.
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.
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.
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.
Node and dependencies are not complicated, there are best practices to avoiding making them complicated.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
- 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.
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.
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”.
I recently discovered and recommend to take a look at vite-plugin-ssr https://vite-plugin-ssr.com/.
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.
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.
Any issues or gotachas you've run into as compared to Next?
- The documentation is good but not "amazing"
- the surface api for routing is large (different ways to achieve routing). the maintainer is working on reducing the surface area though https://github.com/brillout/vite-plugin-ssr/issues/53#issuec...
- api routes (cloud functions) require another package (on purpose). see https://telefunc.com/ from the same maintainer
other than that, no gatchas i encountered. i would choose vite-plugin-ssr again.
other than that, no gatchas i encountered. i would choose vite-plugin-ssr again.
Sveltekit 1.0 was just released and I got teary eyed when going through the interactive tutorial at http://learn.svelte.dev and saw how intuitive some things were compared to react.
Have you tried Remix?
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.
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.
Before deciding on these very dev-oriented metrics, one should probably define the goals of the site/app. Is it a community site where easy content editing / contributions should be prioritized. Or is this a landing page that should have stellar SEO and load blazing fast. What language / framework am I or my team familiar with. The raw performance metrics should probably come last.
Hi, I'm the author of the blog post and wanted to say that I completely agree with your statement.
I picked these metrics because I find them very useful to explain the differences between the rendering options. I did not mean to say that every website needs to optimize for all of them.
The naming caused a little bit of confusion on our last retrospective, because we wanted to migrate our little Node.js project to a proper framework and it wasn't clear if the person suggesting it said NeSt or NeXt.
Yeah, specially with non native english speakers, it is hard to distinguish what they are talking about, and if I correctly remember they are totally different in approach.
Absolutely! And it doesn't help that each framework has 2-3 ways to be spelled: Is it nest, Nest, or NestJS vs Next or NestJS?
And then there is also NeXT
Something tells me the rate of JS backend frameworks means that JS is not a great choice for backend frameworks
Most backend nodejs stuff is microservice/serverless/front-end oriented, and what's not but is mature is mostly pre-async and pre-typescript. Then on top of that, rails/laravel can scaffold you extremely strong starting templates, like having working MFA and uploadable profile pics in less than an hour.
But if you need serverless/microservice for your existing app of any backend type, nodejs is low friction and highly productive.
But if you need serverless/microservice for your existing app of any backend type, nodejs is low friction and highly productive.
or rather that js devs can't into developing backends
Regarding SSG I've formalized (but not invented, it's as old as the web) a pattern that allows to extend it to pages that looks the same for multiple users, but not necessarily all of them. It's already common to do that for i18n where multiple users share a same language, but not all users.
So the scope of SSG us broader to what's described in the article, and also it should probably not be differenciated to SSR as it is just build-time cached SSR. Next 13 app folder makes this clearer.
https://www.smashingmagazine.com/2022/07/new-pattern-jamstac...
https://www.smashingmagazine.com/2022/07/new-pattern-jamstac...
I agree that the lines get more blurry the closer you look, "is it still SSG or already a hybrid approach when it contains localized strings?"
What I meant to describe in the post is the conceptual difference to understand the purpose of the rendering frameworks better.
Makes sense, the problem is that rendering frameworks are lagging behind the current understanding of server-side rendering, Next 13 is the only exception I know
Unless you’re an Angular developer I wouldn’t bother even looking at Nest. It carries over a ton of the same paradigms for better or worse. The biggest problem I have with it is the use of decorators. Microsoft jumped the gun adding support for them into TypeScript and the current proposal is very different.
I'm writing a small side project app using Next.js. I found out the bad way that i18n support is quite bad. Sure, you get an i18n router, but you have to manage translations on your own. There are libraries to do it, which are fine, but translations only work in the front-end, there's no way to, for example, use translations inside an API call (!!).
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.
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.
Can you elaborate on "manage translations on your own"?
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
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
Well what I meant there was just that the framework doesn't take care of that for you, you need a third-party library.
The decision tree at the bottom starts with "Full-Stack App?" but only lists Express and Nest at the "yes" branch.
Next.js does have an API functionality so it can also be used to create a full-stack app.
Next.js does have an API functionality so it can also be used to create a full-stack app.
Next.js API DX is horrible compared to actual API frameworks like fastify. :/
I wish I could love Next’s API routes as much as the rest of the framework.
I wish I could love Next’s API routes as much as the rest of the framework.
You're right, thanks for pointing this out. I'm the author; I updated the graphic to split based on the framework's purpose, "pure backend" vs. "focus on rendering". I hope this is clearer now.
Being able to return JSON makes you "full stack" the same having wings makes a fly an airplane.
Yeah I think they should be switched
For most use cases, I wouldn't advice actually a JavaScript 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.
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.
> The author is seriously suggesting Next.js to build a company website.
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
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
I think they mean "website" as in "static pages of content". Those are all web applications.
Many of these examples use Next.js to support their static content (eg, marketing). Maybe they mean that it's overkill for smaller projects or customers (eg, SMEs) which I would tend to agree with (although, there are Next.js low-code/CMS services emerging, like Builder.io or Plasmic) but for larger companies that have the JS web dev talent it can make perfect sense to do their marketing sites on Next.js. I've also served a small business (an agency) that wanted to do very funky stuff for their marketing site - Webflow or Wordpress certainly weren't going to cut it, so Next was a good fit.
Using a javascript/typescript framework to build static sites is so common place now that I'd even go as far as saying it's the standard.
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.
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.
In the last few years I've moved away from JavaScript and frameworks in a lot of cases because writing raw HTML and CSS was not cumbersome, involved vastly simpler tooling, and didn't involve other folks needing to learn some obscure framework that may have gone out of fashion. HTML and CSS are here to stay and currently they serve their purpose very well. I don't agree with your take (J|T)SX obscure the HTML whose trench coat it's trying to wear with arbitrary rules that produce unexpected effects. If author HTML is considered a burden, I'm not sure how keeping something XML-like is going to make the ergonomics or readability better.
I'll take those arbitrary rules if it lets me use component-driven design unlike raw HTML/CSS does. Very much a worthwhile trade off.
That's because you're looking at the wrong alternatives. check out Hugo
Not seen Hugo, but Htmx is looking interesting.
I'd say this really is an opinion, those choices have deep technical implication and are highly contextual.
Next can also act as a backbone or "backend for frontend", it's not incompatible with using a CMS or building a custom application.
In a lot of "website" scenarios, it makes much more sense to choose a CMS like WordPress, Drupal, Django-cms etc.
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.
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 think we are talking specifically about server side rendering, which is a subset of server side functionality covered by a wide range of languages and frameworks, some of which predate things like node.js by quite some time, Like php, which literally started out as a server side template rendering language end of last century. Php and Javascript emerged around the same time if I remember correctly. I never was a big fan but it remains extremely popular and still runs quite large part of the web.
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.
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.
These do completely different things. It’s like saying “I wouldn’t advise using CSS, use HTML instead”.
I get what you are trying to explain but this analogy is completely wrong. It would mean that the two subjects are complementary and are often used together which is clearly not the case.
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.
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.
> The author is seriously suggesting Next.js to build a company website.
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.
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.
> These do completely different things.
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.
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.
If your developers are already familiar with React, I think next makes a lot of sense for a corporate website. When used as a static site generator, you can reduce a lot of complexity over wordpress et al. because you don’t need a database and can deploy directly to a CDN.
Surprised sailsjs hasn't been mentioned in this thread (and/or seems to have faded in popularity?) Seems like if you go back in time maybe 7 years or so it had a hot moment where it looked like it might become the rails / django / spring of the js world, and then felt like poof it was no longer a major part of the conversation.
Yes, I only focused on the top five frameworks :)
I just checked and Sails, once on place five, fell out of the named ranking in 2019
https://2019.stateofjs.com/back-end/
I don't blame you a bit, you've got to make the scope of your writing relevant to the audience and the moment... just more surprised that Sails seemed to have its moment and then disappear just as quickly, especially given the chat in a thread like this one on HN where there are apparently many people curious if not outright looking for a full-stack js framework.
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.
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.
Anyone here using Svelte or now SvelteKit, how does it compare to React and Vue and Next and Nuxt respectively?
NextJS and SvelteKit are same same.
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...
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...
the new Next is very close to SvelteKit, because they copied their routing
actually, svelte-kit copied nextjs routing :D rich harris read the routing RFC from the next team before they released it
interesting, that's been in the works for quite a while then
SvelteKit!
It allows you to decide about ssr/ssg/csr per route and has an overall nicer approach to reactivity.
It allows you to decide about ssr/ssg/csr per route and has an overall nicer approach to reactivity.
I definitely have SvelteKit on my radar, but I wanted to focus on the top five frameworks this time.
Maybe SvelteKit will make it in the 2022 results :) https://stateofjs.com/
To be honest, I thought someone just released Nust, which is a Next built with Rust.
Haha, this title was actually suggested by a friend of mine when I did the research for this post. But then I found out that someone already created an npm package with this name, but the project seems to be dead :D
https://www.npmjs.com/package/nust
https://www.npmjs.com/package/nust
Measuring TTI and not even mentioning Qwik? Weird :)
Can’t scroll this page on ios safari 16.2.
we sleeping on deno fresh js?
Qwik.
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.