Ask HN: What programming language do you think is the best for Web Applications?
Gime me your thoughs :)
41 comments
JavaScript is a highly productive for Web Applications, although I also heavily use other alternatives for several reasons, But regardless, that is why it is my candidate for the best programming language especially working with the Web and Web applications in general. Anything beyond that is either niches or outside general purpose web. JavaScript can do:
- advance web applications (electron, NodeJS)
- ETL on the go (i.e. fetch, JSON, DOM, SVG)
- data visualization (i.e. d3, three.js, etc.)
- dependency management (i.e. NPM, CDN, ESM like in Deno)
- learning resources in general (extremely abundant and comprehensive on various sources)
It is hard not to learn JavaScript, it is almost everywhere. Also having to learn the 2nd or the 3rd programming language should also fill-in those gaps, even those huge gaps.
- advance web applications (electron, NodeJS)
- ETL on the go (i.e. fetch, JSON, DOM, SVG)
- data visualization (i.e. d3, three.js, etc.)
- dependency management (i.e. NPM, CDN, ESM like in Deno)
- learning resources in general (extremely abundant and comprehensive on various sources)
It is hard not to learn JavaScript, it is almost everywhere. Also having to learn the 2nd or the 3rd programming language should also fill-in those gaps, even those huge gaps.
JS is ubiquitous. It's also a primitive, sloppily-designed language that has caused untold economic damage. It's not as bad a language as, say, Perl, but it might be the single biggest thing holding back the Web as a platform today.
I do understand that it's not entirely fair to criticize it for being sloppy, since it was supposed to only be a stopgap to be used for a few years in the 1990s until the hypothetical better language came along. Perhaps WASM means this long wait is finally over, but I don't want to get my hopes up.
I do understand that it's not entirely fair to criticize it for being sloppy, since it was supposed to only be a stopgap to be used for a few years in the 1990s until the hypothetical better language came along. Perhaps WASM means this long wait is finally over, but I don't want to get my hopes up.
I'd say javascript is the new Perl (I used to love writing perl way back). It is undoubtedly useful, but can be horrific to read. It is heavily used to get things done in a pragmatic way.
The difference I see is that it will not likely die as quickly and quietly due to how distributed the code is.
The difference I see is that it will not likely die as quickly and quietly due to how distributed the code is.
Now that you mention it, the resemblance is pretty clear. I also have to admit that I agree that we probably are stuck with it for the future. There are languages I think much more highly of that compile to WASM, and that's a technique that I plan to use and that I anticipate gaining traction. But there's just so much JS around.
I do love Perl and JS for the same reasons: You can write something and be sure it will keep working. It is not customary to introduce breaking changes.
...Do you write in lots of languages that add breaking changes without warning? I don't.
I have encountered it with many languages. There is usually a warning, but there is also a lack of consent on my part, and a lack of options to retain compatibility.
For example, with most Python-based projects I have tried, I have run into some kind of version incompatibility, and often have not been able to get them to run at all.
This is an experience I wanted to avoid for those who try my software.
For example, with most Python-based projects I have tried, I have run into some kind of version incompatibility, and often have not been able to get them to run at all.
This is an experience I wanted to avoid for those who try my software.
> Python
Aha, there's your problem.
Aha, there's your problem.
That's exactly what I was talking about, and why I chose Perl as the "top-level" language for my project over Python, despite Python being very popular.
That would certainly be one solution.
I've been doing web development since the browser wars and Perl scripts sitting in a cgi-bin directory. The HTTP verbs haven't changed much in 20+ years. XHR (XML HTTP Request, aka async JS, aka AJAX) has been around for almost that long.
Ultimately it doesn't matter what internet commenters think, the best language is always going to be the one you are most comfortable and productive using. PHP, Python, Ruby, Elixir, .NET/C#, Java, Perl, JavaScript, etc. - all of them can accomplish the task of a running web application. I would lean towards an ecosystem that has lots of libraries to pick from and good documentation.
Ultimately it doesn't matter what internet commenters think, the best language is always going to be the one you are most comfortable and productive using. PHP, Python, Ruby, Elixir, .NET/C#, Java, Perl, JavaScript, etc. - all of them can accomplish the task of a running web application. I would lean towards an ecosystem that has lots of libraries to pick from and good documentation.
I'm very happy using Perl with web frameworks like Mojolicious, and database ORMs like DBIx::Class.
You can get a working prototype up quickly, and recent versions of Perl along with OO libraries like Moo/Moose allow you to quickly create well-written code.
There's also a lot of mature testing libraries.
You can get a working prototype up quickly, and recent versions of Perl along with OO libraries like Moo/Moose allow you to quickly create well-written code.
There's also a lot of mature testing libraries.
It depends on a lot of factors. Building a highly concurrent application such as chat? You may find node or elixir to be good fits. Building a reports service with lots of data crunching? Maybe checkout Python for it’s data libraries like Pandas / numpy. The choice of language stems from the domain you’re solving and what your team knows. Finding a happy middle ground is best, but sometimes you need to prefer either what the team already knows for the sake of time to market and other times you need to prioritize the problem space if the team’s knowledge has a limitation that will prevent it from being a maintainable solution.
Rust - https://rust-on-nails.com/
That name is brilliant.
Nice, if this plays out. I've been using Django. Prefer Rust as an overall language, but it currently (prior to this) only has Flask analogs.
There's no such thing. And anyone who thinks there is shouldn't be trusted with making technology choices.
A better question is: what languages and frameworks do you prefer for developing web applications, and why.
In a vacuum inside a perfect sphere, the answer is always Lisp.
In the real world, Elixir. On the frontend, the choice is just one, making it the worst and the best.
In the real world, Elixir. On the frontend, the choice is just one, making it the worst and the best.
Typescript. It's most utilizing the cutting edge web tech (Deno, Next, Serverless), succeeding in how best to deliver bytes between front-end and back-end (SSR, SSG, CSR, Edge, etc.), along with the biggest 3p ecosystem of packages/libraries you could find for almost all web and scripting tasks. You'll find no better integration with the front-end stacks rightfully used by almost all significant tech co's: React, Vue, Svelte.
There's a reason it's the biggest upward-trending lang:
https://insights.stackoverflow.com/trends?tags=typescript%2C...
There's a reason it's the biggest upward-trending lang:
https://insights.stackoverflow.com/trends?tags=typescript%2C...
Best is so subjective that it is impossible to say. Speed of execution is secondary to speed of development. Generally speaking.
Depends on what you mean by "best". If you mean best as in quick to launch, performant, and easy to maintain, then I'd say PHP because it was built specifically for web development.
The problem with PHP is that it's too easy to use and apps built with it have low maintenance costs. Which means that your ownership over a code base can easily be transferred to someone else.
If you want the best tech stack that will prevent you from killing the job, then I'd say Typescript or Java based API and a front-end framework like React. The more complex the code, the harder it will be to replace you and your team.
The problem with PHP is that it's too easy to use and apps built with it have low maintenance costs. Which means that your ownership over a code base can easily be transferred to someone else.
If you want the best tech stack that will prevent you from killing the job, then I'd say Typescript or Java based API and a front-end framework like React. The more complex the code, the harder it will be to replace you and your team.
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.
Depends, if you are trying to spin fast something working with simple business logic, you need a megalit like django, RoR or spring. If you are aiming for something with various microservices, go is the prefered solution nowadays.
Python, with Django, and Django Rest Framework. Steep initial learning curve, but its integration of many features (including auto DB migrations), great docs, and long-term track record.
Pharo + Seaside. For an introduction, see https://books.pharo.org/tinyblog-tutorial/
As other posters say: there is no best language for web applications. However, some languages have richer options for web programming - libraries and frameworks. Popularity also makes it's easier to find answers and tutorials. Other things to consider: ease of deployment, performance.
It's fine to use a programming language not normally known for web programming. Just remember if web-related libraries and documentation doesn't exist, you will need to write them yourself.
It's fine to use a programming language not normally known for web programming. Just remember if web-related libraries and documentation doesn't exist, you will need to write them yourself.
The best? The language you(and your team) know. If you understood most languages then I'd say Haskell or Rust depending on the exact requirements.
I enjoy ASP.Net Core and C#. Both development time and runtime are fast, most things feel architected and implemented well. And works in Linux.
In the Java sphere, Apache Wicket web framework beats anything I've seen before (in 20+ years of pro dev experience).
PHP is a great option to start with, but after a few years of working with the PHP, I'm slowly switching to a JS stack: NodeJS, NestJS, TypeScript, GraphQL.
It gives me much more fun than coding in a php, even with organized framework like Symfony.
The one you know. Or if you want to try something new, the one that has the best documentation.
In my experience, backends are dictated by the business logic, but I use Node when I can. I just move so much faster handling data naturally as JSON or using shared libraries for the frontend and backend objects.
Some popular choices: Python with Flask or Django, Ruby on Rails, Node.js, PHP.
Ruby (on Rails).
F#, I can target backend and frontend, using battle tested libraries.
Static typing that gets out of my way and has very good domain modeling capabilities.
Good enough tooling.
Scala as a close second!
Scala as a close second!
Dynamic languages and the fast changing pace of webapps go well together, lets say.
assembly language
php for backend and html with some js sprinkled on top for the front. if you need more, use htmx.
Ruby, Python, C#