Javascript runs in the browser. Most issues I hear about and encounter myself end up being browser-related.
You mentined all of the things that aren’t connected to JS, and did not mention the one(s) that are. JS is the primary source of problems today. And hackers that break into the back-end. I operate almost exclusively on Macs and my Android phone, and I’ve got between three and six browsers on each one. None of them work the same — which is to say, when I run into a problem on one, I can usually solve it by switching to another browser. Every week it’s something different. The source of the problem is not worth my time to figure it out, and it’s really easy to switch to another browser. Don’t blame php or the back-end for quirks that are endemic to JS running in one specific browser. Even updates of the same browser can behave differently. And the behavior on the same browser can change from one day to the next, or one hour to the next. Nobody is changing the back-end that frequently, I can assure you. It’s the libraries the pages are loading up, or the code the site’s developers changed last night. I’ve been writing code in Delphi using TMS WEB Core, which is available both as a Delphi addon and a standalone package that runs in Visual Studio Code. It takes Delphi code (Object Pascal) and translates it into JS and packages it up so it runs in the browser. NONE of it is running in the back-end! It’s 100% browser based. And 100% of the weird issues I have are all browser related. Sure, there are bugs in the platform, but they are typically reproduced the same in every browser. Browser issues show up differently in one browser, maybe two, but not in all of them. A lot of browsers are using the Chromium engine, so quirks in it can be reflected elsewhere, but they usually need to be running the same version of the engine for them to show up. It used to be that you had to test software on different machines from different vendors, different versions of Windows or MacOS, and it cost you a lot of money to have all of those combinations of software and hardware available for testing. Today you just need to test on one hardware platform with variations of browsers loaded on it, probably running in separate VMs or docker images to ensure you test with different versions of Chromium and whatnot. Same old sh*t, different approach. As far as WP goes, I think it’s internal architecture has become obsolete. Layers and layers of crap have been added to convert asynchronous events into something that serializes them, and the people writing plugins and themes are mostly inexperienced coders who don’t have a clue what’s what. Meanwhile there are people who have nothing else to do with their life but find ways to sneak into cracks and crevices in the back-end, and sometimes wide-open doors, left by said inexperienced coders who didn’t do a good job testing their code. “It works! Ship it!” The UX/UI logic is all being pushed out to the browser, and the business logic is being hidden behind REST APIs. I can build something in TMS WEB Core way faster than it takes to build in WP — it runs faster, is more solid, and is far easier to maintain. That can probably be said of most JS-based UX/UI dev tools today. The problem with Wordpress is … it’s Wordpress. The UX/UI is tightly coupled to the back-end because all of the user’s state is managed in the back-end. And it’s not an API, but just a huge mess of functions that are designed to be hijacked by programmers to get it to do pretty much anything out of the ordinary — if you can’t get it to support something in the UI, you need to build a plugin or theme to add it. And that code lives on the BACK-END and is susceptible to all of the myriad ways there are for hackers to throw sand in the gears. The whole damn platform is open to anybody who wants to poke and prod it’s guts! They even added an API but nobody uses it. If I need something to work a certain way using WEB Core, I can easily program it. I hide necessary business logic behind an authenticated REST API and the JS in the browser manages it all. The events are all asynchronous and I don’t have to worry about someone hacking into the back-end code and hijacking everything. I can build the services in any language and host it on any platform I want. In WP, you have to build a plugin and plan to maintain it as further WP updates will very likely break it in some unexpected way. Or if not the WP code than maybe one of the UI libs you’re working with change and someone updated a theme that loads a different version and screws up your code. IMHO, WP is just a big fat ugly mess that only gets worse over time. Just switch to a no-code / low-code solution that lets you custom-build what you need, and that isn’t dependent on dozens of things that can change from week to week and month to month as the underlying platform is patched to fix newly-discovered exploits and the UI libs get updated by updates in the plugins and themes. -David Schwartz > On Nov 13, 2024, at 9:12 AM, Keith Smith via PLUG-discuss > <plug-discuss@lists.phxlinux.org> wrote: > > Hi, > > This is kind of off topic, however WordPress is Open Source and I would > expect that the vast majority of WordPress is run on LAMP servers. > > My daily driver is a 10 year old Dell that has an i5 with 16G of RAM that > runs Kubuntu 24.04lts. > > I am running a blog using WordPress that is hosted on an Ubuntu server. > > I am having issues with the WordPress Gutenberg back end. I cannot get it to > do the things I want to do like bold text. At times is is sluggish. I've > read that WordPress has a 10 year plan to move to JavaScript. There is not a > lot of info available so it is unclear if the PHP code will be replaced as > well. If WordPress replaces the PHP back end I will leave WordPress. As it > is WordPress is hanging by a thread. > > These problems are new. I am also having formatting issues which might be due > to my theme. > > Is anyone having these issues or maybe other issues with WordPress? > > Ultimately I may create my own infrastructure or start building my own theme. > > Any feedback is very welcome. > > Keith > --------------------------------------------------- > PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org > To subscribe, unsubscribe, or to change your mail settings: > https://lists.phxlinux.org/mailman/listinfo/plug-discuss --------------------------------------------------- PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org To subscribe, unsubscribe, or to change your mail settings: https://lists.phxlinux.org/mailman/listinfo/plug-discuss
