232 karma · joined June 29, 2021
The US phased out their SMS fees about the same time smart phones started to become popular. I think it was only due to regulation.
We use the concept to add meta tags to our client-side-rendered webapp for search indexing. We can decouple our client app from our server and deploy each separately. We use "serverless functions" to add some meta tags that need to be added server-side.
Granted, users don't know or care which engine they're using, but it would allow Mozilla to "control" important infrastructure that apps are deployed on. Maybe it would turn into a revenue stream by providing official support, or maybe it just helps keep Google's fingers out of everything.
Overall, I think it would just be a matter of which language you know better.
Laravel is far from dead; it's more popular than ever. The older versions that you might be familiar with have seen a lot of improvements over the last couple of years. They're fairly aggressive with deprecating older versions of PHP, while still supporting LTS versions.
Its ecosystem is really flexible, and generally has great solutions for anything web-related with easy configuration. I haven't found Laravel to be slow when building websites, but we always put a CDN in front of it, so it doesn't really matter how fast or slow the framework is.
If you want a lighter-weight core to start with, there's Lumen, which is designed to be an API-only version of Laravel. Forget templates, just return JSON (or whatever).
Laravel is a great solution for a lot of websites and applications. Maybe not some applications you have in mind, and that's ok. Pick the right tool for the job. As someone who used to hate PHP, modern Laravel would be my go-to if I need a backend and can't simply get by with a static site generator.
Having not used their software or hardware, I'd assume that for people purchasing a really expensive bike, $40/mo isn't bad. Still...it feels steep.
The single-file components are really nice. You still have separation of concerns, but everything is organized in once place.
The config-style components might be something some devs don't like (boilerplate code), but I find it a lot easier to quickly scan a new component and understand what's going on. Easy to identify the component's private data, computed values, child components, etc. In React or Angular (or Vue 3's new syntax), these different types of data could be anywhere in the file.
Being able to choose TS or JS in a component file has saved me a lot of time. I can set very strict tsconfig rules for files that benefit from typing, and simply use JS when I'm prototyping a feature or I require some library that doesn't have good TS support.
And finally, the developer experience is top-notch. Excellent browser dev-tools extension, ESLint rules help avoid common problems and confusing code (and a lot of them are auto-fixable), and I've never had an easier time with hot reloading than with Vue (HMR still doesn't work out of the box in Angular 13, and apparently it was a major focus of the last release).
There's certainly no industry standard for JS frameworks. It might be in your circle, but that's certainly not the case in the industry.
In my experience, I've found Vue to be a lot easier to learn and to teach to others. I can task a junior developer with a new feature in Vue, and generally speaking, the biggest changes are to simply break large components up into smaller ones. Meanwhile, I've inherited several React apps developed by shops that focus on React, and they all have weird race conditions due to 'hooks', and all sorts of code that breaks web standard.
I know a lot of people out there are very productive with React, but in my experience, the whole process is much more enjoyable when working with Vue. Neither Vue nor React are the only solutions out there, and it's important to not be too dogmatic about which tools people choose to work in.
Basically, they now (as of Angular 12) force you to build a difference version of your app for each language you support, and either serve them up at different URLs or use cookies to serve up the right version to each user. The technical reasons make sense...your translations occur at build-time, rather than at run-time, but it's a pretty drastic change that occurred out of nowhere.
Not a fan.
If you stick to modern versions and frameworks, it's a much different experience from PHP 8 years ago.
I use the "no container" default for work stuff, which means everything just works normally. Anything that isn't a tool for work, that gets a container.