Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I would add that Node JS is suitable for fast development and for relatively heavy loads, not just as no-OOP alternative (in which case you can use Python or any other multi-paradigm language).
And last but not least this sentence:
"nextjs - why isn't webpack sufficient? static rendering is not relevant for SPAs"
Shows a complete misunderstanding about this tech (both webpack and next JS) plus ignoring the fact we usually need SEO in public tools.
BTW you can build a monolith using Next JS as you can do both Node JS and React parts on it, which is suitable for many start-ups as a fast solution.
As devs we need to understand that business needs go first (are the ones paying our salaries at the end) and usually business needs, specially in a start up is to provide solutions and project evolutives as fast as possible.
I used nextjs for the last year building a static site, then a SPA. I didn't use it in a server side rendering case. Whenever people talk about build time rendering, the first question is if the data is specific to the user or not. If it is specific, like anything beyond the login page and some marketing landing pages, the build time rendering doesn't apply.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Of course that non-crawable paths are out of the equation. But there is a different use-case, when you've data which is public but logged in users see the content customised or more capabilities.
On the other hand Next help you with image optimization, pre-loading internal linked views, caching things up and the view presented is -usually- Interactive faster, so the user experience will be better anyway.
But there is a different use-case, when you've data which is public but logged in users see the content customised or more capabilities.
Agreed, I just don't usually work on apps that have this component.
Also, I think the nextjs/blitzjs zero API approach is somewhat novel (and I assume this is what people like the most), but it goes against my general lack of enthusiasm for isomorphic applications. I think inertia.js is a nice technology agnostic approach to achieving similar goals though.
Node JS is suitable ... for relatively heavy loads
Given my personal preference of avoiding node ecosystem, I would reach for golang if this was my goal. But if someone strongly prefers dynamic typing and wants to be prepared for heavy load, then node + js might be a strong candidate. I rarely see node + js, it's usually node + ts.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Well, depends on you needs (like always). If you're going to create any lambda (in AWS) or Cloud Function (in GCP) sure you'll use Node for convenience. The same occurs -usually- when working with websockets or specific async APIs which computational complexity makes unpreferable to use a more complex environment such JVM.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would add that Node JS is suitable for fast development and for relatively heavy loads, not just as no-OOP alternative (in which case you can use Python or any other multi-paradigm language).
And last but not least this sentence:
"nextjs - why isn't webpack sufficient? static rendering is not relevant for SPAs"
Shows a complete misunderstanding about this tech (both webpack and next JS) plus ignoring the fact we usually need SEO in public tools.
BTW you can build a monolith using Next JS as you can do both Node JS and React parts on it, which is suitable for many start-ups as a fast solution.
As devs we need to understand that business needs go first (are the ones paying our salaries at the end) and usually business needs, specially in a start up is to provide solutions and project evolutives as fast as possible.
I used nextjs for the last year building a static site, then a SPA. I didn't use it in a server side rendering case. Whenever people talk about build time rendering, the first question is if the data is specific to the user or not. If it is specific, like anything beyond the login page and some marketing landing pages, the build time rendering doesn't apply.
Of course that non-crawable paths are out of the equation. But there is a different use-case, when you've data which is public but logged in users see the content customised or more capabilities.
On the other hand Next help you with image optimization, pre-loading internal linked views, caching things up and the view presented is -usually- Interactive faster, so the user experience will be better anyway.
Agreed, I just don't usually work on apps that have this component.
Also, I think the nextjs/blitzjs zero API approach is somewhat novel (and I assume this is what people like the most), but it goes against my general lack of enthusiasm for isomorphic applications. I think inertia.js is a nice technology agnostic approach to achieving similar goals though.
I remember reading about this one. That is nice.
Given my personal preference of avoiding node ecosystem, I would reach for golang if this was my goal. But if someone strongly prefers dynamic typing and wants to be prepared for heavy load, then node + js might be a strong candidate. I rarely see node + js, it's usually node + ts.
Using TS is just a preference on development time and it has nothing to do with performance for obvious reasons.
Understand, I was just observing that node doesn't seem to be a hub for dynamic typing enthusiasts anymore, similar to clojure might be.
Well, depends on you needs (like always). If you're going to create any lambda (in AWS) or Cloud Function (in GCP) sure you'll use Node for convenience. The same occurs -usually- when working with websockets or specific async APIs which computational complexity makes unpreferable to use a more complex environment such JVM.