31–40 of 61 posts
Python was supposed to kill PHP. Ruby on Rails was supposed to kill PHP. Now Javascript is supposed to kill PHP? Not a chance, at least in the near future.
At the end of the day, all of the languages being discussed here are all capable of achieving the same goals for 99% of the problems presented. Every language has its pros/cons and brings something new to the table that we usually see the others adopt.
Wordpress, drupal, magento, phabricator, mediawiki, sugarcrm... These are vastly popular, feature rich out of the box tools in PHP, aka the "killer apps". As I don't follow the node community, what are the killer apps on the node side? Im talking about a complete piece of software, where I would want to set up an environment not for development but for running an application.
PHP today is overwhelmingly being used to augment/modify: > Wordpress, drupal, magento, phabricator, mediawiki, sugarcrm... Very few apps are built from scratch using PHP unless the intention is to share the application code like wordpress, drupal, etc. On Node, you're almost always building from scratch, rather than creating plugins for an existing application. Apples and oranges. Different use cases.
I wrote this article so please don't too harsh ;) Crazy to see something I wrote for our company blog on the frontpage of HN this afternoon!
Personally I like these working arrangements and being able to dish up HTML safe in the knowledge that your frontend developer is getting what he needs complete with expected class tags and other markup to be styled. In the future it will probably be better for me as I won't be doing template files with fiddly PHP tags, instead I will be json encoding the requested data, e.g. an array of products. There is a whole lot of logic to getting that array of products, this you need the server for. Presentation of that data? That can be done with the new stuff. From this article I have a better idea of what might be the future.
Earlier quoted context omitted.
Personally, I'd say that the front-end tooling ecosystem constitutes the "killer app": - Minification: Uglify - Transpilation: Babel/TypeScript/CoffeeScript - JS Module Systems: Require/Browserify/Webpack/JSPM - CSS preprocessors: Less/Sass/Stylus - Linting: JSHint/ESLint/CSSLint If you're using a lot of front-end tools, you're using Node. And if you're using Node, you might as well use it to write your APIs.
I agree. At this time Javascript's biggest strength is build tools. It may not be as mature as PHP on the server, but there is so much community growth that I don't think it will be long catching up.
The fact that there's at least 4 "mainstream" build tools and their popularity changes every 6 months is a sign of an ecosystem with little stability that is no good to build a solid foundation.
On Ruby and Python land, how long has it been since RoR and Django have been the dominant players?
Python was supposed to kill PHP. Ruby on Rails was supposed to kill PHP. Now Javascript is supposed to kill PHP? Not a chance, at least in the near future.
And PHP was supposed to kill Perl. At the end of the day, all of the languages being discussed here are all capable of achieving the same goals for 99% of the problems presented. Every language has its pros/cons and brings something new to the table that we usually see the others adopt.
Python was supposed to kill PHP. Ruby on Rails was supposed to kill PHP. Now Javascript is supposed to kill PHP? Not a chance, at least in the near future.
Earlier quoted context omitted.
Very few? There's plenty of apps out there written in PHP. You can do the same thing in PHP as you can in node. Writing from scratch is no greater of a use case for using node than it is for PHP.
> There's plenty of apps out there written in PHP. Yes, there are. I didn't say there weren't. I think PHP is great, relax. In my professional experience, however, I don't see people start a codebase from scratch in PHP anymore. It's almost always based on Node.
I think the concurrency model provided by green threads in Go and Erlang is orders of magnitude easier to reason about, where you can write blocking I/O and the scheduler itself will take care of making sure that your code runs fine. The last thing I need when writing concurrent code is yet another thing to think about at every step of the way. This is a hugely underrated flaw in my opinion of node.js servers. With languages like Haskell, Rust, and Go we are seeing a trend of having smarter compilers and language runtimes making programs much easier to write, where I am offloading lots of things from my mind onto the compiler. The whole point of pre-emptive multi-tasking is to relieve the burden of "taking care not to block [the event loop]," and I think in that respect node.js is a step back.