It’s hard to justify using anything other than JS or if you wanna be fancy, Web Assbly, for the FE.
Any other front end language involves generating Javascript from your language, which inevitably ends up with you making a weird Frankenstein project that mixes the two.
I’d rather just use stuff like Webpack or Vite to compile my JS front-end out of JS (or TS) from the start. It always ends up being a cleaner result.
My backend though can be whatever the fuck I want it to be.
But if you ever think dynamically compiling/transpiling a JS front end on the fly on demand is a good idea, instead of simply just delivering static pre-compiled/transpiled pages, you’re part of the problem for why the web is so slow and bloated.
It’s wild how crazy of projects people will build that take 3 entire seconds to just deliver a 500kb static form that doesn’t even need angular to do anything. They turn a couple hundred kb into several mb for no useful reason, it’s wild.
On that last bit. I agree with you, but people are getting paid to produce, and since they probably just know angular, they use angular everywhere.
I prefer html personally :x
But yeah, I mostly blame the project managers that encourage this behavior, it’s wild how much overengineering goes into basic stuff like making mostly static websites.
Same, plain old HTML, and if I need some reactivity then Stimulus. And if need even more reactivity, then VueJS / Alpine. If the form can’t be submitted via a regular submit button, it infuriates me.
To my understanding, you can’t really use WebAssembly for the frontend - it doesn’t support manipulating the DOM, so you still need to offload a lot of the work to JS. It’s an uncontested language when it comes to web frontend.
It does support it, it’s just slower than JS. WA is faster in other aspects though, so frameworks that compile to WA (like the Rust framework Leptos) still end up being faster than a lot of JS ones.
I find that the only reason for SSR existence is to be able to just move a JS frontend to the backend for SEO/client performonce reasons with almost no effort. If the frontend really needs to be highly interactive then yeah, a FE framework makes things easier. But then you are locking yourself to using JS in the backend. Voluntarily locking yourself to use an objectively bad language.
Then there are the react/angular/other people, who build everything in these frontends.
I really hope tools like htmx gain traction, since it looks like a model able to solve the current JS madness.
I’m not liking htmx, I checked it out, it seemed promising, but it has giant gaping security holes in it so I can’t endorse it.
I have been sticking to using Ejs with html-bundler-webpack
The combo is lightning fast and gives me a solid usability of html partials so I can modularize my front end in re-useable chunks.
It compiles to the static site fast for iterative development, it has everything I need baked in for common needs (minification, bundling, transpiling, cache busting, integrity, crossorigin, tree shaking, etc etx)
I like how it let’s me just focus on actually writing the html + js + css and not have to muck around with thirty boilerplate steps to just make the app run.
If I need a lot of reactivity I’ll use vue or angular but I so so rarely need that.
And now with the template element, half the time reactivity can just be done with those.
Only time I actually need react/vue is when I have to frequently mutate/delete in the DOM.
But if I purely am additive, adding things to the DOM, template elements are plenty.
Could you elaborate on the htmx security holes? I only know about xss attacks, and for those it’s trivial to sanitize in the backend.
I too gravitate towards just templating for static or simple interactivity, but for pages that need SEO and interactivity I’m still wondering what’s a good solution that doesn’t involve SSR and a js framework. For a recent project I had I generated the html in php and sent a lot of pure js for dom manipulation
Htmx has a bunch of logic that basically completely bypasses Content Security Policy stuff, as it has its own pseudo baked in “execute inline js” logic that executes arbitrary javascript via attributes on html elements.
Since this gets executed by the HTMX logic you load in from their library, it effectively allows an attacker to arbitrarily execute js via manipulating the DOM, and Content Security Policy won’t pick it up because HTMX parses the attribute and executes on behalf of it (and you have already whitelisted HTMX in your CSP for it to function)
Result: It punctures a giant hole in your CSP, rendering it useless.
There’s technically a flag you can flip to disable this functionality, but its via the dom so… not reliable imo. If I could pre-compile HTMX ahead of time with that functionality completely disabled to the degree it doesnt even get compiled into the output .js at all, then I would trust it.
But the fact all the logic is still technically there in the library I have loaded and I am purely relying on “this flag in the dom should block this from working, probably”, I don’t see that as very secure.
So until that gets fixed and I can compile htmx with webpack or vite in order to completely treeshake that functionality right the hell out of my output, I aint gonna recommend anyone use it if they want an iota of security on their site. It’s got literally baked in security bypasses, don’t use it.
Hell Id even just be happy if they released a “htmx-lite” package I could use, that just doesnt have that functionality baked in, thatd be enough to make me consider it.
Not sure if it was the first, but PHP still beats a lot of other “platforms/framework” because thats what some of these items on the list are in terms of ease of embedding code directly into what you see what you get frontend code (HTML). It inserts backend code into HTML like javascript and that was very convenient and easy to learn, still easier than figuring out some of these platforms different templating shortcodes, that and its constant development and community support. I used to live on the PHP docs comments… it was a great community.
That’s possible with some java frameworks, no? The “insert code into the html file”? I remember doing that in college (~2010), but I don’t remember the framework we used
Javascript, perhaps?
No, it was something that used JSP (java server pages), you didn’t use a single line of javascript. Maybe it was pure JSP, I don’t remember, really.
Eww
2022: learn python
Who said that, exactly?
The dude trying to push Django in 2003
This year is finally the year of Python, I can feel it!
I’ve been waiting so long for people to realize they should be using the second best language at everything.
PHP is amazing
If you’re thinking of PHP version less than 8 you need to have another look
Totally stateless. Uncached server side rendered response times in double digit milliseconds.
Types
Extremely battle, highly tested frameworks.
Excellent tooling for tdd, bdd, static analysis, automated browser testing, coding standards and auto fixing. Even fully automated refactoring for things like package upgrades (Rector)
Regular, solid, releases bringing updates and fixes
Arguably one of the best package management systems, Composer. And only one, none of this constantly changing tooling that some other ecosystems seem to do
Properly open source platforms to power all kinds of web projects from e-commerce, CRM, social, scraping, analytics, monitoring, API, CMS, blogging
Basically if your target is server side web stuff then it’s really good
Or, you can continue to demonstrate how out of touch you are by continuing with the old “PHP bad” jokes if you want!
What’s wrong with version 8?
he meant 8 is great
Dude was saying that 8 is good, but people still think of version 5 when talking about PHP. Not recommended to still use in 2023.
Even 5.3 was good enough.
4 was hilariously bad though
I’d say 5.4 was when it publicly got great - but yea, a lot of ground work for that was in 5.2/5.3
On the opposite - version 8 is great.
On the note of testing, Pest is still one of the best testing options I’ve seen across a variety of langs.
not only that but you just install it with the lamp stack setting in ubuntu tasksel with apache and mariadb. the beating that these can take (except maybe the sql) and survive is great. you also have access to the whole of linux to do more advanced stuff, while other languages/ stacks shy away from exec
All of that can be the same as other stacks except the Apache bit. You can stand up a Go application on Ubuntu hitting MariaDB as its persistence layer. Or Python. Or Node. Or Java. Or even Ruby. Shit, Haskell can do it.
Also,execis a code smell. Arbitrary code execution is a massive security risk, and the effort to mitigate that risk is often less than explicitly building out the required functionality.I think you need to explore more technologies, my friend. And read up on some security things
Edit: I now realize you mean
execas in calling out to a shell. All languages have this. Still, the overhead of spawning and managing a new process is often more than just implementing the logic in your application itself.I personally prefer hestiaCP but yes
other languages/ stacks shy away from exec
I’m sorry, what?
Turns out arbitrary code execution is actually great(!)
it does not have to be arbitrary my dude
Problem is, you’re mixing a number of different concepts into a nonsensical claim.
Exec as an “execute a string as a language instructions” is nothing new nor unique to PHP. Ruby on Rails, for example, uses it in a controlled manner to generate methods on ActiveRecord models.
Exec as an “replace this process with another process” is old news again. It’s not even language specific.
Popen/spawn family (which seems to be what you alluded to) is, once again, nothing new and is used everywhere.
i just meant that python’s and node’s implementation is shit
Extremely strong functional programmer support, too!
Uncached server side rendered response times in double digit milliseconds.
Thirst thought, that sounds slow. But for the use case of delivering html over the Internet it is fast enough.
Get this man some water.
Double digit milliseconds sounds slow to you?
For a bit of templating? Yes! What drives response times up is typically the database or some RPC, both of which are out of control of PHP, so I assume these were not factored in (because PHP can’t win anything there in a comparison).
Anything under like 100ms load is instant to the user, especially a page load. It’s a balancing act of developer experience vs performance. To split hairs over milliseconds seems inconsequential to me. I mean, PHP requires $ before variables! That’s the real controversy :p
Anything under like 100ms load is instant to the user, especially a page load.
True, but it accumulates. Every ms I save on templating I can “waste” on I/O, DB, upstream service calls, etc.
If it’s stateless and nothing is kept in memory, can you have a connection pool?
If you run it in old-school CGI mode, no, because each request would spawn a new process. But that’s nowhere near state-of-the-art. So typically you would still have a long-running process somewhere that could manage a connection pool. No idea if it does, though. Can’t imagine that it wouldn’t, however, since PHP would be slaughtered in benchmarks if there was no way to keep connections (or pools) open across requests.
Laravel
What is dead may never die
Learn rails in 2004? Good luck. It wasn’t released until 2006
This says it was released at the end of 2004
https://rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh
It was released in 2004. I had a co-worker who was hugely into it in 2005. Entirely coincidentally, he was also into absurdly overcomplicated code and clusterfuck projects that failed after years and millions of dollars.
He was also the only programmer I’ve ever known whose code literally nearly killed a child.
Explain that last sentence please
He was also the only programmer I’ve ever known whose code literally nearly killed a child.
You can’t just leave it at that…
The code was to remotely control (from a PDA) a baseball-throwing machine that had a top speed of 125 mph. This dude fucked everything up for more than a year but somehow was kept on the project. They then had him write a version of the software to be used for Little Leaguers. He decided to test out this version for the first time on a field with actual Little Leaguers - the first ball from the machine was supposed to be a slow grounder to the shortstop, but was instead a 125 mph knuckleball a foot over the kid’s head.
If you don’t know baseball, a knuckleball is a ball with no spin so its movement is incredibly random.
Edit: incidentally, the reason this happened is that the guy’s code originally specified the speeds of the two wheels (a baseball-throwing machine uses two wheels with tires spinning at high speed and a baseball is inserted between them and shot out thereby) using Ints with positive values between 0 and 32767. At some point he decided this was clunky (true) and changed the API to accept Float values between 0.0 and 1.0. All well and good, but this produced a big mess of compile errors in his code which he “fixed” by wrapping every call to the speeds method with Clamp ( CFloat ( iSpeedParam, 0.0, 1.0 ) ). His Little League code passed formerly reasonable integer speed values of, say, 5000 and 6000 (which should have produced something like a 20 mph ball with a bit of topspin) which were then cast and clamped to 1.0 and 1.0, meaning both wheels spun at maximum speed, ejecting a ball at 125 mph with no spin.
Haha that sounds like the epitome of testing in prod 🤣
Technically, kids are in development.
I really wanted to have at least one kid so I could name him “Developmestuction”.
Oof
That’s not true. It was in fact released in 2004 and 1.0 was in 2005.
There are two kind of programming languages:
- The ones everyone complaints about
- The ones nobody uses.
PHP isn’t dead. It’s just smelled that way for decades.
PHP is a shit language, but far from dead. There are too many legacy killer apps that are used A LOT and won’t be rewritten in a different language anytime soon. E.g. Wordpress, Mediawiki (The engine behind wikipedia and other wikis), Nextcloud, Typo3, …
Apart from Python, is anyone of the listed contenders actually still breathing?
Only if you count Angular as the same as AngularJS
Next, Angular, Django, RoR?
People are still using those?
Probably not starting a lot of new projects in them, but there’s loads of valuable software literally being the main income for companies in all of them.
Well, you can say exactly the same about COBOL…
Flask sure is.
Ruby on rails is alive, just not as popular. ASP.NET is popular but looks nothing like it did then; probably for the best.
Honestly, despite my experience in standalone programming and algorithms, my experience in web development is limited. I’ve had experience with ASP dot NET, Actix (Rust framework Lemmy is powered by) with Diesel ORM, and PHP. ASP is limited in .NET ecosystem, and the primary IDE to develop ASP dot NET apps is proprietary, not something I want to work with. Actix is doing pretty good, it uses Tokio internally, one of the fastest and most robust async frameworks in the wild. I’ve been using Rust for more than 2 years, and I’d be honest: it was designed for medium- and large-scale application development. For making prototypes, you probably want another programming language. And I see PHP as one of the easiest ways to prototype.
For Django, I’ve never used it, maybe I’ll have to use someday. Nevertheless, I see Python as a rather bloated (in terms of overlapping language features) language which suffers from similar problems as PHP, like no type checking (by default). Also, Python packages are tied to some exact version of Python, which causes a large dependency mess when using multiple packages (Rust also has this problem, but at much smaller scale, and developers of packages often use conditional compiling of language features). Meanwhile, I think that some Python problems could be resolved using a package manifest file, like Rust does.
If you have something to add, go on, because I’m always thinking what server language/framework I should use for my Next Big ProjectTM.
I personally like Axum over Actix, less macros and more clever trait magic.
This is an irritating meme.
Were people saying PHP was dead in 1995, the year it was released? I guess maybe?
But who was suggesting abandoning PHP for Django in 2003, two years before the latter was publicly released? I suppose the person who made this must’ve read that Django development started in 2003 and gone with that; most of these years correspond with when the respective project started.
So, the reason Perl (which remained more popular for web development than PHP or any of these things into the early 2000s) isn’t on the list must be because it actually predates PHP.
But then what is up with Python in 2022?
Yeah, plus PHP was very popular circa 2011-2016 and laravel was loved by many around that time and beyond. It’s always been a useful language.
I also appreciate that you’re supposed to learn Django 19 years before you learn Python.
Flask too
django and flask are python btw and people wanted to learn python or perl from like 15 years ago, the popularity of python 2 and its “Issues” led to robust dev on python 3, not to mention it being a default for many linux distros since a long time ago
