We’ve gone full circle. 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 technol…
“Hello, (real) world” in PHP in 2017
71–80 of 144 posts
Re: “Hello, (real) world” in PHP in 2017
#72Ahahaha I legitimately cannot tell if this is a sarcastic blog post. To me it just sounds like such a joke. It's quite confusing. I hope it's a joke...
I think this is a realistic reflection on the state of this area in our industry. It is both sarcastic/a joke and not a joke at all.
Re: “Hello, (real) world” in PHP in 2017
#73A 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.
Re: “Hello, (real) world” in PHP in 2017
#74I 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,…
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 is an overkill when you could just use static HTML.
Re: “Hello, (real) world” in PHP in 2017
#75Ahahaha I legitimately cannot tell if this is a sarcastic blog post. To me it just sounds like such a joke. It's quite confusing. I hope it's a joke...
Re: “Hello, (real) world” in PHP in 2017
#76So 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…
--- 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.
Re: “Hello, (real) world” in PHP in 2017
#77I 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,…
On a similar note, I always find it ridiculous when I have to do things like apt-get install npm && npm install bower && bower install ... Why can't we just use apt-get and Makefiles for everything? Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?
It's still squarely in early adopter territory and the documentation is woeful, but if you're willing to put up with that it really does feel like the "one true package manager" I've been searching for. I've been using it at work and while the setup was painful and some things are still awkward (ie statically linking Haskell executables), it's been incredible overall. The up-front work in learning the system and getting it running has paid off already, and it'll pay off even more as I continue using Nix for other things.
Re: “Hello, (real) world” in PHP in 2017
#78Earlier quoted context omitted.
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.
What is good for developers is bad for the industry. How else would they justify creating frameworks in different languages if all people are doing anyway is writing text to (F)CGI stdout? It is much better for the companies/groups involved to make people believe that there is something wrong with this and that they should really be using a "proper" framework.
Re: “Hello, (real) world” in PHP in 2017
#79Call me old fashioned but I prefer my code naked, plain php and postgres, nothing else, not even JS. So for me, echo 'Hello world' is good enough.
If I'm creating a static page I would just create a html page (no php required)
Re: “Hello, (real) world” in PHP in 2017
#80I 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,…
On a similar note, I always find it ridiculous when I have to do things like apt-get install npm && npm install bower && bower install ... Why can't we just use apt-get and Makefiles for everything? Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?
Because Makefiles are quite limiting.
> Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?
Because that would be OS specific.