I have never had to use them directly but the use-now-pay-later model feels scary to me for the same reason. Maybe they allow setting the upper cap to the monthly bill (crossing which they don't serve you until you intervene) but I have never heard of it. On the other hand there are many stories extremely ballooned bills for some unforeseen reasons.
Facebook is already flooded with very strange (to put it kindly) AI boomer engagement bait AI images. I cannot help but think about how much worse the problem could get with AI generated videos. But they are not cheap to make right now.
Genuine question: Judging from the comments, seems like people like this approach. So why is the general trend more towards approaches that use javascript (sometimes unnecessarily) and frameworks like React?
As an end user, I really like the style of applications that GOV.UK write and endorses - lightweight, clean layouts, accessible, and generally work with minimal (or no) JavaScript. And I dislike most SPAs, because they usually end up breaking lots of expected browser functionally, are useless without JavaScript, and often load all kinds of heavy dependencies from various third party sites.
But what users like and what developers like (and can quickly develop) are often very different things.
Ambivalence is a weird thing. People often speak in two minds. We
hate AI, but we love AI. I love ice-cream and crisps. but I tell my
kid not to eat that. As George Carlin said, when you're driving
everybody going 5 mph slower than you is an idiot, and everybody going
5 mph faster is a maniac.
Here on HN we often see the schism between speaking "as a developer"
and "as a user".
As a user I hate a lot of the shit we gleefully enthuse about here.
As a coder it's super cool.
Nobody got fired for building an app in React? When something is an accepted as an industry standard, it's safe to make a decision that goes with the flow. Also, nobody is doing devrel for html/css/vanilla js - if you search how to do things you will find nearly only exclusively framework related content.
There's no cost to building slow, fragile, and inefficient websites.
When you build programs that run on _your_ computers, you have to pay for that. Or at least have to deal with the finance folks asking why your cloud spend increased 5%.
But if you run your software on other people's devices, like frontend devs do, there's barely any cost to that. Any negative signals need to trickle in through user reports, support tickets, and maybe Twitter posts. There's a ton of selection going on there so you're likely not getting the full picture.
Because the trend is also towards doing more over the web.
The web is replacing traditional thick clients, which also assumed a fairly stable network connection and platform specification.
Government systems need to work with the lowest denominator - even if it's not that common. Tech startups only need 1 client to exist at the start (and can mostly trust that their requirements will become commonplace as they scale).
My gut is that the government wants services that work for 100% of people. In terms of purely costs, people who can't use a site may need to be serviced anyway by more expensive means (e.g., voter registration by mail).
A business probably thinks that it doesn't need 100% accessibility. A nicer site may be thought to get more users/customers, even if the site doesn't work for many (or maybe devs just want to fit in with the other cool devs making cool dev sites)
1. Complexity. Devs like complexity like cats like catnip.
2. Tools. React+JavaScript is the industry monoculture. If they're all you know (and for a significant number of frontend devs this is unfortunately true) then you're invariably going to build something complex because its in the nature of your chosen tools.
3. Career anxiety. Building something simple using simple tools isn't sufficiently hardcore and braggable to get that juicy comp increase at the next performance review, never mind a promotion or hopping to that next job.
a. I once worked on a project where the webapp frontend went through a time-consuming, mid-project framework swapout because the "senior full-stack developer/architect" decided it needed server-side rendering for SEO purposes. Never mind that it was a niche industrial app that required a login to use and simply wasn't visible to search engines.
b. I remember being advised to stay quiet when I asked why a different web developer, upon being asked to build a simple static website, had nevertheless built it in React.
That's one dream. There are advantages to thick clients as well... less network traffic if the device can do processing on site, A much easier to maintain and update distribution model over the traditional desktop experience for what is essentially application software, etc.
UIs in general are pretty hard unless you have a set of primitives that do everything you want. HTML + CSS used to be lacking (and still are in some respects). A thin layer of vanilla js on top of them has a tendency to turn into a mess of spaghetti as more and more features are added. So, you organize it into a framework. But a framework needs to be able to assert control over anything that would affect how it renders, which is pretty much everything a browser might do, leading to an SPA.
I think it’s a nice idea, but given the bean-counting-efficiency-experts that run the company, this will never fly “build for the 90-95%” is what I constantly heard from bosses before I left frontend and went to backend, and eventually leaving the cloud industry all together. I can see it working for government sites though because profit isn’t the sole purpose of the website, it’s more there to serve the public as a whole.
Firstly it's what looks good in demos, both internally to management and when trying to sell things to consumers. Government services have users without a choice and usually that they have to provide it has been decided top down.
Secondly it's less "boring" for developers and arguably less work.
Thirdly you have a large amount of only-frontend (often only-React) devs know who won't think of alternatives.
Because most websites today are more than just informational. Some web apps facilitate complex user interactions which typically require a lot of state which are the raison d'etre of web frameworks.
Because the ux and dx are better once you reach a certain amount of complexity. Companies know what is best for their business.
There were will always be a group of devs that don’t like it because it isn’t the same web as in their heyday, and they all will eagerly pile on anything remotely JS-critical is posted on HN.
There is a selection bias to the comments that does not accurately reflect the industry opinion.
"Companies" don't really know anything. The decisions get made by people, with all the flaws that people have. I have seen many developers make decisions that are detrimental to the company.
I do agree that there is a section of HN that will pile on these kind of topics, and I have flagged dozens of low-effort swiped against JS over the years that add nothing.
But two things can be true at the same time:
1. there is an unpleasant section of HN that will rant about all things JS, and
2. SPAs (or our current approach to them) bring a lot of downsides and are often not worth it.
I agree there are tradeoffs to SPAs, and I shouldn't have implied that companies are a perfect decision-making apparatus.
That said, I think if a certain technology becomes an industry standard, especially one that demonstrates some staying power, as React has, it should not be dismissed out-of-hand, and most of this comments section is doing.
There are probably more companies not using React than are. Words like "industry standard" don't really mean much. Languages like Ruby or Go are widely used and here to stay, yet there are also many people who don't like it – and that's okay.
There's a lot of self-sorting going on here; I stopped doing the frontend thing because I didn't like the way things were going and even tepid critique of this was (and still is) often met with completely out of proportion aggression, vitriol, and insults. I got more hate and vitriol over my "Why I'm using jQuery in 2018" post than the rest of my website combined. It feels like engaging on the Israel/Palestine debate or something.
Of course every community self-sorts to a degree. That's okay. I would never presume to critique React on a React thread. But "frontend" is very broad and also includes non-React.
Your comments here are fine, but at the same time it also strongly suggests that SPAs are the only way to build good frontends and that everyone who disagrees is just some old coot stuck in their ways. Both of which are rather tiring tropes, and especially that second one is pretty dismissive, if not downright insulting.
So I kind of gave up on this years ago. It's easy to reach consensus if you chase away everyone who disagrees.
JS-heavy sites are frustrating to me due to generally worse UX — links can’t be opened in a new tab, because they’re not actually anchor tags. Forms can’t be submitted by the “return” key. Navigation using back/forward buttons is broken. There might be a few companies who get it right, but most don’t.
The OP was asking for an explanation why the preferences of the industry diverge from the preferences of this comment section. The question itself identifies two groups.
The top comment on this page said the frontend community seems like a jobs program. It's interesting that you are only criticizing the view you disagree with as being too divisive.
Because we also have hard data that users absolutely hate a blank or frozen screen and "CONFIRM FORM RESUBMISSION." Users are allowed to hate multiple things at the same time and it's up to the web developers to stack rank those.
> Why is every western government not warning Pakistan, and it's population, that if they continue to elect leaders who run the country into the ground that this will have dire consequences for their longevity and wellbeing?
The current Pakistani administration is a product of an American-backed coup on Imran Khan because he was getting cozy with China.
Considering how Pakistan has been a military dictatorship with a foil of an ostensibly elected government ever since its formation, this is least credible explanation of three situation yet somehow this what you came up with
Foreign interference is only something other countries do to us. We never interfere in their politics. /s
I think you need to look into the CIA playbook. They're doing this actively, have been doing this for decades. Even lots of allied "democratic" countries are effectively just puppet states of the US: yeah people get to elect, but their foreign policy is solidly controlled by the US. They don't have real sovereignty, and without sovereignty they don't have real democracy.
I don't think the service aims to solve the problem of political discussions. It is for the type of person who either gets their political content from somewhere else or someone who is socioeconomically comfortable and perceives political discussions as noise.
It is a tiny tool that pushes people further into echo chambers. Opting out into the “I don’t need to know anything about politics” is itself an echo chamber, usually by well-off people (as you mentioned.)
It would be really great to see people making little tools that go in the opposite direction.
We don't need people to make tools that go in the opposite direction. Politics is everywhere on the internet. No one needs a tool to find political opinions online any more than one needs a tool to find cockroaches in a sewer.
I don't think that's a problem that can be solved with technology. And sometimes people understand others perfectly well, and their choice to avoid those people isn't the result of ignorance or fear.
> first introduced in the paper Large Language Models are Zero-Shot Reasoners in May 2022
What's a zero shot reasoner? I googled it and all the results are this paper itself. There is a wikipedia article on zero shot learning but I cannot recontextualise it to LLMs.
It used to be that you had to give examples of solving similar problems to coax the LLM to solve the problem you wanted it to solve, like:
"""
1 + 1 = 2 |
92 + 41 = 133 |
14 + 6 = 20 |
9 + 2 =
"""
-- that would be an example of 3-shot prompting.
With modern LLMs you still usually get a benefit from N-shot. But you can now do "0-shot" which is "just ask the model the question you want answered".
Simply reading an introductory article on the efficient market hypothesis would be a good starting point here, because both of these are basic principles. Efficiency in this context means how quickly and accurately the market incorporates information into asset prices. A very simple example would be a company giving an earnings call, how quickly and accurately after the results are known does the stock price move to reflect the results. If it happens quickly and accurately, the market is efficient, if it takes a long time or is an overcorrection, the market is inefficient. Now expand this concept to all available information at all times for all assets and you roughly have the efficient market hypothesis. Naturally no one thinks that the market is perfectly efficient at all times, but depending on how clear of a signal there is based on available information, the market can be really darn efficient at times.
except in the case of the efficient market, if somebody manages to find some inefficiency, they can stand to profit off it by arbitraging that inefficiency (until it disappears).
So it's not quite the same as code inefficiency, unless an engineer could reap the reward for the fixing of said inefficiency.
This isn't true. If you manufacture inefficiency yourself, and control it, nobody can exploit it. In fact if they try to, you can exacerbate the inefficiency in the other direction. Try arbitraging against the inefficient pricing of GameStop.
I don't see how you can manufacture and control inefficiencies in the long term so that nobody can exploit them. How can you arbitrarily exacerbate the inefficiencies?
More money has been earned by removing the GameStop inefficiencies than by creating them. GameStop shot up in value driven by WallStreetBets, but those people mostly lost money by creating the inefficiencies.
Introducing them has made people money. Those people will seek to introduce them again under a different ticker.
The main inefficiency in GameStop is creating information and will to buy that runs completely orthogonal to the actual valuation of the stock. Like snake charmers, Roaring Kitty etc use memes and bots online to drum "bagholders" into a fervor, thinking they are righteously sticking it to some nebulous man by buying a stock that is worthless.
Ah, so it is like the "Bug Free Code Hypothesis". If someone is paid to write code, then theoretically that code should be making money for someone, and it should be making them more money if all the bugs were fixed.
Not exactly, but I think that analogies with everyday experiences can help to show how silly some of these hypotheses are when considered in more concrete terms. “People have lots of incentives to eliminate Xs, therefore there won’t be any Xs” is an argument schema for which counterexamples abound.
To be fair, the "Bug Free Code Hypothesis" is kind of true. Because there are lots of incentives to eliminate bugs, people do put a lot of time and effort into doing so – yielding modern miracles such as OS kernels with 30 million lines of code that almost always work as intended.
But while software is bug free to a perhaps surprising extent, it would be foolish to plan a software project on the assumption that there will not be any bugs to fix, or that a small number of bugs cannot have a big impact. Similarly, it seems unwise to assume the efficiency of markets in economic planning (though I don't know to what extent economists actually do this).
I'm wary to using analogies of smaller team dynamics for wider systems. Markets have a disconnected impersonal nature where things have a way of shaking out.
Most of those programming management memes come from big companies with giant teams that don't live or die on output, many of them are shielded from that sort of thing because of cash cows like Microsoft/Google or corporate megadeals like IBM/Oracle. So there's never any shake ups until it's long been obvious to the customers.
I'm not using an analogy of smaller team dynamics. One can talk about software bugs in general and the general incentives to fix them just as one can talk about the economy in general and the general incentives for people to make money.
I'm also not referencing any programming management memes.
I think maybe you're seeing a cynicism in my comment that's not there. I don't think that bugs exists because of dumb managers. I think they exist because it's very difficult to write code without any bugs, even when there are very strong incentives to do so. That's partly just because it's inherently difficult, and partly because there are also other incentives pulling in different directions.
At the core of it, the high valuations were not a product of the potential LLMs had in assisting and enhancing individuals' works, rather because there was a hope that LLMs could replace some varieties of human labourers wholesale, thereby cutting labour costs which are often the highest expenditure of many companies. This has not materialised. I have seen more stories of PR nightmares out of attempting this than those with good endings. But maybe that is because of the sensationalist nature of news media itself.
Either way if it is indeed a bubble that will burst at some point, it doesn't bode well for the tech industry. With the mass layoffs, which are ongoing, seems like there won't be enough jobs for everyone.
reply