6 ms·

So, should we stick to PHP for web stuff or is JS here to stay ?

by johnchristopher 8y ago

entropie 8y ago
I remember a time where javascript was somehow called "old" and obsolete and pretty anyone hated it.
- kllrnohj 8y ago
  JavaScript prior to ES6 was "old" and obsolete and hated. Building JS objects pre-classes is pretty terrible (to say nothing of the .bind(this) that is spammed everywhere without the => operator) JS has improved massively over the last few years, it's very nearly an entirely different language than what it used to be. There's a reason everyone was desperate to avoid writing JS not all that long ago be it the form of coffeescript, silverlight, flash, or GWT. ES5 JS sucks. Like... a lot.
  - lgunsch 8y ago
    Interesting. I haven't touched, or even read, any JavaScript since well before ES6 arrived. I suppose I don't really know the language if it's changed so much (I've never even heard of JavaScript classes). I jumped on the JavaScript hater train and left the station.
    - avarun 8y ago
      >I jumped on the JavaScript hater train and left the station. As does most of Hacker News with every technology they hate on.
samsonradu 8y ago
I’d still pick PHP between the two for usual web apps. There is beauty in the statelessness of PHP and also leverage on Nginx (+ Lua) for more critical and high-speed work. The issue I have with Node JS is that the entire ecosystem moves way too fast. However, when I need realtime interaction via WebSockets fe. it really feels like a good choice.
- eropple 8y ago
  The notion that the node.js ecosystem moves way too fast is a time-traveling statement from, like, 2012. When it really was, in a lot of ways, true. But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago. They're also mostly the same tools you would have seen five years ago, and plenty of people use "old" tools completely and perfectly acceptably. You don't have to throw out Grunt if you like it, you don't have to rush onto Parcel if Webpack works for you. Because other people still use them and other people still maintain them. Node is no less stable, today, than Ruby or PHP, and is only arguably less stable than Python because Python has largely ossified. SQL database usage is still an ongoing bummer, though.
  - randomsofr 8y ago
    I just had a project crash that was setup on 2015 (using gulp), i had to update one dependency and that dependency forced me to update the entire package.json to latest versions, so i had to fix the entire build setup and config files. Same happened with a Rails/React project that was setup last year, i tried to update one package that was marked as vulnerable, but it ended up requiring the same thing. I opted to leave that package. I've been working with node for a long time, but i feel like is the same level of stability since the start. Thats very different with Ruby or PHP, you can have old setups working just fine, maybe requiring some extra steps to build certain dependencies but overall working.
    - eropple 8y ago
      1) React is frontend JS which can be consumed on the server side--but I think a reasonable person might hang Express on Node and raise eyebrows at React. 2) Can you explain to me how updating a Gemfile or composer.json file is not going to result in a similar dependency cascade? 'Cause, from experience, it certainly will if the project isn't dead. About the only environment I've ever worked in where keeping up on your dependencies on a regular basis isn't required is a Java one--and that's assuming you don't care that much about security patches.
benologist 8y ago
Maybe we could commit to a longer duration with every major change, develop expertise and contribute to improving that solution.
- chillingeffect 8y ago
  the model in GP is useful, but it doesn't account for the unequal distribution of information. e.g. some people are perceiving the cycle at a different phase and can be convinced to work "harder, not smart" for an interval to shift their position within the cycle. E.g. "Let's get really good at microservices so we don't need a monolith." IOW there's no consensus about when to dig in and go deeper. And even if there was, some people would leverage that information and try to pull ahead of the others digging in.
deleted 8y ago
[deleted]
Zooper 8y ago
WebAssembly.
- endless1234 8y ago
  Webassembly instead of PHP/js? How?
  - pjmlp 8y ago
    Like this, http://example.qt.io/qt-webassembly/quickcontrols2/gallery/gallery.html http://example.qt.io/qt-webassembly/quickcontrols2/gallery/g...
- SahAssar 8y ago
  WebAssembly is a compiler target, not a language you write.
knicholes 8y ago
Stick to whatever works for you. I'm assuming you mean backend JS, but if you don't, you can use both. PHP can render your page and JS can make it interactive. I can see benefits of being able to re-use models for frontend and backend, though.
nevir 8y ago
This argument is less about specific technologies, and more about patterns and practices. For example: web UI started as declarative (HTML -> PHP), and then transitioned towards more imperative (jQuery, Backbone, Angular), and is now moving back towards declarative (React, Polymer)
- sanderjd 8y ago
  I don't really understand calling Perl declarative... I would consider the Perl CGI services I used to work on to be quite a bit more imperative than the Rails applications I've worked on. Similar with PHP, though I can see where peppering the imperative code into the declarative HTML could be considered more declarative.
  - nevir 8y ago
    Yeah, sorry, Perl is probably a bad example (I was really thinking of Mason, and even then it's a bad example). Pulled that from the list!
- chrisco255 8y ago
  There's nothing declarative about HTML except for its extremely limited use case of rendering text.
  - nevir 8y ago
    HTML is purely declarative. Each HTML document describes what it wants to have rendered, but does not describe how it should be rendered.
    - tabtab 8y ago
      In theory, maybe. In practice, no. I've been round and round on ADA issues, and there is no clear distinction between "meaning" and "presentation". Clean separation is either a pipe dream, or too complex for most mortals to get right. I should become an ADA lawyer because I can now pop the purists' BS and win case$.
tetha 8y ago
Make fun of PHP as much as I like or liked to. But I have some easily readable, rock-solid, easily operated php applications in my infrastructure.
- tabtab 8y ago
  I believe good architectures/stacks depend far more on the skill of the architects than the languages involved. Domain fit also matters. As far as PHP, it's an ugly language from a language-only perspective, but easy to deploy and has lots of existing web-oriented libraries/functions. Think of PHP has a glue language for its libraries and some front-end JavaScript to improve the UI. Python and server-side JavaScript may someday catch up, but still have a lot of ground to make up.
  - codedokode 8y ago
    PHP might be not the best designed or nice looking language out there, but you cannot even compare it to JS. It has real classes, doesn't require you to put underscore before private methods and type checking. And it issues a warning if you divide by zero or try to access array index that doesn't exist
    - shub 8y ago
      Is `empty("0")` still true in PHP?
      - tabtab 8y ago
        "blank" and "empty" are not the same thing in PHP. If you expect them to be, then you read the manual wrong. I generally include a set of common utilities where I define my own "isBlank()" function, which trims before comparing. There are different definitions of "blank" such that one size may not fit all. (Consider tabs and line-feed characters, for example.)
lafar6502 8y ago
just check if you dont already have js, python, bower, gulp, yoman and 20 others in your repo

So, should we stick to PHP for web stuff or is JS here to stay ?

entropie 8y ago

I remember a time where javascript was somehow called "old" and obsolete and pretty anyone hated it.

kllrnohj 8y ago
JavaScript prior to ES6 was "old" and obsolete and hated. Building JS objects pre-classes is pretty terrible (to say nothing of the .bind(this) that is spammed everywhere without the => operator) JS has improved massively over the last few years, it's very nearly an entirely different language than what it used to be. There's a reason everyone was desperate to avoid writing JS not all that long ago be it the form of coffeescript, silverlight, flash, or GWT. ES5 JS sucks. Like... a lot.
- lgunsch 8y ago
  Interesting. I haven't touched, or even read, any JavaScript since well before ES6 arrived. I suppose I don't really know the language if it's changed so much (I've never even heard of JavaScript classes). I jumped on the JavaScript hater train and left the station.
  - avarun 8y ago
    >I jumped on the JavaScript hater train and left the station. As does most of Hacker News with every technology they hate on.

samsonradu 8y ago

I’d still pick PHP between the two for usual web apps. There is beauty in the statelessness of PHP and also leverage on Nginx (+ Lua) for more critical and high-speed work. The issue I have with Node JS is that the entire ecosystem moves way too fast. However, when I need realtime interaction via WebSockets fe. it really feels like a good choice.

eropple 8y ago
The notion that the node.js ecosystem moves way too fast is a time-traveling statement from, like, 2012. When it really was, in a lot of ways, true. But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago. They're also mostly the same tools you would have seen five years ago, and plenty of people use "old" tools completely and perfectly acceptably. You don't have to throw out Grunt if you like it, you don't have to rush onto Parcel if Webpack works for you. Because other people still use them and other people still maintain them. Node is no less stable, today, than Ruby or PHP, and is only arguably less stable than Python because Python has largely ossified. SQL database usage is still an ongoing bummer, though.
- randomsofr 8y ago
  I just had a project crash that was setup on 2015 (using gulp), i had to update one dependency and that dependency forced me to update the entire package.json to latest versions, so i had to fix the entire build setup and config files. Same happened with a Rails/React project that was setup last year, i tried to update one package that was marked as vulnerable, but it ended up requiring the same thing. I opted to leave that package. I've been working with node for a long time, but i feel like is the same level of stability since the start. Thats very different with Ruby or PHP, you can have old setups working just fine, maybe requiring some extra steps to build certain dependencies but overall working.
  - eropple 8y ago
    1) React is frontend JS which can be consumed on the server side--but I think a reasonable person might hang Express on Node and raise eyebrows at React. 2) Can you explain to me how updating a Gemfile or composer.json file is not going to result in a similar dependency cascade? 'Cause, from experience, it certainly will if the project isn't dead. About the only environment I've ever worked in where keeping up on your dependencies on a regular basis isn't required is a Java one--and that's assuming you don't care that much about security patches.

benologist 8y ago

Maybe we could commit to a longer duration with every major change, develop expertise and contribute to improving that solution.

chillingeffect 8y ago
the model in GP is useful, but it doesn't account for the unequal distribution of information. e.g. some people are perceiving the cycle at a different phase and can be convinced to work "harder, not smart" for an interval to shift their position within the cycle. E.g. "Let's get really good at microservices so we don't need a monolith." IOW there's no consensus about when to dig in and go deeper. And even if there was, some people would leverage that information and try to pull ahead of the others digging in.

deleted 8y ago

[deleted]

Zooper 8y ago

WebAssembly.

endless1234 8y ago
Webassembly instead of PHP/js? How?
- pjmlp 8y ago
  Like this, http://example.qt.io/qt-webassembly/quickcontrols2/gallery/gallery.html http://example.qt.io/qt-webassembly/quickcontrols2/gallery/g...
SahAssar 8y ago
WebAssembly is a compiler target, not a language you write.

knicholes 8y ago

Stick to whatever works for you. I'm assuming you mean backend JS, but if you don't, you can use both. PHP can render your page and JS can make it interactive. I can see benefits of being able to re-use models for frontend and backend, though.

nevir 8y ago

This argument is less about specific technologies, and more about patterns and practices. For example: web UI started as declarative (HTML -> PHP), and then transitioned towards more imperative (jQuery, Backbone, Angular), and is now moving back towards declarative (React, Polymer)

sanderjd 8y ago
I don't really understand calling Perl declarative... I would consider the Perl CGI services I used to work on to be quite a bit more imperative than the Rails applications I've worked on. Similar with PHP, though I can see where peppering the imperative code into the declarative HTML could be considered more declarative.
- nevir 8y ago
  Yeah, sorry, Perl is probably a bad example (I was really thinking of Mason, and even then it's a bad example). Pulled that from the list!
chrisco255 8y ago
There's nothing declarative about HTML except for its extremely limited use case of rendering text.
- nevir 8y ago
  HTML is purely declarative. Each HTML document describes what it wants to have rendered, but does not describe how it should be rendered.
  - tabtab 8y ago
    In theory, maybe. In practice, no. I've been round and round on ADA issues, and there is no clear distinction between "meaning" and "presentation". Clean separation is either a pipe dream, or too complex for most mortals to get right. I should become an ADA lawyer because I can now pop the purists' BS and win case$.

tetha 8y ago

Make fun of PHP as much as I like or liked to. But I have some easily readable, rock-solid, easily operated php applications in my infrastructure.

tabtab 8y ago
I believe good architectures/stacks depend far more on the skill of the architects than the languages involved. Domain fit also matters. As far as PHP, it's an ugly language from a language-only perspective, but easy to deploy and has lots of existing web-oriented libraries/functions. Think of PHP has a glue language for its libraries and some front-end JavaScript to improve the UI. Python and server-side JavaScript may someday catch up, but still have a lot of ground to make up.
- codedokode 8y ago
  PHP might be not the best designed or nice looking language out there, but you cannot even compare it to JS. It has real classes, doesn't require you to put underscore before private methods and type checking. And it issues a warning if you divide by zero or try to access array index that doesn't exist
  - shub 8y ago
    Is `empty("0")` still true in PHP?
    - tabtab 8y ago
      "blank" and "empty" are not the same thing in PHP. If you expect them to be, then you read the manual wrong. I generally include a set of common utilities where I define my own "isBlank()" function, which trims before comparing. There are different definitions of "blank" such that one size may not fit all. (Consider tabs and line-feed characters, for example.)

lafar6502 8y ago

just check if you dont already have js, python, bower, gulp, yoman and 20 others in your repo