“Hello, (real) world” in PHP in 2017
kukuruku.coI 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.
On a similar note, I always find it ridiculous when I have to do things like
Why can't we just use apt-get and Makefiles for everything?apt-get install npm && npm install bower && bower install ...Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?
I've thought the same for a while, and now I'm looking to Nix[1] as a solution. Upside: strong fundamental design, extreme reproducibility, great Haskell support. Downside: small community, middling OS X support, essentially non-existent Windows support.
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.
> Why can't we just use apt-get and Makefiles for everything?
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.
Makefiles are limiting? They have their own macros, and support M4 as well (macros with recursion), not to mention the DSL is Turing complete.
Make runs on Windows, OS X, Linux and Android.
How is a Makefile quite limited?
I know at least three reasons why makefiles are not working well for common use cases. Many people seem unaware of these cases, even though they seem to come up quite often.
• make(1) has a hard time rebuilding target files when source files have changed. The problem is that users have to declare the dependencies of a target before the build, but due to file search paths, it can be that dependencies are only known after building a target. To know about all dependencies, make(1) would have to build any target at least twice.
• make(1) by default does not rebuild a target when its build rules change. While this seems really weird to me, it seems to be a consequence of having a single makefile. When a build rule is changed, the makefile changes. So should all targets depend on the makefile implicitly? One could argue that they should – but then each change in a makefile would rebuild all targets.
• make(1) can not handle non-existence dependencies. Imagine a file foo.h being searched for by a compiler in directories bar and baz (in that order). If the header file baz/foo.h is found, then bar/foo.h should be considered a non-existence dependency: If at any future point in time it exists, the target should be rebuilt.
These problems are all solved by DJB's redo approach, which I implemented in a few hundred lines of Bourne shell (/bin/sh): http://news.dieweltistgarnichtso.net/bin/redo-sh.html
Those don't seem limitations of make itself, but rather the compiler and linker you use with it...
The compiler may know paths, the linker may know paths, the shell might, make might, or you can supply them.
I've seen and used nested Makefiles before.
These things aren't really make things. If I use tcc, Haskell or Go in my Makefile, then they mightn't apply.
If you can write it in Bash, you can integrate it into your Makefile.
I think that all of these are limitations of not only make(1), but all utilities that expect dependencies to be fully known before a target is built. What makes you think they are not?
How would you solve all three problems I listed using make(1)?
Why should make solve the dependency expectations of what it is building?
If I use pip as part of my buildchain, then it has a series of places it can lookup, or you can supply one. Same with npm, cargo, and even Go.
If instead, I use a tool that has dynamic lookup, then it will only look in those places after the event.
So, if I used make to send a command like:
Then it can lookup those when the lua file is called, later in the process.$(echo 'require "foo"' > bar.lua)So how would this be a limitation of make itself? The limitation only exists in what you call with make... Which could be anything.
A makefile consists of rules. Each rule contains a dependency line which defines a target and an enumeration of prerequisites. This means that the dependencies have to be known before the target is built. By design, it is impossible for a single-pass make(1) invocation to derive dependencies for a C program, as dependencies are output by the compiler.
By contrast, redo builds the target first and then records what was used to build it. For example, when compiling a C file with “gcc -M”, gcc will output dependency information. With redo, you normally record those dependencies after the target has been built. With make(1), that information has to end up in the makefile somehow, possibly leading to further builds.
I mentioned m4 before as a way of using more passes, and is how the Linux kernel approaches this, but looking deeper at make, I'm not even sure you need it.
From the manual, on implicit rules:
foo : foo.o bar.o cc -o foo foo.o bar.o $(CFLAGS) $(LDFLAGS)
Because you mention `foo.o' but do not give a rule for it, make will automatically look for an implicit rule that tells how to update it. This happens whether or not the file `foo.o' currently exists.
I do not understand. I know that make(1) has many implicit rules – but which of the problems I mentioned does this solve and how? Please be specific about your solution.
C already does what PHP does. Why do you need PHP?
COBOL already did what C does, why do you need C?
Assembler is Turing complete.
How is assembler quite limited compared to PHP (or C or COBOL)?
All languages have their place, some in history, some in very narrow fields, some in general use.
That was not my argument.
My argument, was calling make "quite limited".
How would you call make limited? The syntax is expressive, and so is the macro access.
I never said I wanted to replace or not replace make.
Because "limiting" has a broader meaning than what is merely possible with enough effort. The experience of practically everybody who hasn't already put in the effort to learn make is that they get much further much faster in more modern build systems - indeed, framework specific build systems often do exactly what you need them to do with no or very little configuration at all. That is a feeling of not being limited by the tool.
Also, both npm and pip support version-controlled per-project dependency configuration, something that apt needs containerisation to achieve.
Different tools specific to their job, they wouldn't be good to combine together. apt-get only exists for linux, requires root and is designed for that, npm doesn't. apt-get installs the latest version, npm expects more specific verisons since it's for code. npm is built for node's ecosystem and apt-get is better for system packages.
Welcome to dependency hell! Working for years in different "php environments" I learnt that most (web) developers I met in this field tend to use as much new fancy tools out there without thinking about business value and longterm impact. At the end of the day you might end up with more than four dependency systems...
To respond to your initial question if we really need so much dependency systems: No, we don't need to!
As the author already needs to use composer to set up PHP dependencies why not use composer for the other packages required? It's not a problem to get the common needed libraries via composer which dramatically reduces dependency complexity, deployment and build scripts because you don't need that much tools.
>> apt-get install npm && npm install bower && bower install ...
Turtles all the way down!
npm advantage (or disadvantage depending on who you asked) is the project owner has direct control over release cycle. The owner can decide when to push an update and it will be available to everyone immediately regardless of their operating system.
It's called "résumé-driven development."
Well yeah, why would you do anything else? When recruiters and job postings are mostly concerned with what languages and tools you know over software development ability and computer science knowledge why would you voluntarily make your life more difficult?
I believe the term you're looking for is "middle ground".
Exactly. In big companies there are architectural review boards to stop unstable platform usage. I agree those can go too far and sometimes slow things down. However, i've see too many startups use the platform du jour w/o any consideration to stability. Worse, some will fork a good platform, make slight changes, and market their fork as the next best thing. Since experience does not matter as much to keyword-driven recruiters, is it any surprise this all happens?
Might explain why I don't get many recruiters attempting to contact me. Back when AngularJS was the big thing, I'd get bombarded on LinkedIn. Now, having only non-commercial experience with React and refusing to list it on my resume, I'm mostly ignored. Now are recruiters to blame or the companies that hire them?
And sadly, in the race to stay competitive, it's all too common.
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.
JSON-RPC? Not in my 2017. The last time I've had to use that was with an old version of Zabbix https://www.zabbix.com/documentation/2.2/manual/api
Nah, it's all about http://jsonapi.org these days. GraphQL seems neat. Cap'n Proto also seems neat but I'm unaware of anything actually using it. gRPC is also neat but AFAIK not supported in a browser, so you need some kind of gateway to have it work with browser clients anyway (think SPAs calling APIs which can normally service server to server over gRPC). CPNP has the same-ish problem in that it doesn't fully work in browsers (serialization works but not RPC).
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.
I think all these tools give you structure, though.
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.
But that loses its usefulness if there's new tools every 6 months. Yes webpack gives me structure today, but there could be a new structure tomorrow. Look at Grunt and Gulp, NPM and yarn....
Not really, you'll still be able to follow what's going on if the project follows an old standard way of doing things, compared to a random or made-up way of doing things.
I had to update a project that used the Gulp-based workflow 2 days ago, and after 5 minutes I knew what I was doing again.
Even if you don't remember you can still look it up, while those who reinvent the wheel seem to never bother documenting their wheel.
How is the article satirical? I didn't get that at all.
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.
Although, in the longer term, it is unlikely that these tools and pipelines will remain stable, and the interdependence between them often causes you to have to update one to update the other (especially the more dependencies you're dealing with). I realize that most package managers have a way to deal with this (and via semver/good version practices), but sometimes finding the right stable combination of versions of dependencies is like finding the magic incantation.
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.
Funny aside, it took me many months as a teenager who did not know the ways of *nix to "get" CGI. It was very enlightening to eventually realize that it was so simple that it had eluded my understanding. My mind, coming from messing with Win32 in Visual Basic 5, refused to believe that you just make a program that writes plaintext out to the console, and that text is what gets sent to the browser, and that just works.
If you work on web apps, you absolutely owe it to yourself to understand HTTP and CGI. The one page I'd recommend to quickly grok CGI is http://www.oreilly.com/openbook/cgi/ch01_04.html . Also learn how to use cURL and understand everything that is happening inside the Network tab of Chrome or Firefox dev tools (they're very similar these days). Set up MITMProxy between your proxy server and your apache2/nginx, put it into reverse proxy mode and point the proxy at it, then it at httpd, and understand what you're seeing.
I don't have a good link for HTTP but I promise it'll help a ton with debugging things and generally having a sense of what's going on at every level.
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.
Who do you think is making money off open source frameworks?
The whole cottage industry of software engineers, authors, and consultants who implement these solutions.
Consultants that wrote those frameworks in first place and offer their services for help, or go to conferences giving talks about them.
Yep, in many cases the frameworks arise from patterns someone solved while working for BigCo, then decided that the pattern they used was cool enough to share with and be useful for others. Open source is hugely thankless and tons of work, but it can be very rewarding in ways you can't buy, including meeting with interesting / awesome people.
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.
I try to evaluate many new "hot" frameworks using the LDAP test as well. For non-enterprise usage, I use the file upload test.
Specifically, is there a simple example showing LDAP integration (or file upload/catcher). If not even that is documented and there is no example, the framework is likely not ready for usage. Seriously, why go thru all the hassle of starting a framework and not even cover basic use cases?
The latest version is "supported only by" rails. (I mean that you should implement the server side part in your language/framework)
(in php/asp.net/python you should write something in backend for serve javascript responses as is it in rails with files .js.erb)
"When you follow a link, Turbolinks automatically fetches the page, swaps in its <body>, and merges its <head>, all without incurring the cost of a full page load."
Is the cost really that high to warrant this?
It prevents the browser from requesting all the external files (CSS and/or JS), so yes, it may be that high.
I would have assumed they would be cached?
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.
And to just pile on with this comment, "run everywhere" means much more than it ever did.
This isn't just the big 3 desktop OS's, but laptops, tablets, phones, TV's, game consoles, car navigation units, hell my goddamn watch can run websites now! X86, ARM, SPARC, PPC, it doesn't matter.
And on most of those platforms, you have more than one choice of browser.
It's a level of cross-platform that really only simple C programs can even begin to reach. And it's not exactly simple to setup that environment from scratch either.
Except it is simple:
It's responsive, works on every HTML-compatible platform and is even backwards compatible to a degree that none of the other aforementioned solutions even comes close.<html> <head> <title>Hello World</title> </head> <body> Hello World </body> </html>We make it more complicated for ourselves because we choose to make it more complicated. I'm not against modern frameworks but quite often I see people justifying them rather than using them when they become a requirement.
Worse yet, I'm often disappointed by the number of web developers I've worked along side recently that haven't understood how data is serialised in HTTP response and request headers (so they inappropriately use GET and POST methods), don't know even the basic few HTTP status codes, don't understand browser caching, etc and I end up having to handhold them through the basics while they're advocating complex frontend frameworks because "it does the logic for you" (or similar arguments).
This isn't a dig at all web developers by any means. I'm talking about a minority here. But it's a trend I've observed growing and I do think there is a correlation between the rise in popularity of bloated abstractions and the number of inexperienced developers using them as a crutch for their lack of understanding about the core principles of the web. The problem is the moment something misbehaves they're completely incapable of effectively problem solving it. And in the era of everything being a web browser, we have more low end devices than ever that we need to support - which often gets neglected when you have developers constantly opting for their shiny new toys resulting in cumulative page sizes of megabytes just to display "Hello World!".
So going back to my original point; yes I do think it can be simple to set up the kind of cross platform support you describe. I think it's often us who choose to make it complicated for ourselves. Often far more complicated than it ever needs to be.
+1 on developers not knowing how HTTP works. I'd add to that with server-side devs (the ones writing the APIs that the single-page apps talk to) not knowing how CGI works. You can literally learn both in an afternoon if you have reasonable networking and OS-level knowledge that I'd expect anyone with a CS major to have down cold. Sadly, well, you know.
In my experience, devs knowing how it really works are the small minority. Most of them seem to know "I put /foo in my Rails router, run `rails s`, hit 127.0.0.1:3000/foo in my browser, and it does the good stuff", which is consequently enough to get by in many development positions at many places.
CGI isn't really something I'd expect many people to be using these days though. These days language web frameworks fire off their own web server and the few exception usually bypass CGI (eg PHP has a mod_php C++ API that hooks directly into Apache bypassing CGI).
Sure you can still run Perl, Python or even Go via CGI on Apache, or PHP using FastCGI on nginx, but the difference in performance between even FastCGI and a language-native web server isn't negligible. So there isn't really much reason to recommend people using CGI barring niche use cases where, hopefully, the sysadmin / devops as purposely chosen CGI acknowledging it's pitfalls (not just in terms of performance but also security) and thus understanding how it works.
This is one of the few areas where I think the additional complexity in modern frameworks is a real benefit.
Don't forget my proprietary pet peeve for proper mobile rendition: <meta name="viewport" content="width=device-width, initial-scale=1">. Don't get me started :)
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.
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.
------------------------
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 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.
Because, once you start working with complex systems, you’ll require complex frameworks.
That influences the way the entire language goes.
There isn't much history taught. So each generation makes the same mistakes over and over again.
There is a subset of programmers who will try and turn every language they encounter into Java.
Ahahaha 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.
Poe's law in full action. If for some reason this is not a joke, it's a pretty lousy tutorial, as for every single arbitrary framework/tool decision here, there's not a single rationale here but "because it's 2017". I'd absolutely prefer 1995's Hello World if it's just about saying "Hello World".
Generally I would agree with you, but I think it should be taken with a grain of salt. "Hello World" is somewhat metaphorical concept, the ultimate goal isn't to show the label itself, but to show what is the amount of work required to produce some generic output without any business-logic involved. This means that it totally makes sense to use OpenGL or ncurses to show "Hello world" on the screen, even though they are obviously not necessary to do just that. It's just that they will be necessary for many other typical tasks we are considering.
So, although I wouldn't really chose tools author choses here, so the "not-really-a-joke joke" is still largely opinionated, I have to admit that assuming AJAX and some kind of MVC-ish framework (even if it's a one of your own) on both back-end and front-end is pretty much a must for a typical PHP web-application.
I don't think it's a joke, but I also don't think "tutorial" is the right word either. It seems more like an illustrative commentary on the state of the webdev industry.
I think the word you're looking for is "satire".
That has extra connotations of parody that I was trying to avoid.
Actually I'd prefer the program just consisted of plain text since that's perfectly valid PHP.
I think this is a realistic reflection of one side of the industry. There are still some that I know who don't use 70% of what's mentioned but still run a profitable business in website development. Sometimes I think they're the more productive ones that don't comment on HN posts :)
Nicely done. Now back to work! LOL :)
Otherwise known as ironic.
its really funny :) my favorite line is:
"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» ?>"
I think it's a case of "Ha, Ha, only serious"
This is a bit like
$ echo 'Hello World!'
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.
I'm not convinced that this approach flattens the learning curve significantly. The concepts are different, and when you're at the end of that journey and look back, you'll find that you spent a large amount of time unlearning things. That is if you ever get there. It's easy getting stuck on local maxima when avoiding steep learning curves.
In other words, old school PHP and modern PHP are two vastly different beasts with few commonalities.
There is no way past learning the basics (OOP, patterns, proper architecture), by deferring that in favour of an easier start you're only lengthening the journey.
Call 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.
Users overwhelmingly prefer some amount of client-side interaction, so how do you do that without JavaScript?
css :hover with hrefs to fast-loading pages can give the illusion of interactivity without any javascript (or even server processing, if the whole site is statically-generated).
Most people don´t know how to build this because their X MB JS framework just slows everything down.
HTML
Links, text boxes, selects, radios, checkboxes, buttons, forms, and content.
Depends what you are building. I have certainly had more frustration using single page or collections of single page apps. It is very rare that they get the back/forward button handling and refresh handling exactly right.
Are you sure about that, I don't think many of the users I know could tell the difference.
I'd agree, but I really can't say I enjoy making websites without at least a templating engine. I use Twig (80% with silex micro framework.. ).
If I'm creating a static page I would just create a html page (no php required)
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.
Hello world! in PHP is simply:
Hello world!
People forget PHP is still a template language for the web.
> 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 C1 or VC1S at scaleway is 3.6€ per month. This gives you total control to install anything (nodejs, ...)
...and now you're a sysadmin, with a whole new world of exciting career opportunities. And if you can also write bash scripts and spell Jenkins, welcome to devops!
The point is that if you're 13 years old, somewhat crafty, and just want to make a website that puts text on dank memes using ImageMagick to impress your friends, PHP and $3/month hosting with a friendly alligator that you can show to your mom to get her to put her CC in without thinking you'll get hauled off by a black helicopter...will get you to done quickly without having to read a foot of O'Reilly books, 20 DigitalOcean tutorials, 57 Wikipedia pages, and 118 StackOverflow answers.
Spaghetti PHP on shared hosting written by copy/pasting comments from the PHP docs and SO is a fantastic gateway drug for teens who end up being great developers. I love it.
Just write "Hello, world!" in a file without the quotation marks, and nothing else. Save, then run. Will print what you asked it to.
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.
When I first read that I saw the nice girl with the red T-Shirt and thought, wow, the simplest way of writing Hello World in PHP is literally
Hello World
Of course this would be broken HTML but first it displays, and second you could configure the web server to send
Content-Type: text/plain
'old' vs 'modern':
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.
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.
We can't have fun anymore. Web dev is serious business.
No one even writes javascript anymore, they compile it from Haskell or whatever. That's how serious it is.
I'm curious, how did you find yourself taken to those technologies? What made you feel like you couldn't achieve it in vanilla JS?
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.
Curious what others think
You do realise this article wasn't written as a beginner's tutorial but as a sarcastic view of modern web dev?
And where is the VM, the docker images, the swarm in the cloud to make HA and the right https configuration ?
I hope that VM is behind Elastic Beanstalk
Admittedly, no I didn't.
What's the tell? I obviously missed it :(
I am going to leave this here...
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...
I don't mind this article as long as it's classified as satire.
Is it though? The author described my company's tech stack. And I thought I had it bad in today's ops landscape.
Satire to an extent but also somewhat true.
"You can’t build a decent modern application without frameworks."
Bullshit, especially on the PHP / backend side. It's 2017, we should know how to avoid over engineering simple things.
Then, come peer code review/pull request by a senior/lead person, will be declined with the comment <? echo "Hello, overengineered world." ?>
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...
But we're now using "Agile development", so I guess we have to use those things.
Nailed 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.
Sorry but if you love PHP and use as your main language, why you don't complete any sideproject ? I don't understand your statement.
I do complete side projects, but I don't complete more than I complete. Often it's because trying to balance multiple projects when each is using multiple frameworks in different ways becomes a massive headache, things get paused and then canned because now there's newer buzz-word frameworks to use!
Side projects are natural places for programmers to get lost in this kind of bike-shedding/yak-shaving/etc., since they're not under the same kind of "this needs to ship on Tuesday or I lose my job" pressure that work projects are.
And in fairness, one of the better reasons to do a side project is to get up to speed on some fashionable technology so you can get a better job; that may well be of more value to you than the nominal deliverable, in which case it could make sense to prioritise it.
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.
The only thing missing from projects I've seen up close is that the value would be selected from the database using a stored procedure.
Or GraphSQL!
Sometimes I miss the old good days with PHP mixed in HTML.
Maybe wasn't the best solution but it worked...and was fast too.
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.
Having had to find and fix a bug in a very long page like that recently I can definitively say I don't. Horrible.
Granted the person who wrote it obviously didn't care but that setup was awful for anything of any size.
You can write bad code(not modular) with every language...
If you use some include() in php, you can avoid long php/html pages...
What I really miss is that was very fast "GET SHIT DONE" with PHP.
>If you use some include() in php, you can avoid long php/html pages...
In my experience, you just get long PHP pages including other long PHP pages, globals defined in one and used in others, included files that contain nothing but HTML, and other madness.
You can certainly GET SHIT DONE in PHP with a bit more coherence. Composer, with its autoloader and a router (probably nikic/fastroute) won't get in your way, your code will be more organized, modular, and lightweight, dependencies can be managed, etc.
Is non-modular code always necessarily bad?
> 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...
What about internationalisation ? You have to add i18n.
well, it is our job as programmers is to waste ... err ... utilize all that hardware power/bandwidth that Moore law has been showering us with...
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.
What is the point in writing blog posts like this?
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.
Right. Let's just delete everything and go back to a world where even more websites are packed full of vulnerabilities, written in spaghetti PHP!
I expect adding yet more lines of code will reduce vulnerabilities.