
PHP + Ajax scripts or the modern ecosystem dilemma - seapunk
https://threader.app/thread/1078388060696576001
======
giancarlostoro
Use what you're best at, and if you're paid to use something, use it. If you
don't like what you're using at work, take your time to find a new job
opportunity. I feel like SPA's are overrated they take away performance and
stability from standard HTML websites with some AJAX capabilities thrown in.
When I first heard of a SPA it sounded perfect: you download all the HTML
you'll ever need once, and load content to the appropriate DIVs accordingly,
but now you gotta take a hike and basically do more work to show a button, or
a text box, or whatever. I mean no disrespect to people who love SPA web dev,
all power to you, but unless I'm paid a lot more, or I'm working on some
multimedia / social media type of site, I don't see the point. Sometimes SPA's
I see are done poorly which is another pet peeve.

~~~
scarecrowbob
I'm not totally sure about the context for the OP, but just recently there are
a lot of folks doing low-end PHP dev work for WordPress, and many of them are
now having to learn React because WordPress has changed its backend editor to
a system that is based around React.

Personally, I think that this is a good choice-- the editor system in that CMS
is a very good use case for complex JS technologies.

But at the same time, there are a whole lot of of folks who have been doing a
lot of work with PHP who didn't want to learn that toolchain.

In that context, it's a little complex: we have a whole ecosystem of
businesses and developers and software tooling that is being pushed over by
some core changes. I'd bet that there are going to be a lot of frustrated low-
end PHP devs dragged into learning modern-ish JS tooling.

~~~
arkh
> modern-ish JS tooling

This need a lot more scary quotes around modern and tooling.

The JS "ecosystem" is a cancer: nowadays when you want to do some front-end
work with some CSS you usually end with an install of node and
npm/webpack/the-shit-du-jour, half of them crying about incompatibilities and
how you should use the shit-du-lendemain instead to compile you don't really
don't know what, it still takes 20mn to see the result. All you wanted was to
edit some CSS. And surprise: now half of your other projects won't build
anymore because you had to install npm-1.911-HELP-ME-DAD and the option to not
install globally changed from -not-everywhere to --just-a-local-beer.

~~~
qudat
Yikes. There's nothing stopping someone from creating a CSS and HTML file and
being done. The trap is following standards and common practices for
enterprise-level front end development when they don't suit the requirements.
Simply editing a CSS file requires none of the things you are complaining
about. It certainly doesn't require globally installing npm packages.

~~~
arkh
Let's say you want to use bootstrap 4 and sprinkle some gradients. You'll have
to rebuild it. Which imposes the use of npm.

~~~
scarecrowbob
Yeah, if you want to use the tools you need to use the tool chain.

On the other hand, I work with a whole lot of other peoples' WordPress
projects. A lot of folks just crap some CSS wherever they can find a spot and
call it done.

FWIW, I'd rather troubleshoot someone's gulpfile than dick around with a 4K
line CSS file. But that's my choice and I know plenty of folks who pay their
bills and would rather grep (well, they don't use grep because they don't know
the CLI) and who love a monolithic CSS file.

I like the tools, some folks don't. But they aren't inherently bad tools, they
are just not right for everything.

------
kbenson
I would like to point out a middle ground, where I currently reside.

Back-end in whatever you want (Perl + Mojolicious for me), and a front end
using one of the major frameworks (Vue for me), but without even the need to
managing it all with node and NPM (you can still just use script tags, it's
not that hard if you don't go crazy with inclusions). Serve pages as simple
templates, with maybe some embedded JSON to cut out the initial AJAX request,
and now you're playing to the strengths of each part of the stack.

You have a back-end that you're comfortable with and possibly have your own
library of utilities for, you have a front-end that leverages all the power
the browser brings to the table, and you aren't mixing front-end jQuery style
actions with back-end templating and the pain that eventually results in.

~~~
azangru
> a front end using one of the major frameworks (Vue for me), but without even
> the need to managing it all with node and NPM

This sounds like such an arbitrarily painful limitation I couldn't resist
asking: why? As far as I heard, package managers have been regarded by every
language as a blessing. Ruby has its Bundler; Python has its pip; PHP has its
Composer (and I heard PHP programmers joke that they feel like grown-ups now,
when they have modern tools). Why would you deliberately exclude Node, NPM,
and the whole ecosystem that it brings to the table?

~~~
kbenson
Because I'm literally using Vue, Axios, a polyfill, and Bootstrap-Vue. Two CSS
link tags, and four script tags. Currently for external resources, but
trivially brought locally. It's an internal web-app, so it's not like
minification is even required, much less bundling.

No Javascript is used on the back-end currently. To use NPM/yarn/etc, I would
have to first install Node, and then configure it to build my stack. At some
point if I pull in a bunch of requirements, maybe that's worthwhile, but right
now, it's actually a fair amount of work for dubious return given my current
needs.

~~~
azangru
> I would have to first install Node

You mean, locally, on your machine? But it's not a big deal. Not even a small
deal. It's, like, not a deal at all.

But I get your point. I thought you were advocating a general approach, but
instead you were describing your specific setup.

~~~
fencepost
_But it 's not a big deal. Not even a small deal. It's, like, not a deal at
all._

I can't help but feel that the road to maintenance hell is scaled with tiny
tiny things.

~~~
azangru
But from the maintenance standpoint, a package manager together with some
bundling tool is so much more desirable than hand-copying links to scripts!

------
dvfjsdhgfv
This is a common theme on HN but it's actually quite simple:

1\. If you want to get hired, you need to know the tools in fashion now. It's
always been like that but recently these proliferated so much it's quite
difficult to catch up even in the market you specialize in.

2\. If you want to build a successful product, you need to be smart and use
what you know in the best way, and only spent your time to learn something new
if it's really necessary. That's why some of the biggest sites in the world
were written in PHP, Photoshop was originally written in Pascal, Minecraft in
Java etc.

There is much more to say about it but the essence is that.

~~~
cityzen
you forgot #3) If you want to learn how to sell you can get your own clients
and make great money and not have to get caught up in the hype.

I make a very comfortable living, wife stays home, we have no debt and I work
around 20 hours a week most weeks. Most of my clients are on retainer and I do
good work for them. We rarely talk about what "stack" we're using but we
always talk about the problems they're trying to solve.

Most of these arguments are about ego, someone being right and wrong and what
tools are the best. From an old fart I can tell you this... tools are only as
good as the person using them. If you are a shit developer, nothing is going
to save you from yourself.

It really seems to me like a huge issue these days is that people can't even
stick with a framework or language long enough to ever be decently good at it.
This seems to be due in part to your #1 - learning what is needed to get a job
and #2 - fear of building a product on the "wrong" stack when they scale to
billions of users in 2 weeks (hint: this doesn't happen).

The biggest lesson I've learned from building a product is that no matter what
tool you are using, you cannot engineer your way out of a marketing problem.
No marketing = no success. There is a lot of horribly coded garbage out there
making people tons of money because of marketing.

~~~
owyn
The two most profitable companies I worked for used PHP. And nowhere close to
the newest versions. The two least profitable both used C++.

Even with those experiences I would never say there's a correlation between
chosen language and success, because in all those cases it was the core
business idea that was the driver of success or failure.

I do still try to choose the right tool for the job based on some kind of
instinct and experience anyway.

Also, congrats on your gig. From where I'm standing (an old fart still
grinding it out at startup #7) that sounds totally awesome. This is going to
be my last startup though, I was going to accept my fate and go work for some
BigCo before it's too late otherwise I'll have no retirement at all. But if I
could find a nice niche like that, I'd happily work part time forever.

~~~
cityzen
Thanks! Feel free to shoot me an email (address in profile) if you have any
questions. In terms of retirement, I have been able to fund my wife's and my
retirement accounts each year. I think the biggest challenge of being solo is
that you really have to stick with it for a good 2 years to understand the ebb
and flow of the business. Sometimes it _looks_ like you make a lot less money
but when you factor in all of the benefits of being a business, it all pans
out.

I will also add that I am mostly a PHP dev and I do not work with WordPress at
all. There is a LOT of work out there, though.

~~~
rocannon
cityzen - your email address is not in your profile. I do have some questions
for you. My email address is in my profile.

------
altmind
The same php+jquery+ajax+plain css stack that used to work 7 years ago, would
likely still work today.

Thats a great departure from famous, glamorous new
orchestration/styling/components/web standards that are adopted before they
are ready and are obsolete in 18 months after deployment.

------
AdrianB1
Not a developer, but a low level IT manager in a top 50 Fortune 500 company:
for my area I chose to use almost plain PHP and jQuery and a few tools for our
internal use apps, not the latest, shiniest tech available for 3 days.

Finding developers with real expertise, being able to support the applications
5 or more years, having stuff that simply works is much more important than
using the obscure or temporary in fashion technology of the day. Yes, there
are so many options and there are so few that meet the criteria...

~~~
akie
I’m sorry, but you’re 5 to 10 years behind the times, and I say that as a non-
bandwagon-jumping old guy. Plain PHP these days is almost always a mistake,
there are new (and proven, stable) tools that provide significant benefits
without any real downsides.

~~~
AdrianB1
Can you please provide a few examples? Just curious how it can be simpler and
cheaper to build and maintain when performance is more than enough, usability
is great and the end results are exceeding all expectations. Other than being
out of fashion, what is wrong with things that simply work?

~~~
andrewmackrodt
I think plain PHP may have been taken to mean you're using an in house
framework without using a package manager such as composer. In this case it's
definitely more expensive to roll your own solution, especially when it comes
to maintenance and onboarding.

~~~
AdrianB1
Composer is included in the "tools" category, of course. There are other tools
used (ex: webpack, grunt, git and more), but I am looking at the stack (PHP +
SQL) as the primary components on topic for this discussion. What I am not
including are niche or fancy components that bring little or no value, add
complexity or limits the availability of developers or long time support. We
are also not writing code in Notepad (Windows shop by other people's choice,
no comment), so it's not stone age.

We used in the past libraries that were abandoned, technologies that were big
hypes for a year or two and disappeared, etc. In the corporate world you don't
have one product with millions of users, you have tens of small apps that have
thousands of users. Some are so simple I can write myself using existing
(internal library of) components in a few days using basic stuff like
Bootstrap (good enough), jQuery, Vue (nice one) and very carefully written SQL
code (that is where volume and complexity exists).

Again, I am no developer myself, but I can write code when needed at least as
good as the developers that I have from multiple suppliers. In the end is cost
versus benefits. We are very good at calculating both and in many cases the
bean counting tells me to continue doing what we do.

------
root_axis
Exactly! I don't understand all the complaining about the complexity of the
front-end; if you don't like modern front-end tools you're not obligated to
use them, all the old tools work just fine. Just because someone releases
their own work for free on the internet doesn't mean you're obligated to use
it. If you don't understand what problems a particular tool solves, you
_definitely_ shouldn't be using it. Stick to what you know or deal with the
learning curve. It's literally a software engineer's job to figure out the
best tools to solve the problem at the lowest cost, if you're just picking the
most popular tools because they're popular then _you_ are to blame.

I don't buy the employment gripe either. If you don't like working with the
tools that are popular in front-end development then it's time to pick a
different job. There's plenty of work in java, ruby, c#, swift, go, kotlin,
cpp etc, and a bunch of legacy PHP/JS systems that function in completely
different paradigms and ecosystems. If you're fresh out of school and JS is
the only language you know and you're frustrated by all the complexity, that's
not anyone's fault except your own lack of experience. Stop expecting everyone
to stop working on free tools because they confuse you.

/rant off

~~~
noitsnot
It's not that simple. If you don't like them, you have no choice. Every
company from large to small has jumped on the bandwagon. Maybe I'm wrong, but
companies want frontend dev with angular and react, but the complexity is at a
point where you need a back-end who understands data types and CS. So, you're
essentially taking a discounted rate or front-end pay while providing back-
end. A "Full stack" dev or worse, a Graphic Designer who is expected to do
front-end.

~~~
root_axis
> _It 's not that simple. If you don't like them, you have no choice. _

I already addressed that. If you don't like the contemporary front-end tools
there are plenty of other programming domains to work in that use other
languages and tools. There are also many huge legacy JS systems (especially in
the corporate world) that need traditional JS skillsets.

> but the complexity is at a point where you need a back-end who understands
> data types and CS

I would argue that front-end developers should already be expected to
understand "data types and CS" otherwise they should be earning a designer
salary instead of an engineer salary (no disrespect to designers, what they do
is also complex, but engineers are paid more on average).

> _A "Full stack" dev._

I disagree. A full stack dev, in addition to front-end, would be expected to
also understand how to wire-up back-end services and databases and create
abstractions that make this data available for the front-end or other back-end
consumers. There aren't really any positions with the exclusive front-end
title that also expects any of that. Being able to configure webpack or babel
is not "back end" or "full stack", webpack is just a pre-processing tool, not
unlike any of the other myriad front-end tools that have existed for years
(e.g. sass, less, haml, compass etc)

------
martin_drapeau
The beauty of front-end development is that you can USE WHATEVER YOU WANT. The
end-user really doesn't care. As long as the UI is good. The browser really
won't care either. It will interpret that JavaScript whatever framework or
library you've used.

When it comes to collaborating with fellow developers, its another story. We
switched to React at Amilia because its easier to hire developers.

For personal projects jQuery, Bootstrap and Backbone are still my tools of
choice.

~~~
JustSomeNobody
I bet if I searched HN I’d get more hits for “just use react” than I would for
“use whatever you want.”

------
tambourine_man
I love PHP and jQuery and use it whenever possible.

I really tried to find a reason to use Backbone, Angular, React over the
years. Vue is the only one that seems appealing but still, not terribly so.

 _editing PHP with Vim in production via a tmux session_

Replace production with development instance and you’re good to go.

~~~
AdrianB1
I did look at these from time to time, I find Vue as useful to simplify UI
logic without bringing a huge complexity or learning curve. It is just a
personal opinion, but I tend to see these as options you have, not mandatory
to use if you don't have a need for it.

Having more options can be better, the huge downside is the fragmentation. The
classic problem is: do you prefer a single programming language, a dozen or a
thousand? I would go for a dozen, one is not flexible enough, a thousand is
too fragmented for most to be worth considering.

------
emersonrsantos
Take serverless, for example. It’s just CGI that scales better. People will
see this simple, but powerful approach, and will hopefully return to a
transactional webpage programming style (as the Web was intended to be). All
the monoliths will be out of fashion again.

~~~
kokokokoko
I love to joke that cloud functions are just PHP shared hosts that support
node, go, etc as opposed to PHP, Perl etc. It is a bit of an exaggeration, of
course, but fun to joke about.

I agree completely. The tranactional nature of that shared hosting era made
hosting an application or website orders of magnitude cheaper and easier and
led to an absolute boom of open source solutions like Wordpress. I hope to see
some standardization across the serverless ecosystem to allow a similar
situation as opposed to the lock-in approach taken by AWS and other cloud
platforms.

------
stickfigure
I run a small SaaS business in a niche market. The whole company is two
engineers; our UI is a SPA built with react and material design.

We have one direct competitor, who launched around the same time we did. They
have at least 6 engineers (plus support staff); they built a traditional
webapp with some jquery.

We get a fair number of their users. They all gush about how easy our system
is to use and how much better the UX is. Some of this is the different
conceptual approach we took to the problem, but we couldn't have pulled that
off without the interactivity that a SPA gave us.

Modern web dev tools significantly raise the bar for customer experience.
Sure, you can build a PHP app with some jquery and form posts. If you have no
competition, you may do alright. But customers notice UX, and you should be
afraid of upstarts who do chase the "modern ecosystem".

~~~
chx
UX design and the technology used to implement it have nothing to do with each
other. Absolutely none.

~~~
stickfigure
You clearly weren't trying to build rich UIs in the 90s and 2000s with the
technology available then.

~~~
marpstar
React and Material UI are still just HTML, CSS, and JS.

~~~
stickfigure
...and all computer programs are "just" machine code. But good luck writing
modern apps with a hex editor.

------
cobythedog
I feel like I am missing something. Is this just a blog-response to a comment
on HN?

~~~
giancarlostoro
The tweet is at the top, but yeah it reads a little weird without the context
that it's a bunch of tweets.

Source:

[https://twitter.com/dan_abramov/status/1078388060696576001](https://twitter.com/dan_abramov/status/1078388060696576001)

------
jcroll
Whatever works but a lot of these modern tools were designed with good reasons
and good intentions. Build your mvp with PHP + Ajax, if it's successful tho
might not be long till you're hitting a wall and looking for more robust
solutions

~~~
wolco
PHP is modern and if you wanted to, you could use the latest laravel framework
or microframework with whatever bleeding edge version.

If you have a small website plain php/jquery will be faster and simplier to
work with.

------
samfisher83
[https://w3techs.com/technologies/details/pl-
php/all/all](https://w3techs.com/technologies/details/pl-php/all/all)

Php still runs a majority of the web.

------
Myrth
The "My way is better than yours" insecurity projection

