3 ms·

Based on my experience: - many frontend engineers would run away from companies that hire for jQuery skills. Frontend engineers nowadays usually want to write

by danwee 4y ago

Based on my experience: - many frontend engineers would run away from companies that hire for jQuery skills. Frontend engineers nowadays usually want to write React and use Vercel and what not (even though the product may only require jQuery) - many backend engineers would run away from companies that hire for PHP. Backende engineers nowadays usually want to write Python/Go/Kotlin/Java, well, anything except PHP, even though modern PHP is well-suited for most SaaS/web-products - many infrastructure engineers would only apply for companies that use K8s, modern CI/CD pipelines (e.g., GitHub/GitLab) and cloud providers (e.g., AWS, GCP) and run away from anything that smells like on-prem installations using Ansible/Chef/custom bash scripts, even though the vast majority of web products out there do not need K8s/AWS/Terraform/etc. I think in general, engineers do want to build useful stuff for people but only if they get to play with the coolest tech.

mwcampbell 4y ago
All right, you got me. I've eschewed PHP for almost 20 years. And I don't use jQuery in new code either, though I do sometimes use plain, framework-less JavaScript, which in modern browsers provides a lot of the functionality of jQuery but with no runtime overhead. I wouldn't disqualify a candidate for being primarily experienced with jQuery, and I'd be curious to see their modern PHP.
bluefirebrand 4y ago
> even though modern PHP is well-suited for most SaaS/web-products Maybe, but is it pleasant to use? My memories of PHP are not fond at all, it is a really miserable language to write. Maybe it has the features it needs but is it actually nice to use? Same with JQuery. There's a lot of rose colored glasses these days for JQuery, imo. It is not fun to write. Also the complexity lift to use React versus using JQuery is minor compared to the complexity lift distributed K8s microservices have over an NGinx server with a custom bash script. The extra complexity of the scalable microservices architecture might be sufficient to actually sink your startup. The extra complexity of using React over JQuery costs... Essentially nothing. Edit: I guess what I'm really saying is that choosing a different backend technology or frontend framework isn't remotely the same as choosing to build a scalable distributed microservice architecture over a static bare metal server. Choosing a technology is a choice based on what you want to work with and what you think you can hire other people to work with. Choosing K8s terraform distributed microservices for scalability early on is the most premature optimization you can possibly make. Get a customer before thinking about scaling.
marcosdumay 4y ago
A Python/Go/Kotlin/Java framework has the same amount of complexity as a PHP one (you are using one, right? It's not <?php tags all over the source, right?) and are nicer to use. (Not much nicer, mind you, PHP frameworks have evolved too, but still nicer.) Isn't that what we expect from evolving technologies? (And well, if you are doing <?php all over, bare Python with print statements has the same complexity, with about the same downsides. Nobody will want to touch it, for very good reasons.) jQuery is a very predictive mark for decades old leggacy cruft that nobody is allowed to improve. The modern equivalent is vanilla JS, that is simpler, about as powerful, and perfectly viable to hire for. There's actually no technical problem with jQuery, it just correlates very well with bad companies. The infrastructure world has a real problem. A large part of it is that Puppet, Ansible and Chef are all badly managed centralized, complex pieces of software, and custom bash scripts can be anything. Also, cloud offerings tend to minimize on-call incidents, and companies normally have very bad policies about on-call time (kept secret until the candidate has no other option). A purely community oriented ops tool (Apache style) would do wonders here. As would better labor laws (on the US mostly). (And edit here, the trend on newer ecosystems, like Go, Rust and Haskell - and old language where the ecosystem is mostly new, is to make the backend frameworks simpler. So you get a nicer to use system with less complexity to stop you from solving issues.)

by danwee 4y ago

mwcampbell 4y ago

All right, you got me. I've eschewed PHP for almost 20 years. And I don't use jQuery in new code either, though I do sometimes use plain, framework-less JavaScript, which in modern browsers provides a lot of the functionality of jQuery but with no runtime overhead. I wouldn't disqualify a candidate for being primarily experienced with jQuery, and I'd be curious to see their modern PHP.

bluefirebrand 4y ago

> even though modern PHP is well-suited for most SaaS/web-products Maybe, but is it pleasant to use? My memories of PHP are not fond at all, it is a really miserable language to write. Maybe it has the features it needs but is it actually nice to use? Same with JQuery. There's a lot of rose colored glasses these days for JQuery, imo. It is not fun to write. Also the complexity lift to use React versus using JQuery is minor compared to the complexity lift distributed K8s microservices have over an NGinx server with a custom bash script. The extra complexity of the scalable microservices architecture might be sufficient to actually sink your startup. The extra complexity of using React over JQuery costs... Essentially nothing. Edit: I guess what I'm really saying is that choosing a different backend technology or frontend framework isn't remotely the same as choosing to build a scalable distributed microservice architecture over a static bare metal server. Choosing a technology is a choice based on what you want to work with and what you think you can hire other people to work with. Choosing K8s terraform distributed microservices for scalability early on is the most premature optimization you can possibly make. Get a customer before thinking about scaling.

marcosdumay 4y ago

A Python/Go/Kotlin/Java framework has the same amount of complexity as a PHP one (you are using one, right? It's not <?php tags all over the source, right?) and are nicer to use. (Not much nicer, mind you, PHP frameworks have evolved too, but still nicer.) Isn't that what we expect from evolving technologies? (And well, if you are doing <?php all over, bare Python with print statements has the same complexity, with about the same downsides. Nobody will want to touch it, for very good reasons.) jQuery is a very predictive mark for decades old leggacy cruft that nobody is allowed to improve. The modern equivalent is vanilla JS, that is simpler, about as powerful, and perfectly viable to hire for. There's actually no technical problem with jQuery, it just correlates very well with bad companies. The infrastructure world has a real problem. A large part of it is that Puppet, Ansible and Chef are all badly managed centralized, complex pieces of software, and custom bash scripts can be anything. Also, cloud offerings tend to minimize on-call incidents, and companies normally have very bad policies about on-call time (kept secret until the candidate has no other option). A purely community oriented ops tool (Apache style) would do wonders here. As would better labor laws (on the US mostly). (And edit here, the trend on newer ecosystems, like Go, Rust and Haskell - and old language where the ecosystem is mostly new, is to make the backend frameworks simpler. So you get a nicer to use system with less complexity to stop you from solving issues.)