11 ms·

I think enough time has passed that we're collectively forgetting the good reasons why so many moved from server side rendering, which I would say it was mostly

I think enough time has passed that we're collectively forgetting the good reasons why so many moved from server side rendering, which I would say it was mostly the difficulty in make complex uis. Then it became a trend, now going old school seems appealing. Anyway in my particular case if I had any project that was a good fit for server side rendering I would probably now go with php and some libraries but probably no framework. I've been looking at some "weirdly coded 90's style php projects". An while the code is a terrible mess there's also the magic that I can read everything that's happening pretty quickly because it's just there or in a file next to it and not hidden in a library and a sub-library with calls to functions that I never seen before.

cies 6y ago
> I would probably now go with php seriously? 2020 and you'd pick php for a greenfield project? and you mention this here, where we're discussing a project that provides: strong typing, typed safe queries, type safe templates, and more. interesting.
- radisb 6y ago
  I love when people are shocked because someone decides which tech to use based on the merits of the tech instead of what the current year tech fashion dictates. It's hilarious.
  - tluyben2 6y ago
    Or, you know, simple things like being able to easily attract people. No matter how I prefer Purescript/Haskell/Ocaml/F#/k or even Idris (not practical but I like writing things in it); if I need people fast, PHP/C#/TypeScript are just a better bet (I am surprised how easy it is to find good people with these skills now; seems unemployment hit these as well?). But it depends on what you are doing ofcourse.
    - cies 6y ago
      > if I need people fast Exactly, this is a real reason for not using the technologically superior.
      - megiddo 6y ago
        It's a fantastic reason. Writing code is a job. A well-run business is dictated by factors that will usually dominate language design. If these other languages were better in a holistic sense, businesses would switch. I would argue against the "technically superior" position on three merits: 1. Finance, 2. Median productivity 3. Long-term product stability Network effects mean that familiar languages will dominate. PHP, C#, and Javascript are familiar. PHP has had staying power because it is extremely well-documented (with examples) for the novice, prioritizes backwards compatibility, and is reasonably if not very productive for most developers. The documentation section of PHP.net is probably the most important language "feature" of PHP - it trumps almost any language design feature you think is important. It reads easily. It's easy to implement. It interacts natively with JSON in a completely fluid way. The database handling routines are rock solid and fast. The core language team spends a lot time improving the safety and performance of existing code. There's a good debug story. It's its own templating language - no need to bolt on a hand-rolled templating mechanism. Just PHP all the way down. It prioritizes language features (reflection) that make writing libraries and frameworks easier. It promotes building reusable tools. Important features are pulled directly into the runtime, based on popularity in the ecosystem. The kitchen sink is included and it's portable. Basically, it's a language that has been developed by people who actually have to build and maintain projects over a long period of time. A useful language is more than it's design.
        cies 6y ago
        So why do I see it going down the hole that Perl and ColdFusion are already occupying? I see the other side: it's a sinking ship. FB comes to rescue PHP, but internally seems to like anything but PHP for greenfield projects: Java, C++, Erlang (chat msg broker), OCaml/Reason (messenger.com app), even Haskell is used for some spam filtering tool.
      - 6y ago
  - cies 6y ago
    > the merits of the tech In relation to PHP, really? Sure it has come a long way recently, but there's too much still in there that can never be fixed. I dont think what IHP delivers is some sort of "fashion": they choose to be server-side only, pretty old school. The typing discipline is not very fashionable either: old, time tested, established, but not often leveraged for the development of simple websites/webapps.
- purerandomness 6y ago
  Today's PHP projects (at least the ones for which I've done consulting) are modern and clean code bases that use strict/strong typing, run static analysers and have stellar package management thanks to composer. PHP 8 is due to be released this fall which improves the situation even more. Symfone is the web framework that had the highest count of contributions over all frameworks in all languages. The PHP community took a 180 degree turn from the 90's style flat files with a mix of HTML, SQL and code in the last decade. That times are gone (of course that kind of code is still laying around) For someone who already knows PHP, starting a project in 2020/2021 in PHP is an excellent choice.
  - cies 6y ago
    Which other languages are you fluent with? I find many that love PHP have a bit of a "when all you've got is a hammer" bias in favor of it. I had the same! Then I invested in learning some Haskell/ Elm/ Reason/ Rust/ Kotlin: it changed my preferences for ever. I now look for proper sum types and (pattern) matchers, strong typing discipline and null safety.
    - purerandomness 6y ago
      I totally agree with what you're saying. While PHP is still a joke compared to even Java which it very hard tries to become (which I think is a good thing), for someone who only knew PHP the entire time, the situation still got much, much better over the last decade...
    - weego 6y ago
      I use Scala, Typescript, R, some Go and some Swift daily and have been using typed languages for 20 years+ and would still recommend PHP to someone wanting to throw together a brochureware site for the best cost/hassle ratio. Almost no one is solving FANG problems, and people literally throw their clients/businesses money away on poor value because they've lost focus on what's important: delivering a solution for what they need right now, not what you want to spend your time playing with. Also what is the big deal with type safe templates when you're literally just abstracting building HTML strings?
    - 6y ago
mhoad 6y ago
I think the problem here is that you are setting up a situation where it is some binary choice between the insane complexity of SPAs and everything that entails and some random 90s style hand rolled PHP file. There are a whole bunch of options between those two extremes and I can’t for the life of me think why people don’t talk about them more often. For example, I think the new Hey.com implementation hasn’t received anywhere near the level of recognition that it probably should have. It’s an entire email application with a single set of screens that power all web, desktop and mobile apps, does so with all the speed of an SPA, has no need for advanced state management, has the ability to push live updates on a per component basis on any screen and does it all in under 40kb of JavaScript. Seriously go and look at the source code. I’ve only seen a tiny number of people talking about it like in this post https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technology-iii-turbolinks-frames-5e4a https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technol... But to me the past few years of SPAs are starting to look more and more like a mistake to me where they became the rule when they should have probably been the exception.
- DougBTX 6y ago
  Here's the library they've written: https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
  - mhoad 6y ago
    For the record it is worth mentioning that there is a major update pending for that library that handles some of the specific things outlined in the post I referenced above, however, even in its current iteration I think it is a much more sensible default to reach for than say React & Redux would be for a large number of applications. There is a second library that they have used along side that for handling all of the app specific JavaScript here as well https://stimulusjs.org/ https://stimulusjs.org/
- fastball 6y ago
  Unfortunately it is hard for me to comment on the hey.com web app as they currently have restrictive registration. The benefit of building with a de-coupled JS frontend (SPA) and an API is that it can extended and adapted far easier than using server-delivered HTML. If you have an API that delivers JSON/Protobuf/whatever, you can easily make new interfaces to that backend. If you are currently delivering a web app in HTML/JS, but decide you want a native Mac/iOS app written in Swift, you'll just end up building an API anyway. Sure, there are plenty of websites that wont ever need additional interfaces, but if your goal is to make an app that can easily have new interfaces added to the mix, de-coupling is the way to start in my opinion.
tantaman 6y ago
Tech is a circle that goes round and round. Remember when everyone thought NoSQL was a good idea and wanted to get rid of their relational DBs? Nobody remembered _why_ we went to relational DBs until after all of their data was duplicated and inconsistent in NoSQL solutions. I think the root of this is a lack of appreciation for or lack of knowledge of the history of software engineering.

cies 6y ago

> I would probably now go with php seriously? 2020 and you'd pick php for a greenfield project? and you mention this here, where we're discussing a project that provides: strong typing, typed safe queries, type safe templates, and more. interesting.

radisb 6y ago
I love when people are shocked because someone decides which tech to use based on the merits of the tech instead of what the current year tech fashion dictates. It's hilarious.
- tluyben2 6y ago
  Or, you know, simple things like being able to easily attract people. No matter how I prefer Purescript/Haskell/Ocaml/F#/k or even Idris (not practical but I like writing things in it); if I need people fast, PHP/C#/TypeScript are just a better bet (I am surprised how easy it is to find good people with these skills now; seems unemployment hit these as well?). But it depends on what you are doing ofcourse.
  - cies 6y ago
    > if I need people fast Exactly, this is a real reason for not using the technologically superior.
    - megiddo 6y ago
      It's a fantastic reason. Writing code is a job. A well-run business is dictated by factors that will usually dominate language design. If these other languages were better in a holistic sense, businesses would switch. I would argue against the "technically superior" position on three merits: 1. Finance, 2. Median productivity 3. Long-term product stability Network effects mean that familiar languages will dominate. PHP, C#, and Javascript are familiar. PHP has had staying power because it is extremely well-documented (with examples) for the novice, prioritizes backwards compatibility, and is reasonably if not very productive for most developers. The documentation section of PHP.net is probably the most important language "feature" of PHP - it trumps almost any language design feature you think is important. It reads easily. It's easy to implement. It interacts natively with JSON in a completely fluid way. The database handling routines are rock solid and fast. The core language team spends a lot time improving the safety and performance of existing code. There's a good debug story. It's its own templating language - no need to bolt on a hand-rolled templating mechanism. Just PHP all the way down. It prioritizes language features (reflection) that make writing libraries and frameworks easier. It promotes building reusable tools. Important features are pulled directly into the runtime, based on popularity in the ecosystem. The kitchen sink is included and it's portable. Basically, it's a language that has been developed by people who actually have to build and maintain projects over a long period of time. A useful language is more than it's design.
      - cies 6y ago
        So why do I see it going down the hole that Perl and ColdFusion are already occupying? I see the other side: it's a sinking ship. FB comes to rescue PHP, but internally seems to like anything but PHP for greenfield projects: Java, C++, Erlang (chat msg broker), OCaml/Reason (messenger.com app), even Haskell is used for some spam filtering tool.
    - 6y ago
- cies 6y ago
  > the merits of the tech In relation to PHP, really? Sure it has come a long way recently, but there's too much still in there that can never be fixed. I dont think what IHP delivers is some sort of "fashion": they choose to be server-side only, pretty old school. The typing discipline is not very fashionable either: old, time tested, established, but not often leveraged for the development of simple websites/webapps.
purerandomness 6y ago
Today's PHP projects (at least the ones for which I've done consulting) are modern and clean code bases that use strict/strong typing, run static analysers and have stellar package management thanks to composer. PHP 8 is due to be released this fall which improves the situation even more. Symfone is the web framework that had the highest count of contributions over all frameworks in all languages. The PHP community took a 180 degree turn from the 90's style flat files with a mix of HTML, SQL and code in the last decade. That times are gone (of course that kind of code is still laying around) For someone who already knows PHP, starting a project in 2020/2021 in PHP is an excellent choice.
- cies 6y ago
  Which other languages are you fluent with? I find many that love PHP have a bit of a "when all you've got is a hammer" bias in favor of it. I had the same! Then I invested in learning some Haskell/ Elm/ Reason/ Rust/ Kotlin: it changed my preferences for ever. I now look for proper sum types and (pattern) matchers, strong typing discipline and null safety.
  - purerandomness 6y ago
    I totally agree with what you're saying. While PHP is still a joke compared to even Java which it very hard tries to become (which I think is a good thing), for someone who only knew PHP the entire time, the situation still got much, much better over the last decade...
  - weego 6y ago
    I use Scala, Typescript, R, some Go and some Swift daily and have been using typed languages for 20 years+ and would still recommend PHP to someone wanting to throw together a brochureware site for the best cost/hassle ratio. Almost no one is solving FANG problems, and people literally throw their clients/businesses money away on poor value because they've lost focus on what's important: delivering a solution for what they need right now, not what you want to spend your time playing with. Also what is the big deal with type safe templates when you're literally just abstracting building HTML strings?
  - 6y ago

mhoad 6y ago

I think the problem here is that you are setting up a situation where it is some binary choice between the insane complexity of SPAs and everything that entails and some random 90s style hand rolled PHP file. There are a whole bunch of options between those two extremes and I can’t for the life of me think why people don’t talk about them more often. For example, I think the new Hey.com implementation hasn’t received anywhere near the level of recognition that it probably should have. It’s an entire email application with a single set of screens that power all web, desktop and mobile apps, does so with all the speed of an SPA, has no need for advanced state management, has the ability to push live updates on a per component basis on any screen and does it all in under 40kb of JavaScript. Seriously go and look at the source code. I’ve only seen a tiny number of people talking about it like in this post https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technology-iii-turbolinks-frames-5e4a https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technol... But to me the past few years of SPAs are starting to look more and more like a mistake to me where they became the rule when they should have probably been the exception.

DougBTX 6y ago
Here's the library they've written: https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
- mhoad 6y ago
  For the record it is worth mentioning that there is a major update pending for that library that handles some of the specific things outlined in the post I referenced above, however, even in its current iteration I think it is a much more sensible default to reach for than say React & Redux would be for a large number of applications. There is a second library that they have used along side that for handling all of the app specific JavaScript here as well https://stimulusjs.org/ https://stimulusjs.org/
fastball 6y ago
Unfortunately it is hard for me to comment on the hey.com web app as they currently have restrictive registration. The benefit of building with a de-coupled JS frontend (SPA) and an API is that it can extended and adapted far easier than using server-delivered HTML. If you have an API that delivers JSON/Protobuf/whatever, you can easily make new interfaces to that backend. If you are currently delivering a web app in HTML/JS, but decide you want a native Mac/iOS app written in Swift, you'll just end up building an API anyway. Sure, there are plenty of websites that wont ever need additional interfaces, but if your goal is to make an app that can easily have new interfaces added to the mix, de-coupling is the way to start in my opinion.

tantaman 6y ago

Tech is a circle that goes round and round. Remember when everyone thought NoSQL was a good idea and wanted to get rid of their relational DBs? Nobody remembered _why_ we went to relational DBs until after all of their data was duplicated and inconsistent in NoSQL solutions. I think the root of this is a lack of appreciation for or lack of knowledge of the history of software engineering.