5 ms·

What server language today except PHP (and its forks) is actually designed for the web and works as the web was intended? The implication of the question is th

What server language today except PHP (and its forks) is actually designed for the web and works as the web was intended? The implication of the question is that there's something designed into PHP that makes it better for working with web things. Why does the language need to be designed to work with the web? That part of any language can be filled out with a framework quite easily, and arguably that means it's much easier to change how the language is used. That seems to be the case with every major PHP application anyway - most use Laravel or Cake or Symphony or something. Just as most Ruby web projects use Rails, and most backend JS projects use Express, and Rust web projects use Poem, and so on. I don't think there's a good reason to design a language specifically for web projects. If that's how PHP works these days (I haven't used PHP in a decade or so), I'd suggest that might be a bad thing. It's very rigid, and if the language gets anything wrong that compromises the design of every project that uses it. Languages should provide simple primitives that frameworks and libraries build on.

capableweb 5y ago
> I don't think there's a good reason to design a language specifically for web projects. If that's how PHP works these days (I haven't used PHP in a decade or so), I'd suggest that might be a bad thing. It's very rigid, and if the language gets anything wrong that compromises the design of every project that uses it. Languages should provide simple primitives that frameworks and libraries build on. That has always been the goal of PHP, to be a web framework in itself (and now we have frameworks on top of that framework). It's trivial to read POST data as understanding POST requests are built-in into the language. With Rust or JavaScript you either will pull down a external library to handle that for you, or write a ton of code to make it easier for yourself. With PHP, it's literally one-line of code. It is not as rigid as you might believe, as we have frameworks on top of the native PHP framework already. That's not to say PHP is without compromises, it's not suitable for a bunch of different projects (you wouldn't write mobile/desktop apps with it for example). But if you have a simple CRUD application that just needs to output some HTML data and persist stuff to a MariaDB/MySQL database without wanting to pull down a bunch of 3rd-party dependencies, PHP will make that effortless compared to basically any other language. I think the popularity of PHP for web development speaks for itself, it basically conquered that segment of development when it first appeared, and is still more-or-less king, even with its warts. As a last word, I like that languages specializes in different things, not every language has to be a general-use language, and I hope we see more of that in the future. Darklang specializes in building backend APIs for example, others specializes in being for UIs and so on. As every language more or less looks like C today, there is plenty of room for innovation in programming language design (and no, not talking about TypeScript which is basically just C# that compiles to JavaScript, but more different languages).
- berkes 5y ago
  > That has always been the goal of PHP, to be a web framework in itself This is untrue. PHP was a templating language and form-handler first and foremost[1]. It took a long time for it to move out of that (I'd argue up to 5.6) and become an actual programming language rather than a template language on steroids. Edit: we still have to move out of template mode in every file by adding a <?php at the top of our files - and don't ever add a whitespace char before that, or else. So, essentially, we now have web-frameworks built in a templating language. With, ironically, template languages written in that templating language. Nice, if you like recursion though. [1] Early PHP was not intended to be a new programming language, and grew organically, with Lerdorf noting in retrospect: "I don't know how to stop it, there was never any intent to write a programming language - https://en.wikipedia.org/wiki/PHP#Early_history https://en.wikipedia.org/wiki/PHP#Early_history
  - capableweb 5y ago
    We're saying the same thing :) Templating language (for the web) and handle forms (on the web) makes PHP a web-language first and foremost. That's also the impression I get from reading the following section from the Wikipedia page you linked: > PHP development began in 1994 when Rasmus Lerdorf wrote several Common Gateway Interface (CGI) programs in C,[16][17] which he used to maintain his personal homepage. He extended them to work with web forms and to communicate with databases, and called this implementation "Personal Home Page/Forms Interpreter" or PHP/FI. He was working on his homepage (on the web) and wanted to make it easier to handle forms and communication with databases. That's basically everything the early web could do, and PHP aimed to make that easier.
    - berkes 5y ago
      I think I focused too much on the word framework, which is a vague word, and probably means a lot of different things depending on perspective. My reply was more to explain why I think it is not a framework, but rather a language, to handle web-stuff. But looking at it from other perspectives, that can be "framework" just fine.
berkes 5y ago
Continuing on Rails: It's suprising how little Rails does with the web. Rack is the layer handling the HTTP stuff. Which then sends its requests to ActionDispatch, which calls the correct ActionRouter. IMHO this is still too much HTTP, as I'd prefer to keep the entire HTTP out of my app, but after your routers, there's nothing "Web": it could all be "domain specific". Ruby, the language, is, indeed, hardly "Web" at all. Ruby stdlib has some HTTP stuff but that is both lacking and optional.
tored 5y ago
> That part of any language can be filled out with a framework quite easily Consequence of that is that every other language is de facto is dominated by one framework provider that you almost always have to use. That in it self is the basis for a stagnant community. Frameworks solves a general problem, you on the other hand solves a specific problem, sometimes those two are aligned, but many times they are not and then you are on your own. > I don't think there's a good reason to design a language specifically for web projects It definitely is because web has some unique properties and I think that one of the reason why we are unnecessarily shuffling JSON from backend to frontend where it is then transformed to HTML by async JavaScript (which gives a rather disjointed user experience), instead of sending a proper HTML document immediately from the server, because most backend languages suck when it comes to doing proper web. Thus the industry creates these band aid solutions that constantly makes both the web and web development worse. > language gets anything wrong that compromises the design of every project that uses it Language design is overrated when it comes to producing customer value. What is important is how the general architecture works * memory model (shared, per request, etc) * request model (by the app or by the web server) * resource model (mapping URL to file) * compilation/build step * deployment * hosting * tooling (IDEs, linters, testing, package manager, etc) * how to scale * available programmers * community PHP wins by these metrics. But if you want to have some fancy language feature to print out a proper HTML document, or what is more likely a JSON blob, go ahead, but it does not improve the end user experience at all.
simion314 5y ago
> Languages should provide simple primitives that frameworks and libraries build on. This had tons of disadvantages. Say CoolLang is such a language. Since is msall CoolLang has a micro standard library so has no DateTime or JSON, so you have a package manager and maybe 1 repo where 15 different JSON packages, you decide to use JSON_A but you also want to integrate with Amazon and they used JSON_B in their API and you also need to integrate with other API and this guys used JSON_A2 witch is an incompatible version of JSON_A. So now repeat for each web related function you have to decide for what package to use, if is compatible with whatever you use and review all it's dependencies, in the end you notice you depend on 100 packages and 3 years alter you have issues upgrading. You maybe now will complain that JSON is included and the solution is to use the CoolFramework_V13 for CoolLang, with is incompatible with previous versions and is based on 100 packages that could explode when some dev decides he had a bad day and purch is package.
- onion2k 5y ago
  CoolLang sounds a lot like JS.
  - simion314 5y ago
    There are more languages not only JS, with small standard library and the community offers multiple packages for same thing(like more packages for json) but you install them at your own risk - though this weaknesses are promoted by Cool.lang fanboys as features.
azangru 5y ago
> and Rust web projects use Poem Isn't Poem just... several months old? Your examples of frameworks for other languages are mature and established. Is the Rust ecosystem moving that fast?

capableweb 5y ago

> I don't think there's a good reason to design a language specifically for web projects. If that's how PHP works these days (I haven't used PHP in a decade or so), I'd suggest that might be a bad thing. It's very rigid, and if the language gets anything wrong that compromises the design of every project that uses it. Languages should provide simple primitives that frameworks and libraries build on. That has always been the goal of PHP, to be a web framework in itself (and now we have frameworks on top of that framework). It's trivial to read POST data as understanding POST requests are built-in into the language. With Rust or JavaScript you either will pull down a external library to handle that for you, or write a ton of code to make it easier for yourself. With PHP, it's literally one-line of code. It is not as rigid as you might believe, as we have frameworks on top of the native PHP framework already. That's not to say PHP is without compromises, it's not suitable for a bunch of different projects (you wouldn't write mobile/desktop apps with it for example). But if you have a simple CRUD application that just needs to output some HTML data and persist stuff to a MariaDB/MySQL database without wanting to pull down a bunch of 3rd-party dependencies, PHP will make that effortless compared to basically any other language. I think the popularity of PHP for web development speaks for itself, it basically conquered that segment of development when it first appeared, and is still more-or-less king, even with its warts. As a last word, I like that languages specializes in different things, not every language has to be a general-use language, and I hope we see more of that in the future. Darklang specializes in building backend APIs for example, others specializes in being for UIs and so on. As every language more or less looks like C today, there is plenty of room for innovation in programming language design (and no, not talking about TypeScript which is basically just C# that compiles to JavaScript, but more different languages).

berkes 5y ago
> That has always been the goal of PHP, to be a web framework in itself This is untrue. PHP was a templating language and form-handler first and foremost[1]. It took a long time for it to move out of that (I'd argue up to 5.6) and become an actual programming language rather than a template language on steroids. Edit: we still have to move out of template mode in every file by adding a <?php at the top of our files - and don't ever add a whitespace char before that, or else. So, essentially, we now have web-frameworks built in a templating language. With, ironically, template languages written in that templating language. Nice, if you like recursion though. [1] Early PHP was not intended to be a new programming language, and grew organically, with Lerdorf noting in retrospect: "I don't know how to stop it, there was never any intent to write a programming language - https://en.wikipedia.org/wiki/PHP#Early_history https://en.wikipedia.org/wiki/PHP#Early_history
- capableweb 5y ago
  We're saying the same thing :) Templating language (for the web) and handle forms (on the web) makes PHP a web-language first and foremost. That's also the impression I get from reading the following section from the Wikipedia page you linked: > PHP development began in 1994 when Rasmus Lerdorf wrote several Common Gateway Interface (CGI) programs in C,[16][17] which he used to maintain his personal homepage. He extended them to work with web forms and to communicate with databases, and called this implementation "Personal Home Page/Forms Interpreter" or PHP/FI. He was working on his homepage (on the web) and wanted to make it easier to handle forms and communication with databases. That's basically everything the early web could do, and PHP aimed to make that easier.
  - berkes 5y ago
    I think I focused too much on the word framework, which is a vague word, and probably means a lot of different things depending on perspective. My reply was more to explain why I think it is not a framework, but rather a language, to handle web-stuff. But looking at it from other perspectives, that can be "framework" just fine.

berkes 5y ago

Continuing on Rails: It's suprising how little Rails does with the web. Rack is the layer handling the HTTP stuff. Which then sends its requests to ActionDispatch, which calls the correct ActionRouter. IMHO this is still too much HTTP, as I'd prefer to keep the entire HTTP out of my app, but after your routers, there's nothing "Web": it could all be "domain specific". Ruby, the language, is, indeed, hardly "Web" at all. Ruby stdlib has some HTTP stuff but that is both lacking and optional.

tored 5y ago

> That part of any language can be filled out with a framework quite easily Consequence of that is that every other language is de facto is dominated by one framework provider that you almost always have to use. That in it self is the basis for a stagnant community. Frameworks solves a general problem, you on the other hand solves a specific problem, sometimes those two are aligned, but many times they are not and then you are on your own. > I don't think there's a good reason to design a language specifically for web projects It definitely is because web has some unique properties and I think that one of the reason why we are unnecessarily shuffling JSON from backend to frontend where it is then transformed to HTML by async JavaScript (which gives a rather disjointed user experience), instead of sending a proper HTML document immediately from the server, because most backend languages suck when it comes to doing proper web. Thus the industry creates these band aid solutions that constantly makes both the web and web development worse. > language gets anything wrong that compromises the design of every project that uses it Language design is overrated when it comes to producing customer value. What is important is how the general architecture works * memory model (shared, per request, etc) * request model (by the app or by the web server) * resource model (mapping URL to file) * compilation/build step * deployment * hosting * tooling (IDEs, linters, testing, package manager, etc) * how to scale * available programmers * community PHP wins by these metrics. But if you want to have some fancy language feature to print out a proper HTML document, or what is more likely a JSON blob, go ahead, but it does not improve the end user experience at all.

simion314 5y ago

> Languages should provide simple primitives that frameworks and libraries build on. This had tons of disadvantages. Say CoolLang is such a language. Since is msall CoolLang has a micro standard library so has no DateTime or JSON, so you have a package manager and maybe 1 repo where 15 different JSON packages, you decide to use JSON_A but you also want to integrate with Amazon and they used JSON_B in their API and you also need to integrate with other API and this guys used JSON_A2 witch is an incompatible version of JSON_A. So now repeat for each web related function you have to decide for what package to use, if is compatible with whatever you use and review all it's dependencies, in the end you notice you depend on 100 packages and 3 years alter you have issues upgrading. You maybe now will complain that JSON is included and the solution is to use the CoolFramework_V13 for CoolLang, with is incompatible with previous versions and is based on 100 packages that could explode when some dev decides he had a bad day and purch is package.

onion2k 5y ago
CoolLang sounds a lot like JS.
- simion314 5y ago
  There are more languages not only JS, with small standard library and the community offers multiple packages for same thing(like more packages for json) but you install them at your own risk - though this weaknesses are promoted by Cool.lang fanboys as features.

azangru 5y ago

> and Rust web projects use Poem Isn't Poem just... several months old? Your examples of frameworks for other languages are mature and established. Is the Rust ecosystem moving that fast?