
“Hello, (real) world” in PHP in 2017 - skazka16
https://kukuruku.co/post/hello-real-world-in-php-in-2017/
======
vectorpush
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.

~~~
dheera
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?

~~~
ponyfleisch
> 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.

~~~
shakna
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?

~~~
erlehmann_
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](http://news.dieweltistgarnichtso.net/bin/redo-sh.html)

~~~
shakna
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.

~~~
erlehmann_
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)?

~~~
shakna
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:

    
    
        $(echo 'require "foo"' > bar.lua)
    

Then it can lookup those when the lua file is called, later in the process.

So how would this be a limitation of make itself? The limitation only exists
in what you call with make... Which could be anything.

~~~
erlehmann_
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.

~~~
shakna
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.

~~~
erlehmann_
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.

------
sixdimensional
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.

~~~
frou_dh
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.

~~~
coliveira
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.

~~~
woah
Who do you think is making money off open source frameworks?

~~~
pjmlp
Consultants that wrote those frameworks in first place and offer their
services for help, or go to conferences giving talks about them.

~~~
seanp2k2
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.

------
robbiewxyz
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.

~~~
m_fayer
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.

~~~
Klathmon
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.

~~~
laumars
Except it is simple:

    
    
        <html>
            <head>
                <title>Hello World</title>
            </head>
            <body>
                Hello World
            </body>
        </html>
    

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.

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.

~~~
seanp2k2
+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.

~~~
laumars
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.

------
bikamonki
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.

~~~
seanp2k2
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.

------
kuschku
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 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
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.

~~~
kuschku
Because, once you start working with complex systems, you’ll require complex
frameworks.

That influences the way the entire language goes.

------
libeclipse
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...

~~~
sixdimensional
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.

~~~
endymi0n
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".

~~~
khedoros1
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.

~~~
iiv
I think the word you're looking for is "satire".

~~~
khedoros1
That has extra connotations of parody that I was trying to avoid.

------
okket
This is a bit like

    
    
      $ echo 'Hello World!'
    

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.

~~~
adevine
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).

------
ponyfleisch
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.

~~~
raziel2p
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.

~~~
ponyfleisch
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.

------
Entangled
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.

~~~
travisjungroth
Users overwhelmingly prefer some amount of client-side interaction, so how do
you do that without JavaScript?

~~~
rabidrat
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).

~~~
martin_a
Most people don´t know how to build this because their X MB JS framework just
slows everything down.

------
lohengramm
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.

------
DanHulton
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.

~~~
unscaled
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.

------
megous
Hello world! in PHP is simply:

Hello world!

People forget PHP is still a template language for the web.

------
camus2
> 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.

~~~
webreac
a C1 or VC1S at scaleway is 3.6€ per month. This gives you total control to
install anything (nodejs, ...)

~~~
seanp2k2
...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.

------
z92
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.

------
_nalply
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
    

(no <?php and so on).

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
    

without charset parameter because YAGNI.

------
quickben
'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.

------
xchaotic
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.

~~~
krapp
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.

------
iamdave
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

~~~
halfdan
You do realise this article wasn't written as a beginner's tutorial but as a
sarcastic view of modern web dev?

~~~
SFJulie
And where is the VM, the docker images, the swarm in the cloud to make HA and
the right https configuration ?

~~~
iDemonix
I hope that VM is behind Elastic Beanstalk

------
partycoder
I am going to leave this here...

[https://en.wikipedia.org/wiki/Rule_of_least_power](https://en.wikipedia.org/wiki/Rule_of_least_power)

If you enjoy overengineered code, check:

\- Fizzbuzz Enterprise Edition:
[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

\- Fizzbuzz in Tensorflow: [https://github.com/joelgrus/fizz-buzz-
tensorflow/blob/master...](https://github.com/joelgrus/fizz-buzz-
tensorflow/blob/master/fizz_buzz.py)

------
mike503
I don't mind this article as long as it's classified as satire.

~~~
scurvy
Is it though? The author described my company's tech stack. And I thought I
had it bad in today's ops landscape.

------
wanderr
"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.

------
hugodahl
Then, come peer code review/pull request by a senior/lead person, will be
declined with the comment <? echo "Hello, overengineered world." ?>

------
mndewitt
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...

~~~
dheera
But we're now using "Agile development", so I guess we have to use those
things.

------
iDemonix
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.

~~~
CCing
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.

~~~
smacktoward
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.

~~~
rwallace
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.

------
methodin
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.

------
buro9
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.

~~~
CCing
Or GraphSQL!

------
CCing
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.

~~~
mythrwy
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.

~~~
CCing
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.

~~~
krapp
>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.

------
wernercd
> 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...

------
guillem_lefait
What about internationalisation ? You have to add i18n.

------
trhway
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...

------
nillawafer
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.

~~~
seanp2k2
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.

------
jakon89
What is the point in writing blog posts like this?

~~~
ponyfleisch
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.

------
Ambrosia
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!

~~~
tommorris
I expect adding yet more lines of code will reduce vulnerabilities.

