“Hello, (real) world” in PHP in 2017(kukuruku.co) |
“Hello, (real) world” in PHP in 2017(kukuruku.co) |
Maybe wasn't the best solution but it worked...and was fast too.
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.
Granted the person who wrote it obviously didn't care but that setup was awful for anything of any size.
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.
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...
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.
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.
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?
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.
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.
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.
Turtles all the way down!
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.
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).
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.
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.
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.
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.
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.
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.
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.
------------------------
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.
------------------------
That influences the way the entire language goes.
I hope it's a joke...
"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» ?>"
$ 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.
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).
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.
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.
Links, text boxes, selects, radios, checkboxes, buttons, forms, and content.
If I'm creating a static page I would just create a html page (no php required)
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.
--- 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!
People forget PHP is still a template language for the web.
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.
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.
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.
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
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.
No one even writes javascript anymore, they compile it from Haskell or whatever. That's how serious it is.
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
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...
Bullshit, especially on the PHP / backend side. It's 2017, we should know how to avoid over engineering simple things.
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.
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.
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.
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.
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?
(in php/asp.net/python you should write something in backend for serve javascript responses as is it in rails with files .js.erb)
Is the cost really that high to warrant this?
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.
<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.
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.
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.
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.
Make runs on Windows, OS X, Linux and Android.
How is a Makefile quite limited?
• 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
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.
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)?
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.
How would you solve all three problems I listed using make(1)?
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:
$(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.
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.
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.