I get that this article is satire, but I think the deepest (perhaps) unintentional insight presented by the author's veiled criticism is that the justification for using these tools is presented as "it's 2017" and not as a solution to any particular problem. The issue isn't the 2017 ecosystem, the issue is the 2017 programmer's deference to vanity instead of engineering. All these individual tools exist for a reason, and if your project is already functioning to specification without the use of these tools, you shouldn't be using them; doing otherwise is the developer's fault, not the tool's or the ecosystem's.
The combination definitely seems overwhelming, but each tool is a solution to a real problem. That's where the "(real)" in the title is coming from. Yes, if you're only writing a hello world app you certainly don't need all that bloat, but if you're writing a real world app, here's a list of legitimate requirements you have to fulfill:
1. You offered your client a static page with purple background, blinking title, a guestbook and a visit counter - they miraculously refused; therefore, you need a database. That was true even in the good old days of the LAMP stack, circa the time BLINK tags went out of fashion.
2. Your app will be rather complex (many views, controllers and routes) and probably have more than one developers, and you'd want to somehow manage all of this complexity, have a standardized way of organizing views/controllers/etc. and cut down on hard-to-maintain boilerplate. That's why you want a framework.
3. Your data will change (you need migrations) and inline SQL gets hairy very quickly. You'll need an ORM. You'll need to create models/entities for that.
4. Your client demands an SPA. They want incremental search, sliders, drag and drop functionality and everything else that require a Javascript framework.
5. You need responsive design and nice looking CSS widgets, and a design that easy to update (so that you could replace your primary and highlight colors in a single place). You end up with a CSS framework like Bootstrap and a preprocessor like Sass.
6. You realize you'll end up writing JS code no less than you would write PHP, and you want to avoid callback hell, and the general weirdness that comes with classic ES5, so you go ahead and add Babel to your pipeline.
7. You also need to merge and minify JS and CSS files, so you end up tacking webpack or browserify or a custom grunt or gulp build script (or even both of them) to your pipeline. Yeah, complex pipeline suck, but in the old days we used to zip everything and upload with FTP.
8. The article doesn't mention it, but you may definitely want to set up a CI pipeline that does all of that, and link it with your Git repo using webhooks.
9. Wow, you need so many javascript and PHP libraries! Let's use a package manager.
10. Your SPA needs to communicate with your app somehow, right? We need to use an API for everything. REST is getting a lot of hate recently, but it's not like gRPC or JSON-RPC or GraphQL are simpler to set up.
We haven't even mentioned adding OAuth2 support, social login, analytics, error reporting and logging, client-side router, isomorphic apps which generate views on the server side, view caching and object caching, a separate server for static resources, load balancing, a CDN, setting up LetsEncrypt to automatically issue SSL certificates and whatnot.
Yeah, setting up a modern web app is complex. Not because this is how we do web app, but because by 2017 users' expectations of web app are much higher than they used to be. If your app is in a position to skip some of the issues listed above, by all means skip it. People often go into overkill mode with all these frameworks (one of my pet peeves at work is people using Spring for microservices).
Of course, if all you need is printing "Hello World", even good old <?php echo 'Hello, world!'; ?> is an overkill when you could just use static HTML.
The article is fallacious in that writing "hello world" (and then working your way up to printing the numbers from one to 10, then asking for your name and printing "Hello, $NAME", then checking the time and printing good morning/evening etc) isn't about building a fully-featured modern web application. You could argue that the example is criminally irresponsible because it neither considers the need for HTTPS and 2FA! And finally, you need to compare apples to apples. Setting up a similarly fully featured application in any language takes significant effort, and may well be easier than in PHP, but Hello World is still easier in PHP.
Maybe I am old fashioned and outdated. I don't know about anyone else, but it makes me pretty sad that the "modern" way as presented in this article is no longer simple and straightforward and has some severe dependency hell.
Not that I'm saying the structure of modern web applications isn't needed and that we haven't advanced. Just that the overhead and knowledge required to set up a modern web application is crazy.
I am working on a larger .NET web application in my day job... and it requires things like.. Typescript + typings files, Webpack/Gulp/Grunt/etc. and therefore Node.js and NPM, NuGet, .NET Framework, onion architecture, front-end framework (Angular, or React, or..), Entity Framework, multiple databases, web services/web API, ASP.NET MVC.. I mean, it's just crazy if you step back and think about it.
Sometimes I long for the simpler "bad old days"? Oh well, back to my enterprise single page application framework-laden monster.
DISCLAIMER: I know we're better off today in many ways, and maybe I'm just getting older and the cognitive load is higher.
> I am working on a larger .NET web application in my day job... and it requires things like.. Typescript + typings files, Webpack/Gulp/Grunt/etc. and therefore Node.js and NPM, NuGet, .NET Framework, onion architecture, front-end framework (Angular, or React, or..), Entity Framework, multiple databases, web services/web API, ASP.NET MVC.. I mean, it's just crazy if you step back and think about it.
All long as all the tools and pipelines work flawlessly it's painless.
As soon as something goes wrong, if you are not a specialist or have a deep understanding of the inner-working of all these it actually hinders productivity.
What if Webpack doesn't work as expected because you mis-configured it? what if there is a bug in AngularJS and you're not capable of fixing it yourself? What if Entity framework doesn't support a specific use case/feature of your DB?
While in a professional environment implementing the domain is already a lot of work and people want the rest to be coded fast by using ready-made solutions, each new component, framework should be carefully vetted, adding a new framework or library shouldn't become a reflex.
It's usually not advisable, but I genuinely think classical CGI is beautiful mechanism for dynamically generated pages. It's a natural extension of Unix scripting: shebang'd scripts in any language, environment variables, stdout. Job's a good'un.
I definitely agree with you. And we are better off compared to the hack-hell it was when you were doing [0] (yes, that is still the tutorial), but I feel we are still finding our ways very much. If the progression from the old 'install and start developing and deploying' to the current brittleness and dependency hell is going to continue into the future, I will find something else to do :)
To quote DevOps Borat: "Cloud is not ready for enterprise if is not integrate with single server running Active Directory."
And with service accounts, API tokens, client certs, partner management of users, etc with OAuth and micro services, I really wish we just used LDAP for everything.
Everyone's trying to take this literally as the "right way to display plaintext" in modern PHP. In that sense, it is absolutely absurd.
But if the idea of a "hello world" is to learn the basic boilerplate that you'll need before you start implementing real features, unfortunately for us web developers, this quite accurately represents the minimum before we can even start implementing business logic. With the baseline expectation for a lot of modern SPA-type applications including caching scripts, client-side routing, server-side rendering, working offline, supporting IE9 to iOS to Firefox and all the quirks in between, etc it really is getting to this point.
I wish like nothing else that most of this could come out of the box so "hello world" really was a one-liner, but that just doesn't seem to be the reality that 2017 webapps live in.
Then again take a step back and look at what's being achieved. You are delivering, nearly instantly, a sophisticated and responsive fat client application to the user without any installation process. This fat client is running in a nearly universal and quite safe sandbox that is provided by several vendors across different os's, form factors, and architectures. With a good amount of backwards compatibility. Backed by a backend that's almost infinitely scalable. And developers are constantly feeding new features into this system without bringing it down or interrupting anything.
From that perspective, you would expect the tooling and stack to be complex. We really are doing way way more than we were in the "old days." "Write once run everywhere" has arrived and we're doing it, it's just not as simple as it sounds.
The irony is that if it was a real world baseline, we'd have a discussion about not all browsers supporting the fetch() api, and yet another boilerplate step being needed to polyfill it.
99% of real-world apps out there could be implemented with a BAAS and some simple JS MVC framework (good ol' BackboneJS in my flavor, if not jQuery fancy). I am not talking about building million-user-base facebooks and twitters, I am taking about a fuckzillion apps with a dozen at best concurrent users that will thrive in Firebase's free tier, a damnzillion worpress sites that never-fucking-ever get updated and would do just fine with good ol' static html, forever spared from bitcoin ramsomware.
Simply put: we forgot how to be engineers (the right solution for the problem). We are all Zuckergified into the fucking hype. Aren't we? We forgot that it is WE the experts that should tell clients how to solve their damn problems not just echo some buzz words so we get the damn contracts.
This post is NOT satire. It is the very state of current affairs.
FWIW the Wordpress situation and specifically my personal site getting hacked even though I was a sysadmin working in hosting at the time are why I love static site generators. Moveable Type was always amazing and scaled with traffic literally 100x as well as Wordpress out of the box (Varnish and W3 Total Cache can help if you ever need it, but again "out of the box"), so I'm happy to see that things like Jekyll and Hugo are trendy. The fundamental idea behind SSGs just makes so much sense to me; optimize it for viewing (in terms of computational power spent on serving traffic), which it'll be doing many more times than it will be created. Why generate a page on each visit when that page will be exactly the same until the post gets updated? I understand that many WP sites are much much much more than blogs (like shopping carts, ooh god why), but that's a different conversation entirely.
Wordpress (and any dynamic CMS) is like having a library full of whiteboards with the contents of the books written on them, with about the same potential for vandalism.
Truly look at the PHP code in this article, the JS dependency hell here and in the recent JS article.
Look at the code. At the environment. At the libraries.
Who isn’t reminded of what Java looked like years ago?
We’ve come full circle.
------------------------
Now, if one asks why this is, the answer is pretty simple – enterprise products.
To build software of a certain scale, certain technology, patterns, etc are required. These are what we see here again – ORMs, complex dependency systems, complicated frameworks, etc.
One might wonder why people even write PHP and JS nowadays, if Java is still faster, JS and PHP are now equally complicated, and Java ported all of the advantages of the others.
And, in fact, the Play Framework (which supports Java and Scala) is growing.
At the same time, Google’s go is copying the same mistakes Java did in the beginning, with almost all new methods in the standard library taking interface{} – the equivalent of void* or Object, and a simplistic typesystem.
------------------------
Why do we, as a profession, create new tools for a new purpose, then force them to adapt to another purpose, until they’ve become identical to the tools we tried to replace?
Why is the "enterprise" the culprit? The things you describe have more to do with generational churn, abusing the web as a desktop replacement, and developer's desires to always use the latest stuff as a stepping stone for the next gig, or maybe to convince themselves they're avantgarde when in reality it's mostly boring stuff.
which if, you think about it, requires a kernel, multitasking, driver independence on various level, many drivers, memory management, possible resource accounting, binary api, dynamic linker, interpreter, etc, etc, etc.
All (or at least most) of this seems overkill if you just want to print out 'hello world'. But it makes total sense if you want to do a little more complex stuff.
I think that's kind of the point, though, that OSes and shells have gotten to the point where all that complexity is hidden behind an easy installation. With modern web frameworks, all the "guts" are still fully exposed, warts and all.
It kind of reminds me of the state of Linux in the mid-late 90s, where you'd have "install fests" with a roomful of 25 people and it took a whole day to get Linux installed on your machine (and your sound still didn't work, that took another afternoon).
While reading i was thinking "..but that all makes sense for any project that's larger than a few hundred lines.." and thought the author was just ignorant and needlessly cynical.
But at the end of the article, he makes a good point:
Disputes like “Why do I need PHP if there’s Java?” have become more frequent nowadays. I don’t know who’s in the right, Holly Wars are tricky. But each dispute has an argument in favor of PHP — it’s easy for beginners. To my mind, this argument isn’t valid anymore, which is exactly what I was trying to say in this article.
The notion of PHP as a beginner-friendly language has in my opinion been a harmful one for a while now. There are still people writing old school PHP apps, and there is the (mildly displeasing) wordpress ecosystem. But for anything serious, Symfony is invaluable. And the gap between old school PHP to modern PHP is almost the same as the one between old school PHP and Java/Spring/Hibernate, which is kind of what Symfony/Doctrine is cloning anyway. Plus if you do Java, you don't get the stigma of being in the same category as a professional wordpress template tweaker.
I like to argue that you can start off using PHP as a scripting language with a single index.php file, then maybe learn to use some of the simple frameworks like Slim (though even that has become more complicated recently), then move from that to Symfony or the like. This is a point the original author misses. If you introduce beginners in PHP to Symfony and SPAs from the start obviously they're going to have a bad time.
Coincidentally I recently began a new project involving a user-facing PHP app, and even though I have enough ES6 + webpack + react blablabla experience (and some angular, but I didn't particularly enjoy it), I decided to just go with good old synchronous requests. It makes things easier and, in this case, development time is key.
So many people not getting the joke here. This article is a send-off of the idea that PHP is "just easy" anymore, but frankly, misses its shot.
Of course it's complex when you introduce complexity. So is anything by definition. If you don't want to do complex things, you're fine. But if you want to have a database, have a framework abstract away the truly dangerous and boring shit, use a modern, type-safe version of Javascript, write CSS in something approaching a maintainable fashion, and deliver a responsive, reactive site, you'll have to do something like this, regardless of language.
Also, the author neglected to set up database migrations, to say nothing of a Dockerfile.
All true. But OP was never trying to argue that PHP is more complex than other language, but instead claimed that once you get to the point of requiring complexity, PHP doesn't get to have the "it's braindead simple" advantage anymore. To quote:
---
Disputes like “Why do I need PHP if there’s Java?” have become more frequent nowadays. I don’t know who’s in the right, Holly Wars are tricky. But each dispute has an argument in favor of PHP — it’s easy for beginners. To my mind, this argument isn’t valid anymore, which is exactly what I was trying to say in this article. A novice programmer will have to learn lots of new things, as well as write tons of configs: frameworks (very similar to java frameworks), databases, linux, shminux, JavaScript with all its baggage, http-protocol, various tooling and many more. Even if it’s not SPA.
> But each dispute has an argument in favor of PHP — it’s easy for beginners. To my mind, this argument isn’t valid anymore, which is exactly what I was trying to say in this article.
It's still is easier AND cheaper to deploy a Hello World in PHP than a Hello World in any other language. You can get a cheap Apache/PHP hosting for $2/month, use SFTP a get a working app in minutes. The default PHP distribution comes with a lot of extensions.
The problem is that PHP doesn't help a beginner graduate from a basic webpage to a secure and robust application without having to download a complex framework and meddle with configuration files. IMHO by the time you are tempted to use Symfony you might switch to Java or ASP.net directly.
If PHP was really beginner oriented, it would actually do everything it could to use the most secure defaults for every feature, like templating, or sessions.
Microsoft attempted to do that with WebPages, which is kinda what PHP should have been if it was really intended for beginners. WebPages mostly use secure defaults. While it doesn't prevent spaghetti code it makes having to rely on a complex framework unnecessary.
A bit like the other submission on learning JS in 2016. I find that I am getting dragged down by complexity. Even simple tic tac toe game that I was planning to write in vanilla js took me via jQuery, npm, Firebase etc. Sure its production ready but I just wanted to write something for fun.
Wasn't really fun.
This seems like a decent primer for someone who already has their heads wrapped around application development, but absolutely horrid for someone who wants to pick up a web language for the first time and create that first simple output.
That first simple output IMO is critical for retention and engaging the language knowing exactly what you're going to get by looking at dirt simple code like echo hello world; at least it was for me as PHP was one of my very first languages
The intent is well meaning in this "real world" hello world, but I feel like taking the espoused mentality in the opening paragraph, one is throwing construction tools at a toddler who asked for a box of legos for christmas.
Using React, TypeScript, and Webpack in this context is ridiculous. Use tools that solve the problem at hand, not just because someone else is doing it...
I love PHP and it's still my main language, but the reason so many projects never get completed is because of this. Really I should just accept that for an MVP, Laravel and a static front end with some old school jQuery where required is fine.
I enjoy that the concept of Hello World engulfs a full-stack deployment. Every one of these dependencies has a Hello World and the fact that people might not be aware of them is a real problem.
I don't miss having to manually add includes and update dependencies with FTP. I don't miss htmlspecialchars or mysql_real_escape_string, I don't miss running everything in the webroot, I don't miss having to switch contexts between PHP, HTML, Javascript and CSS all mixed in one file.
The good old days kind of weren't that good. The simplicity of bare PHP was great for cowboying up sites in a hurry, but it's not a system that handles complexity well.
> Summary: Disputes like “Why do I need PHP if there’s Java?” have become more frequent nowadays. I don’t know who’s in the right, Holly Wars are tricky.
Who is this Holly and why are we starting a war over her?
All this talk about "Enterprise over engineering", is all this needed, tool-overload-hell, etc... and I just can't stop thinking about Holly and how to stop the war over her...
Once you've spent all this time setting up a NodeJS stack.... why use PHP at all? Ie. just use Node for the API/Server, you're already setup, and the stack would be 100% one language.
Except e.g. React and Express are so different and work on such vastly different domains that them being in technically a similar VM is more or less inconsequential. They're two entirely different disciplines and have different build pipelines, deploy pipelines, etc. I don't see much benefit in having them in the same language. One thing does DOM state while the other does ~play in traffic with libuv. Like hey it's nice that this OS kernel is implemented in C, good thing I am also writing my GUI in C.
Idk, maybe it's a boon for some, but I've tried it and don't really see the big appeal...except for Meteor, because if I'm writing both my UI and API in the same * language, why in the would I need to write my models in both places and maintain them separately. But meteor has problems too, I just always thought it was neat way of doing something that would only be possible ("easily") when using the same lang on both sides.
The author makes it clear at the end of the article. The claim that PHP is "beginner friendly" is bogus now because any serious development in PHP is full blown enterprisey software engineering.
vectorpush|9 years ago
dheera|9 years ago
Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?
rosser|9 years ago
unscaled|9 years ago
1. You offered your client a static page with purple background, blinking title, a guestbook and a visit counter - they miraculously refused; therefore, you need a database. That was true even in the good old days of the LAMP stack, circa the time BLINK tags went out of fashion.
2. Your app will be rather complex (many views, controllers and routes) and probably have more than one developers, and you'd want to somehow manage all of this complexity, have a standardized way of organizing views/controllers/etc. and cut down on hard-to-maintain boilerplate. That's why you want a framework.
3. Your data will change (you need migrations) and inline SQL gets hairy very quickly. You'll need an ORM. You'll need to create models/entities for that.
4. Your client demands an SPA. They want incremental search, sliders, drag and drop functionality and everything else that require a Javascript framework.
5. You need responsive design and nice looking CSS widgets, and a design that easy to update (so that you could replace your primary and highlight colors in a single place). You end up with a CSS framework like Bootstrap and a preprocessor like Sass.
6. You realize you'll end up writing JS code no less than you would write PHP, and you want to avoid callback hell, and the general weirdness that comes with classic ES5, so you go ahead and add Babel to your pipeline.
7. You also need to merge and minify JS and CSS files, so you end up tacking webpack or browserify or a custom grunt or gulp build script (or even both of them) to your pipeline. Yeah, complex pipeline suck, but in the old days we used to zip everything and upload with FTP.
8. The article doesn't mention it, but you may definitely want to set up a CI pipeline that does all of that, and link it with your Git repo using webhooks.
9. Wow, you need so many javascript and PHP libraries! Let's use a package manager.
10. Your SPA needs to communicate with your app somehow, right? We need to use an API for everything. REST is getting a lot of hate recently, but it's not like gRPC or JSON-RPC or GraphQL are simpler to set up.
We haven't even mentioned adding OAuth2 support, social login, analytics, error reporting and logging, client-side router, isomorphic apps which generate views on the server side, view caching and object caching, a separate server for static resources, load balancing, a CDN, setting up LetsEncrypt to automatically issue SSL certificates and whatnot.
Yeah, setting up a modern web app is complex. Not because this is how we do web app, but because by 2017 users' expectations of web app are much higher than they used to be. If your app is in a position to skip some of the issues listed above, by all means skip it. People often go into overkill mode with all these frameworks (one of my pet peeves at work is people using Spring for microservices).
Of course, if all you need is printing "Hello World", even good old <?php echo 'Hello, world!'; ?> is an overkill when you could just use static HTML.
mseebach|9 years ago
nkkollaw|9 years ago
Every project is setup in an identical or similar way, which makes it easy for other developers to jump in and understand what's going on.
cossovich|9 years ago
sixdimensional|9 years ago
Not that I'm saying the structure of modern web applications isn't needed and that we haven't advanced. Just that the overhead and knowledge required to set up a modern web application is crazy.
I am working on a larger .NET web application in my day job... and it requires things like.. Typescript + typings files, Webpack/Gulp/Grunt/etc. and therefore Node.js and NPM, NuGet, .NET Framework, onion architecture, front-end framework (Angular, or React, or..), Entity Framework, multiple databases, web services/web API, ASP.NET MVC.. I mean, it's just crazy if you step back and think about it.
Sometimes I long for the simpler "bad old days"? Oh well, back to my enterprise single page application framework-laden monster.
DISCLAIMER: I know we're better off today in many ways, and maybe I'm just getting older and the cognitive load is higher.
camus2|9 years ago
All long as all the tools and pipelines work flawlessly it's painless.
As soon as something goes wrong, if you are not a specialist or have a deep understanding of the inner-working of all these it actually hinders productivity.
What if Webpack doesn't work as expected because you mis-configured it? what if there is a bug in AngularJS and you're not capable of fixing it yourself? What if Entity framework doesn't support a specific use case/feature of your DB?
While in a professional environment implementing the domain is already a lot of work and people want the rest to be coded fast by using ready-made solutions, each new component, framework should be carefully vetted, adding a new framework or library shouldn't become a reflex.
frou_dh|9 years ago
tluyben2|9 years ago
[0] http://php.net/manual/en/tutorial.firstpage.php
seanp2k2|9 years ago
And with service accounts, API tokens, client certs, partner management of users, etc with OAuth and micro services, I really wish we just used LDAP for everything.
raarts|9 years ago
robbiewxyz|9 years ago
But if the idea of a "hello world" is to learn the basic boilerplate that you'll need before you start implementing real features, unfortunately for us web developers, this quite accurately represents the minimum before we can even start implementing business logic. With the baseline expectation for a lot of modern SPA-type applications including caching scripts, client-side routing, server-side rendering, working offline, supporting IE9 to iOS to Firefox and all the quirks in between, etc it really is getting to this point.
I wish like nothing else that most of this could come out of the box so "hello world" really was a one-liner, but that just doesn't seem to be the reality that 2017 webapps live in.
m_fayer|9 years ago
From that perspective, you would expect the tooling and stack to be complex. We really are doing way way more than we were in the "old days." "Write once run everywhere" has arrived and we're doing it, it's just not as simple as it sounds.
technion|9 years ago
bikamonki|9 years ago
Simply put: we forgot how to be engineers (the right solution for the problem). We are all Zuckergified into the fucking hype. Aren't we? We forgot that it is WE the experts that should tell clients how to solve their damn problems not just echo some buzz words so we get the damn contracts.
This post is NOT satire. It is the very state of current affairs.
seanp2k2|9 years ago
Wordpress (and any dynamic CMS) is like having a library full of whiteboards with the contents of the books written on them, with about the same potential for vandalism.
kuschku|9 years ago
Truly look at the PHP code in this article, the JS dependency hell here and in the recent JS article.
Look at the code. At the environment. At the libraries.
Who isn’t reminded of what Java looked like years ago?
We’ve come full circle.
Now, if one asks why this is, the answer is pretty simple – enterprise products.To build software of a certain scale, certain technology, patterns, etc are required. These are what we see here again – ORMs, complex dependency systems, complicated frameworks, etc.
One might wonder why people even write PHP and JS nowadays, if Java is still faster, JS and PHP are now equally complicated, and Java ported all of the advantages of the others.
And, in fact, the Play Framework (which supports Java and Scala) is growing.
At the same time, Google’s go is copying the same mistakes Java did in the beginning, with almost all new methods in the standard library taking interface{} – the equivalent of void* or Object, and a simplistic typesystem.
Why do we, as a profession, create new tools for a new purpose, then force them to adapt to another purpose, until they’ve become identical to the tools we tried to replace?tannhaeuser|9 years ago
ams6110|9 years ago
tonyedgecombe|9 years ago
libeclipse|9 years ago
I hope it's a joke...
sixdimensional|9 years ago
autokad|9 years ago
"That’s it, we can run it now. “Hello, world!” is displayed on the screen. It looks almost like the result of <?php echo «hello, world» ?>"
aidenn0|9 years ago
okket|9 years ago
All (or at least most) of this seems overkill if you just want to print out 'hello world'. But it makes total sense if you want to do a little more complex stuff.
adevine|9 years ago
It kind of reminds me of the state of Linux in the mid-late 90s, where you'd have "install fests" with a roomful of 25 people and it took a whole day to get Linux installed on your machine (and your sound still didn't work, that took another afternoon).
ponyfleisch|9 years ago
But at the end of the article, he makes a good point:
Disputes like “Why do I need PHP if there’s Java?” have become more frequent nowadays. I don’t know who’s in the right, Holly Wars are tricky. But each dispute has an argument in favor of PHP — it’s easy for beginners. To my mind, this argument isn’t valid anymore, which is exactly what I was trying to say in this article.
The notion of PHP as a beginner-friendly language has in my opinion been a harmful one for a while now. There are still people writing old school PHP apps, and there is the (mildly displeasing) wordpress ecosystem. But for anything serious, Symfony is invaluable. And the gap between old school PHP to modern PHP is almost the same as the one between old school PHP and Java/Spring/Hibernate, which is kind of what Symfony/Doctrine is cloning anyway. Plus if you do Java, you don't get the stigma of being in the same category as a professional wordpress template tweaker.
raziel2p|9 years ago
Entangled|9 years ago
travisjungroth|9 years ago
acomjean|9 years ago
If I'm creating a static page I would just create a html page (no php required)
lohengramm|9 years ago
DanHulton|9 years ago
Of course it's complex when you introduce complexity. So is anything by definition. If you don't want to do complex things, you're fine. But if you want to have a database, have a framework abstract away the truly dangerous and boring shit, use a modern, type-safe version of Javascript, write CSS in something approaching a maintainable fashion, and deliver a responsive, reactive site, you'll have to do something like this, regardless of language.
Also, the author neglected to set up database migrations, to say nothing of a Dockerfile.
unscaled|9 years ago
--- Disputes like “Why do I need PHP if there’s Java?” have become more frequent nowadays. I don’t know who’s in the right, Holly Wars are tricky. But each dispute has an argument in favor of PHP — it’s easy for beginners. To my mind, this argument isn’t valid anymore, which is exactly what I was trying to say in this article. A novice programmer will have to learn lots of new things, as well as write tons of configs: frameworks (very similar to java frameworks), databases, linux, shminux, JavaScript with all its baggage, http-protocol, various tooling and many more. Even if it’s not SPA.
megous|9 years ago
Hello world!
People forget PHP is still a template language for the web.
camus2|9 years ago
It's still is easier AND cheaper to deploy a Hello World in PHP than a Hello World in any other language. You can get a cheap Apache/PHP hosting for $2/month, use SFTP a get a working app in minutes. The default PHP distribution comes with a lot of extensions.
The problem is that PHP doesn't help a beginner graduate from a basic webpage to a secure and robust application without having to download a complex framework and meddle with configuration files. IMHO by the time you are tempted to use Symfony you might switch to Java or ASP.net directly.
If PHP was really beginner oriented, it would actually do everything it could to use the most secure defaults for every feature, like templating, or sessions.
Microsoft attempted to do that with WebPages, which is kinda what PHP should have been if it was really intended for beginners. WebPages mostly use secure defaults. While it doesn't prevent spaghetti code it makes having to rely on a complex framework unnecessary.
webreac|9 years ago
z92|9 years ago
Default in PHP is to output the bare text. Unless you wrap it in special markup '<?php'. That's an unique feature in the top languages.
_nalply|9 years ago
Of course this would be broken HTML but first it displays, and second you could configure the web server to send
without charset parameter because YAGNI.quickben|9 years ago
I run a search engine. It is big enough that it needs drives, caches, firewalls, VMs etc.
The front end is php. No classes, no phpadmin, etc. Just pure vanilla php.
Sometimes I tail /var access logs. People try all kinds of urls routinely fishing for weaknesses.
It's 2017. It is slow to code and keep the attack surface that minimal.
0 intrusions so far.
xchaotic|9 years ago
krapp|9 years ago
No one even writes javascript anymore, they compile it from Haskell or whatever. That's how serious it is.
oddlyaromatic|9 years ago
iamdave|9 years ago
That first simple output IMO is critical for retention and engaging the language knowing exactly what you're going to get by looking at dirt simple code like echo hello world; at least it was for me as PHP was one of my very first languages
The intent is well meaning in this "real world" hello world, but I feel like taking the espoused mentality in the opening paragraph, one is throwing construction tools at a toddler who asked for a box of legos for christmas.
Curious what others think
halfdan|9 years ago
partycoder|9 years ago
https://en.wikipedia.org/wiki/Rule_of_least_power
If you enjoy overengineered code, check:
- Fizzbuzz Enterprise Edition: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- Fizzbuzz in Tensorflow: https://github.com/joelgrus/fizz-buzz-tensorflow/blob/master...
mike503|9 years ago
scurvy|9 years ago
blackice|9 years ago
wanderr|9 years ago
Bullshit, especially on the PHP / backend side. It's 2017, we should know how to avoid over engineering simple things.
hugodahl|9 years ago
mndewitt|9 years ago
dheera|9 years ago
unknown|9 years ago
[deleted]
iDemonix|9 years ago
I love PHP and it's still my main language, but the reason so many projects never get completed is because of this. Really I should just accept that for an MVP, Laravel and a static front end with some old school jQuery where required is fine.
CCing|9 years ago
methodin|9 years ago
buro9|9 years ago
CCing|9 years ago
CCing|9 years ago
Maybe wasn't the best solution but it worked...and was fast too.
krapp|9 years ago
The good old days kind of weren't that good. The simplicity of bare PHP was great for cowboying up sites in a hurry, but it's not a system that handles complexity well.
mythrwy|9 years ago
Granted the person who wrote it obviously didn't care but that setup was awful for anything of any size.
wernercd|9 years ago
Who is this Holly and why are we starting a war over her?
All this talk about "Enterprise over engineering", is all this needed, tool-overload-hell, etc... and I just can't stop thinking about Holly and how to stop the war over her...
guillem_lefait|9 years ago
trhway|9 years ago
nillawafer|9 years ago
seanp2k2|9 years ago
Idk, maybe it's a boon for some, but I've tried it and don't really see the big appeal...except for Meteor, because if I'm writing both my UI and API in the same * language, why in the would I need to write my models in both places and maintain them separately. But meteor has problems too, I just always thought it was neat way of doing something that would only be possible ("easily") when using the same lang on both sides.
jakon89|9 years ago
ponyfleisch|9 years ago
Ambrosia|9 years ago
tommorris|9 years ago
Girlang|9 years ago
[deleted]