Re:Ask HN: What programming language do you think is the bes...
by solardev on Saturday October 08, 2022 @01:26PM
(#33134199)
The language doesn't matter, what does is your ability to deliver on user and business needs with the resources you have access to.
Often times that's more about a framework than a language, or about the level of abstraction you want to deal with on the backend, or how you intend to scale, and what sort of shop you're at and what kind of devs you have. More often than not, unless you're a greenfield project or a startup, some or all of those decisions have already been made.
Compare two different approaches...
One, a traditional LEMP stack with server side interactivity and rendering. You define every layer of the stack, managing everything from the database to the CDN yourself. You deliver HTML to browsers with a sprinkling of Javascript for pagination or whatever.
Two, a Jamstack running on something like Next and hosted on Vercel, using some sort of headless CMS maintained by another vendor.
(You can substitut LEMP with any similar stack, or Next with any other Jamstack framework in any language).
But the levels of abstraction there are very different, as are your dev and infrastructure costs, as is the user and developer experience. And ecosystem support, everything from third-party packages to Stack answers. Everything gets compiled down to shades of HTML and Javascript anyway, it doesn't really matter what you start out with. The stack and its ecosystem will have way more impact on your final experience.
Most web apps are light on fancy algorithms and heavy on presentation. You're usually building documents more than apps. The tradeoffs you encounter are often between interactivity and infrastructure. Whatever stack you choose that lets you focus on that, without sacrificing business needs, is a good choice.
Often times that's more about a framework than a language, or about the level of abstraction you want to deal with on the backend, or how you intend to scale, and what sort of shop you're at and what kind of devs you have. More often than not, unless you're a greenfield project or a startup, some or all of those decisions have already been made.
Compare two different approaches...
One, a traditional LEMP stack with server side interactivity and rendering. You define every layer of the stack, managing everything from the database to the CDN yourself. You deliver HTML to browsers with a sprinkling of Javascript for pagination or whatever.
Two, a Jamstack running on something like Next and hosted on Vercel, using some sort of headless CMS maintained by another vendor.
(You can substitut LEMP with any similar stack, or Next with any other Jamstack framework in any language).
But the levels of abstraction there are very different, as are your dev and infrastructure costs, as is the user and developer experience. And ecosystem support, everything from third-party packages to Stack answers. Everything gets compiled down to shades of HTML and Javascript anyway, it doesn't really matter what you start out with. The stack and its ecosystem will have way more impact on your final experience.
Most web apps are light on fancy algorithms and heavy on presentation. You're usually building documents more than apps. The tradeoffs you encounter are often between interactivity and infrastructure. Whatever stack you choose that lets you focus on that, without sacrificing business needs, is a good choice.