Honestly I think React DX kinda sucks, at least in some areas. Performance is one of the worst (`useMemo` and `componentShouldUpdate` are way to easy to ignore, constant re-renders are the norm and writing performant React code requires conscious effort to avoid footguns) but it's also just less self-explanatory than the alternatives I've tried.
I started doing web dev before reactivity frameworks were a thing, and I found Vue to be the most intuitive of the frameworks available when I first needed reactivity. To me, Vue feels like HTML with superpowers while React feels like a whole new way of thinking about webapps. I'm honestly a bit surprised that the article doesn't mention Vue, since Vue is (and has been for a while) the most popular "not React or Angular" framework option. Newer versions of Vue even support the "disappearing framework" feature Svelte was built for, which I'm excited to take advantage of when my biggest work project finally moves to Vue 3.
I think you've nailed it. It does come down to user preference.
React _is_ a whole new way of thinking. Back in the days of jQuery it was very painful to stitch together web experience across HTML+CSS+JS. jquery provided much needed DX around utilities to navigate across these pieces. But it was still way too easy to treat HTML like your database and model user-state across a Frankenstein of server, json, html, and javascript.
React was a paradigm shift. "Screw it, everything is javascript." The web depends on js runtime, we know we're going to need it. It starts to makes the best future-forward sense to use the only full programming runtime available. From DX pov this was spectacular to speed up prototyping. And you can finally truly model state purely from data.
What followed was a huge a mess (redux), but I always say, what do we expect? The web is a mess, and it's great because it's useful. Humans are a mess!
---
VUE: similar to angular I just don't align with "super-powered html attributes". It just doesn't make sense as a mental model. Because it's _not_ HTML spec and HTML is not a programming language. The more powerful the framework gets the more we reinvent a pseudo-programming language _through_ HTML. Angular was full-stop a no-go when I first saw it's for-loops in HTML.
Neither react's JSX nor vue's template language are HTML. But rejecting vue's template on grounds that it's not HTML seems odd. React's JSX deviates from HTML in many ways. Like class vs className. XML self-closing vs HTML self-closing. onchange vs oninput. On purely aesthetic grounds, I can't understand how the react idiom of array.map() would ever be preferable to an affordance in the (non-HTML) template language for handling this normal standard thing that always happens.
it's not about feigning html purity it's the opposite. Why pretend we're using HTML when it's not? so with react it becomes a js flavor, jsx, which some people hate but it's very clear that it's a made up language IN real javascript.
edit: the mental model is instant: it's just javascript for reals. do anything you want in javascript using real js primitives. it's not about looking pretty, jsx doesn't. it's about not relearning basic programming primitives in a made up _markup_ language.
my issue with angular is it's neither real html nor any programming language. its made up pseudo-programming language for no other reason than it fools people into thinking "it's just HTML". that's my gripe.
Completely agree with you. Every time I see yet another template language adding some clumsy for-each loop syntax I sigh. Just let us use a normal programming language. As an example I give you every template system ever invented. Devops tooling is full of them.
Over the years, I've seen a few posts like this that seem to take it as a given that a loop in a normal programming language is better than foreach capability in a template language. Certainly enough times to believe that a significant group of people actually believe it's superior.
There's not a difference in capability of expression of the two models. It seems to be a purely aesthetic or comfort difference.
It's because native programming language will defacto allow you to hack it to its natural limit. A tendency most all programmers have given they even get into programming.
For example with any iterator/loop you may want to filter, or find, or transform. in ruby you have the entire Enumerable API to dig into or Array prototype for js.
a templating language would have to reimplement functionality one by one in an allow list.
it's just fatigue at that point, yet another API i've got to mentally track.
edit: of course if you export the view data "clean" before hand it compels you to not have intense logic in the view. I get that but after a decade+ in product, views are never pure, even just ability to highlight the active tab takes conditional and select logic in a loop.
I would rather that all the developers were "encouraged" to do the filtering and sorting in some kind of logic block rather than having an attractive footgun lying around that makes it easy to cram in one more last data adjustment.
JSX also fools people into thinking "it's HTML in javascript". I've heard several co-workers say this. JSX is a made up language as well. It's not javascript. That's why you need a build step to parse the syntax.
Angular and vue's template language are no more made up than JSX is.
It's been interesting seeing several comments like this in the comments, since Laravel's docs may be one of the most highly-praised aspects of the framework. I suspect the divide may be that newer developers get everything they need explained in the docs in clear language, but the more advanced stuff requires some digging.
I use Laravel personally, and I've definitely seen both sides of this myself. For basic "happy-path" API reference, the docs are great. If I really need to understand how the framework is doing something, I pretty much always end up diving into the code. Unfortunately the heavy use of Facades can sometimes make it annoying to find the underlying code.
I disagree, at least in this specific context. With Laravel Cloud you build a standard Laravel application which can be deployed anywhere, then use the service to handle DevOps for you. Because it doesn't include any unique services of its own, you can always decide to hire a DevOps team and run all the required services yourself.
You're totally correct in scenarios where you need to build your project around the service, but this service is specifically a DevOps shortcut with no lock-in.
Should your Fortune 500 company use this? Maybe not. Should a one-man dev shop use this? Quite possibly - you pay for the convenience, but it frees up more time to improve your application.
This is true, if you're billing your hypothesis as a hypothesis. The problem is that prominent Republicans billed their "election was stolen" hypothesis as a fact, claimed to have boatloads of evidence in order to convince the public, and then never published that evidence.
In the aftermath of this clearly deceptive behavior, they've maintained the support of Republican voters who still believe the lie despite none of the evidence ever being released.
It's one thing to claim something is true and that you have evidence, then release the evidence and find out that it's insufficient to win in court. It's another thing entirely to make a claim, say you have overwhelming evidence to support it, and never release any evidence at all. In the former case, maybe you got overzealous or maybe you were dealing with an unsympathetic judge. In the latter, the only rational way to interpret the situation is that you were intentionally misleading your audience.
It's well established that adults who read incorrect information frequently don't find out it was wrong and become more skeptical of the source. Some people operate that way, but it's a small minority unfortunately.
In particular, it's been shown that people with dogmatic beliefs strengthen those beliefs when shown evidence to the contrary rather than questioning them.
Moderated media leans left. At least some of the reason it ends up that way is that many of the people who violate incredibly reasonable rules are conservative. Certain groups of hard-right people will say some incredibly bigoted shit that's absolutely out of line and makes it impossible to have a civilized conversation, then they complain about getting banned and drag a bunch of moderately-more-reasonable people with them when they leave. Once those people leave, normal everyday non-asshole conservatives realize the platform has less conservative content and leave in search of spaces that they feel respect their viewpoints more. In some cases entire topic-groups get banned (/r/the_donald is a good example) for legitimate reasons that frequently involve a small extremely-active group of members, and the rest of the members will also leave the platform because all they see is that a group they were part of got banned.
People who lean to the left tend to believe that it's bad to do some of the things that get you justifiably banned (such as intentionally using language that demeans people based on immutable traits). Because of this, it's much easier for them to avoid being deplatformed.
Assuming that random factors like "it rained" or "voters got in car accidents and couldn't make it to the polls" aren't a significant factor, there's always a 100% probability of one specific candidate winning since everyone has made up their minds before the day of the election. What polls do is not telling you the real-world probability, it's telling you the likelihood of a given outcome given known data.
Polls always need to be skewed in some way to be accurate, since not everybody will vote. You can't just get a random distribution of the population's preference and assume the more-preferred candidate will win. Polls can never be truly accurate because people will lie about which candidate they're voting for and whether they're planning to vote, and sometimes people who genuinely intended to vote never make it to the polls. There are a huge number of variables to consider when trying to predict the outcome of the election, but it's important enough that it's still worth trying.
Serious question - what do you think will happen to AI that currently relies on human reporters if everyone switches to getting their news from AI and the reporters lose their jobs?
Morals aside, AI will run into serious problems in 10-20 years when the world has rearranged itself around AI content. With less non-AI content available and no reliable way to differentiate AI vs non-AI content, there will no longer be a dataset to train against.
Individual humans summarizing the news can reduce revenue for news organizations slightly, but AI summarizing every news article is a problem on a whole different scale. Basically the same as the difference between getting a mosquito bite and being stabbed in your carotid artery - both are just blood loss, but one is a minor annoyance and the other is fatal.
This no reporter argument is so false but gets repeated often. If I only read internet articles from internet media companies you might have a little bit of a point, but actual newspapers have actual journalists. Some might be good and some might be bad, but they do employ people that do more than build an article around a tweet.
> Serious question - what do you think will happen to AI that currently relies on human reporters if everyone switches to getting their news from AI and the reporters lose their jobs?
It will evolve towards consuming more raw data and more information that people self publish to produce news. Newslike narration constructed on actual factual information is so bland and repeatable that there is no need for more training material. News is so uncreative and predictable that I can pick up a newspaper in language I don't know and still guess with high probability what most articles are about from photos, common names and few words of that language that I do know and general tone.
> Individual humans summarizing the news can reduce revenue for news organizations slightly,
There are so many humans doing that that the effect is not negligible. I skip reading all paywalled articles and read just their comments instead.
> Serious question - what do you think will happen to AI that currently relies on human reporters if everyone switches to getting their news from AI and the reporters lose their jobs?
Then the AI will go to the primary sources that the human journalist currently go to.
Will it be flawed? Yes.
Are humans already? Also yes.
Is there a huge risk that "the algorithm" will be politically biased? Totally.
Can you name one press organisation, larger than a local one-city-only paper, that hasn't been accused of that?
I'll confess - I have a project that uses Heroku's managed Postgres and my preferred upgrade method is to set the maintenance window to the middle of the night, create a backup, and be awake at 1am to make sure that nothing is broken after they force the upgrade. Their auto-upgrade process hasn't failed me so far, but there's no way to manually trigger it.
Proposal: Apply a ceiling function to your pizza-counting algorithm and always leave the last slice in the freezer. Then simply throw out that slice when you want a new pizza!
I started doing web dev before reactivity frameworks were a thing, and I found Vue to be the most intuitive of the frameworks available when I first needed reactivity. To me, Vue feels like HTML with superpowers while React feels like a whole new way of thinking about webapps. I'm honestly a bit surprised that the article doesn't mention Vue, since Vue is (and has been for a while) the most popular "not React or Angular" framework option. Newer versions of Vue even support the "disappearing framework" feature Svelte was built for, which I'm excited to take advantage of when my biggest work project finally moves to Vue 3.