The big difference is that while the PHP major upgrades - although had breaking changes - provided a forward-compatible way for you to run older version code on a newer version PHP (see WordPress for PHP 5 running fine on PHP 8), Python did not offer such a thing; code was either exclusively for Python 2 or for Python 3, making upgrade paths very difficult.
I remember getting that error in the past, and at the time googling for that token gave few results, so it was a slightly bigger deal than you would think.
99% of the time the cause was: you are on PHP 5.2, but we're trying to use PHP 5.3 late static binding ( `static::someMethod()` ).
Every time I hear any news about routing in a React framework I always get disappointed that the news isn't that they're introducing type-safe (TypeScript) routes to enable type-safe linking.
I'm curious about what you mean. There's no way to embed type information into a URL - every GET parameter is a string. Are you suggesting that visiting a link like /123 would go to the 'string: "123"' route, while clicking a <Link to={123}> would route you to 'number: "123"'? That would make deep linking in an app really hard to manage. I'm struggling to understand why you'd want to overload routes like that.
edit: I did implement this a while back but found it gave me only so much additional value. Though I can imagine that large applications with dozens of developers might indeed benefit from type-safe routes to avoid dead links.
CRA isn’t really an alternative because it doesn’t have a server-side component. It’s also a lot less opinionated around things like routing. I’d say Remix is probably the main competitor to Next, that’s built around React Router and already has support for nested routes/layouts, and has opinionated support for the server-side too.
I'm implying that if you "don't need Next.js", because it's too heavy-weight (because e.g. you already have a dedicated team working on the back end API using a different language), then too bad: there's no lighter-weight alternative that is viable.
Nextjs has useful defaults and enough basic elements for front-end.
create-react-app is just a bunch of oppinions on how to config your app that dont really add much productivity if you are already familiar with webpack. Depending on the need I'd either go with react and my webpack config copied from last project or nextjs. Don't see the point of cra
Nearly all front end metaframeworks/starters are like this, which is why I've given up on trying to run them in Docker, because it's just over-complicating the deploy process with no real benefit due to what you mentioned, and I'd rather just use simpler tools like Netlify.
Pretty much. I've been able to use some regex-replacements on the build output in the past with varying luck. But it definitely feels like a hack and can break in weird ways. Another option is building all environments into a single container image and then selecting the right build runtime using an environment variable. This makes the build costlier, even if you can build in parallell, and a bigger image takes longer to distribute into your environment.
At that point dedicated frontend hosting infrastructures like Netlify, Vercel, Cloudflare Pages and others seems like a better choice.
One of the reasons I haven't moved over to NeoVim is because they removed this feature, because supposedly it's not perfect or something. So sure, the NSA may be able to still be able to extract my passwords if they arrest me and take my computer, but the point is that random people won't be able to.
Although as a male I highly support that sex work be legal, and acknowledge it as legitimate work, I do not tend to honestly respect this type of work (besides the courage to do it and such). I find it quite unfair be able to make so much money for relatively low effort (at least it feels that way despite the downsides/dangers).
But I must say that this escort is super smart and has a really good sense of business. This article also gave me some newfound respect for escorts for the fact that although on the surface they seem to mostly just use their bodies, they do put in a lot of effort on the business and strategy side which people don't talk about.
I read the entire article.
By making a lot of relatively low effort I mean selling something for a lot that's not a expensive items or valueable experienced labor.
And like I said, before I thought this was all low effort work, and through this article I got to see the high effort business side.
> I find it quite unfair be able to make so much money for relatively low effort
I hope you hate capitalism then. It's all about supply and demand. As a gay man with some friends who escort, their rates are much lower, both for obvious reasons (it is ridiculously easy for most gay men to find other men to have sex with) and less obvious ones (IMO there is much less of a stigma among gay men for escorting, and at least friends I knew who did it expressed little shame at doing it).
It is absolutely supply and demand. I meant girl escorts when I wrote what I wrote. I find it unfair that it you're born a girl and are pretty, you have this option.
I don't see how the "men" part is relevant of what you are saying. The "rich" part is a good point: that's certainly more unfair.
I'm thinking that if men and women of equally poor background, women have this escort option that men don't (obviously they do, but it pays far less good on average than women).
Just that men earn more money and have more wealth than women when looking at population averages. In many cultures women are expected to marry and look after the kids while the men work, and that expectation carries over into education opportunities, parental support, hiring decisions and so on.
Although Livewire allows you to do that, and shows counters in its examples, for such things that shouldn't require communication with the backend (e.g. saving, or grabbing data from the DB), you are rather meant to use something like Alpine or petite-vue for lightweight JS manipulation than to make use of Livewire's feature for it to waste a roundabout request to the backend.
If you are reaching for Alpine or petite-vue I would consider jquery. The reason why people moved on from it "heavy dom changes" = "slow", "too messy in heavy js pages" is the reason to use it here. Lightweight pages + jquery = fast development, quick to load/render and tidy looking code.
I think the initial marketing/examples for Phoenix Liveview and the like really did a disservice here; when you ask the team always says that the live part should really just be replacing what would have been xhr requests in an SPA - where you need server-side data or functionality. For local interactivity they recommend Alpine but too many people have already seen the counters example and drawn their own conclusions (and even built entire applications this way).
reply