PHP + Ajax scripts or the modern ecosystem dilemma
threader.app
threader.app
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.
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.
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.
> a whole lot of of folks who have been doing a lot of work with PHP who didn't want to learn that toolchain.
Those people are not entitled to learn one thing and then be able to get work forever, the wordpress technical leadership (i.e. the ones who actually work on the core software day to day and make the technical decisions) are making changes that they feel enhance the product or make it easier to maintain, if a particular wordpress developer has a problem with that then they can either choose to support only the old versions or just learn something new. The other option is to work on some other PHP software that isn't making changes.
But the WordPress "Community" has a lot of peculiarities that are unique to that system.
Well, I develop SPA and never did something like that. More work to show button? Oh, it must be React or Vue. I find them very prehistoric. The way I write a button in ExtJS for example is
{ xtype: "button", text: "OK" }
That's it, no CSS, no HTML.
> Oh, it must be React or Vue. I find them very prehistoric.
Modern JS development in a nutshell.
And let's not even get into customizing. Attaching CSS rules to four different generated nested divs, inline style declarations to both the object and its underlying element, custom XTemplates... Abstractions get leaky rather fast, if you're not doing the "3270 terminal forms meet Excel 2003" enterprise UI.
Or gain enough seniority / technical respect to convince your team or company to use a different technology for some aspect of the business, and transform where you are working into where you want to be working.
I need Go with ADT and pattern matching.
In JavaScript i also want to see JS being used as vmcode and a higher level language similar to Go with ADTs/pattern matching compiling down to JS and everyone using it.
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.
That's the only hackish portion out of there, otherwise I'd agree. I rather get back what I expect from an endpoint not some mixture of things.
If someone requests /users.json I return JSON. If someone requests /users.html I return a document with rules in JS for how to build the HTML based on the data (Vue) and the JSON to build it with. In both cases the JSON is the important part, the Vue stuff included in the HTML version is just a transform on that data to be applied by the client. In that respect, I think not including the desired JSON would by hacky, requiring a separate request for the actual data you requested initially.
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?
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.
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.
Well, in this case development is done through Vim on the remote server, first in a dev environment branch, and then pulled from production. It would require installing the tool chain on the server, which is an artifact of my development process, but nevertheless should require consideration in my case.
But yeah, I'm just describing my setup, and the ease of which it allows getting started and productive. I'm wasn't really advocating for or against using a build process for the front end in general, just noting my current process. I imagine if I was using a lot of modules in my front-end, I would see the benefit of putting more tooling in place to maintain and manage it fairly quickly.
I can't help but feel that the road to maintenance hell is scaled with tiny tiny things.
That's a lovely stack you got there. I'm a Perl guy (sometimes) myself, and I hated all the bloat of the JavaScript tooling. I recently found Vue and I fell in love with how light-weight it is.
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.
I think it's an unfair over-generalization. There are quite a few places that started building their tech a fair number of years ago, and have accumulated quite a legacy that needs to be maintained. They would probably want someone with decent knowledge of those dated technologies. The question is, given the choice, would you, personally, want to work on a legacy system, or would you rather prefer to work with something new and shiny. I think the answer will overwhelmingly be the latter. I personally am sure I would pick new and shiny, because it is generally much more pleasant and satisfying to work with than old technologies.
I prefer not to be on the bleeding edge of stuff, especially not in the JS world - got bitten too often by incomplete, missing or flat out wrong official documentation, horrenduous bugs, incompatibilities and sudden breaking changes all over the place.
Side note to all shiny tool vendors out there, if you want people to try out your stuff, provide usable documentation and don't force your users to copy-and-paste from StackOverflow...
Yeah, webpack was definitely the worst offender I remember. How many days were lost in trying to get it to behave... sigh.
You could also easily get into contracting or freelance development too, since many companies don't really care what tech a developer/team uses so long as the work gets done.
2. But this is definitely true. Additionally, your average Joe doesn't care about the tech you use. They care about what the product actually does, and if works well...they won't care if it's React or jQuery (or whatever).
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.
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.
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.
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.
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...
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.
Additionally, you will find that other people (third parties) have written code that integrates with these frameworks, and this allows you to re-use their code instead of writing your own.
Finally, in terms of maintenance, it will be easier to hand over the application to new developers, because they might be familiar with either Laravel or Symfony.
It’s a vicious, pathetic cycle.
More fool you (and your employer) I guess.
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
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)
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.
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.
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.
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.
Considering serverless lambda i isolation isn't a worthy comparison.
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".
i'm personally a pragmatist who likes systems thinking - a hand coded form + CGI still works just as well as a full featured SPA to 'correctly fulfill' requirements, the variable in question is the requirements.
... Yeah.
Source:
If you have a small website plain php/jquery will be faster and simplier to work with.
Php still runs a majority of the web.