HN fails to see the intersectionality between corpo power complex politics and marshalling LUTs in firmware space. Shame, but that's life. Rob's point is bang on albeit from a technical stance. This is also ultimately why Rob failed, but with a deep groaning sigh and not a bequeathed resignation (a true nerd is at the end of the day only known by their yawp). Power junkies will try to convince you otherwise because they benefit from it. But you have to live to believe it. The life of a kernel driver maintainer of something that a large corpo entity is financially vested in is one of a diplomat saint. Newly minted VP wants to leave a mark and be goody two shoes. Good luck. The news you hear on the internet are superficial because the map is not the territory.
I’ve known a couple of people to write in this style and I still like it! Antonio had a bit of this style in ~2009, Ribbon Farm’s contributors have been throwing stuff like this off for at least a decade now, and Nikhil Suresh (The Rightful Emperor of Mecatol Rex, natch) is maybe the most anti-biotic resistant evolved form of SARS-COV-FSCK-TEH-MAN to emerge recently.
Of course it could be a modern GPT with a context longer than my dick stuffed more full of better men than my ex-wife, so maybe I’m taking to a bot, but if it gets me a Jumbotron with Ana de Armas asking if I like real girls I’m still happy to talk to a machine.
I read through this to hopefully save all of you the clickbait and mid-way through nonsensical philosophical diatribe. It's a bit ranty and devoid of technically-caloric content.
The author is advocating for use of plain HTML/SSR patterns and avoiding SPAs and complicated frameworks/libraries ala Angular/React/etc. It's an old thought that lines up with the "you don't need JS" crowd.
Oh, and the author would like to kindly point out that React is legacy now. Because they said so. In case you didn't know.
You can read it that way if you ignore the rest of the article, I guess. They simply are saying many (most?) sites do not need to be SPAs and the baggage that entails with load times and latency. Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience.
In most cases later frameworks are slow and bulky. I certainly hate using sites like X or Target on mobile. Random delayed loading of things, loss of scrolling position when going back, things just not loading the first time it delayed reactions. It sucks.
Nah, the rest of the article is not insightful either.
eg React Native is dismissed in 5 sentences, with no real solution at all given to the basic problem of wanting to have a website and mobile apps without writing your app 3 times. Let alone a website + mobile apps + windows + mac clients. The suggested solutions do not address this need -- eg there's some Apache crap that no one I've heard of uses (it's renamed Adobe Phonegap crap that Adobe bailed on and tossed over to Apache); some random link to a 5 year old google i/o presentation; etc.
As far as I know, there's basically 3 toolkits that offer this: React + derivates; Rails with Hotwire; and Flutter, which means trusting Google (fools only), and which has recently deprioritized desktop... so that's a rock solid foundation to pour millions of dollars of eng time into. And I guess Xamarin, if anyone is using that.
I think sadly to that point there’s no solution given because there isn’t one. And the ones that promise it (RN) still has you doing tons of platform specific code and in some cases supporting even more platforms than just going native.
I've been at orgs that wrote 3x apps and at orgs that shipped via RN. RN was a significantly superior choice ime. While yes, it wasn't 100% write once, it was pretty good and also avoided some of the ugly single-platform-only bugs I experienced at choice one, eg in core data libs (subtly different validations on data), that made the write 3 apps strategy be more like 4x work.
As for the article, honesty probably would have just had the author write something like: "RN: an unfortunate but maybe your best choice in these circumstances" instead of pretending there's serious alternatives eg the Apache garbage dump.
> Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience.
This is how you end up with an amalgam of legacy crap that no one wants to touch. I can’t read guarantee you that outside of big tech and a couple of unicorns started by experienced devs this will NEVER work reliably.
React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have.
The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks.
Before anyone mentions Custom Elements and Web Components, I must say I tried it. Gave it a lot of effort to be a solution but it is not!
"React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have."
"The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks."
Heartily concur. It's a classic of an essay written by one of those tortured souls who cannot understand why everyone so blithely moves past the incisive, obvious, truths they share.
With a topping of how this is all just solved by "giving a toss about the user", followed by a cloying apology for being vulgar
I'm not in web and am amenable to a good web dev hot take but this simply isn't worth the time, it's an array of generic wisdom delivered as if it's specific, written with the effort of someone who is proud of themselves when you disagree.
I mean the graph in the article of Amazon vs Target vs Wayfair is pretty damning. And honestly you don't even need the graph, just go to their sites. Target is dog slow while Amazon loads instantly.
Out of curiosity I checked on iPhone 14/4g and 2018 Intel MBP.
I don't get what the point of these comments is ? If you're using RPI with a 2g connection you'll have a bad experience shopping at the site ? And somehow that's supposed to factor in to my tech stack decisions ?
But is the average Target shopper on a cheap Android phone accessing over non-broadband? Wayfair?
It's a fair point to note devs and users might have different devices, but in some cases they don't and the decision to use React might be well-founded with that fact.
Do you not care about most of your potential customers, or do you only cater to high net worth people? If so, then sure, substandard devices and connections can be ignored. If you’re Target, on the other hand, you probably shouldn’t ignore them.
I find it extremely odd that this was even a question on this site. Do you think the problem you’re solving should impact your tech stack at all, or is your tech stack more important than the problem?
You're making the same mistake as the author. I get unnecessarily aggro too, but a plain reading of their comment isn't "they only cater to high net worth people" or they're advocating for such. Its "hey we're talking about 3G connections at this point, which are mostly shut down, and we don't cover developing markets"
Note most of this is nonsensical too.
His primary thing is "you don't need client side code because JS = (HTML + CSS) * x, where X >= 1"
We can start sneering about not caring about users there, too, having a one time client side download of that magnitude can certainly be much better on the poors than 10 page loads with SSR.
I keep hearing the "SPA is actually lightweight" argument but it's never materialized for me, the fastest sites are SSRs that are mostly static. The saving from HTML vs JSON just isn't that much over the wire and mobile CPUs and memory are a bottleneck.
I have a newer iPhone and Safari is still full-refreshing pages constantly due to memory.
With utmost respect, that's not what I'm saying :)
I hold no hot take position on anything web dev, or any firm declarative position.
What I'm trying to get at is, indicia of an article being half-baked includes things like asserting all that's required to agree is to care about the user.
This feels good to say, but doesn't say anything, other than there's been at least some short-circuiting of thought. We can come up with many trivial cases where "caring about users" involves requiring client-side logic during rendering.
o7 thanks, people like this who do not work in contexts with problems that React solves yet insist React is not solving problems are profoundly boring.
I spent a lot of time working on react applications of one kind or another and I think most businesses don’t have “problems that React solves” for their frontends. Somewhere that’s actually an application might, but most line of business applications would be better as something like Rails views rather than React
Because, for most business applications I've worked on, React just complicates the frontend code compared to serving up simple HTML views and for no real benefit aside from "using React"
Really? HTMX for me brings spaghetti code on the server side. Fine for small projects but not so for large ones. I would prefer the clear separation between frontend and backend beyond small scale projects.
I love the narrative of a Chinese manufacturer selling electronics to the West only to one day shut everything off for no reason at all than to fuck with people and disappear and for people to find out the supposedly registered company never existed. It's like a trashy, second-rate William Gibson knock off novel but there's something awfully amusing about it.
Frankly it doesn’t even require (special) maliciousness (per-se) - spinning up random ‘brands’ to sell to rubes on Amazon while obfuscating beneficial owners is essentially standard operating procedure.
The only surprising thing here is they took an action to brick something instead of just abandoning it.
>The only surprising thing here is they took an action to brick something instead of just abandoning it.
You're right, but I wouldn't say surprising. I do wonder what would happen if the units just stopped working outright one day and they're all intended to be gridded and nothing works properly anymore and the distributors are stumped and can't get ahold of anyone.
Fair point - it would be trivial frankly to embed a ‘bug’ which causes them to all brick at some arbitrary point in the future too. Considering the level the firmware works at, probably even catch on fire.
Has PC gaming fallen in any meaningful sense? And what is 'trad' PC gaming?
It seems stronger than ever to me, and I started in 1993. Consoles are becoming more PC like. PCs can now be more console like, if one so desires. In many ways we get the best of all worlds.
Depends on what you value. Quake III, UT, Counter Strike all from an era where modding, map making, and self hosting were the norm. I used to run my own server with a collection of maps and mods that I liked in Unreal Tournament 99. I even wrote a few myself. It's what got me into programming.
Halo is often seen as the beginning of the end for these types of games. I'm just happy I was born early enough to have caught this previous era, if Halo had been the game of my youth with no options for tinkering or self expression my life might look a lot different.
Thanks for elaborating. Still, even that strikes me as a narrow recollection.
Early Id games had only the smallest modding capacity built-in (loading mostly), with the community stepping up with original tooling. There were also fewer games to play, which concentrated community efforts. Games were simpler too, which also made modding easier.
It was also daunting to make ones own game from scratch. Around 2000 friends and I failed repeatedly going down that path. (While the mods we made were mostly released.) Today it's so much easier to make games and even mod those based on common engines.
Dedicated servers are a loss yet they often had rampant cheating. They were also painful to setup and maintain compared to private party systems from the game creators. Hopefully with some tweaks to the law, they can be incentivized to open source their servers or at least keep them alive.
'trad' in this sense mostly being the era of dedicated servers and the countless mods and whatnot that these games are known for. Some of the better bots during these years were done by modders who had access to do these things - Q3 included.
This is a fairly high level overview of linkers, most of which you can find for yourself if you look up `ld` documentation [0] (mentioned in the article) and walk through it step by step in a tutorial fashion.
A more comprehensive look would be, at the very least one would hope, to have a reference manual of your favorite MCU and write the corresponding linker script for the memory sections it expects and provide stubs/thunks and other things of that nature. It's the praxis and application that brings the scary things out.
[0] https://sourceware.org/binutils/docs/ld.pdf (nb - after you've gone through the page count of some IC and MCU datasheets, 164 pages of ld will seem like a walk in the park)
I don't really find this argument convincing. You don't need to know how to build a car from first principles to drive one. If you're into it, sure, it can be fun and teach you plenty about its failure modes, the scary things as you put it, but most people really don't need nor want to go into that detail.
This is nowhere close, nowhere near close, not even within the same 100 mile radius close, of first principles.
This is literally starting from `man ld` and going one step further. The manual literally starts with a `man ld` printout and then goes to describe it from concepts onwards.
If you want first principles we can try to maybe start the discussion at maxwell's equations and take it a handful of hundred steps from there until we arrive at how logic gates, diodes and transistors work.
Except in reality 99% of people will just take the example (or auto-generated) linker scripts from the MCU manufacturer without understanding a thing about them and call it a day.
This worked fine for me for a little while, until I needed to do things that the manufacturer's example script didn't do, such as place certain globals into specific sections of memory. I had to piece the syntax of the linker file together myself, which wasn't too difficult, but a straightforward introduction to the file format would have been appreciated.
Implying that you can just read that documentation and "walk through it in a tutorial fashion" is a peak HN comment probably only rivaled by the famous Dropbox comment.
Not everyone is an expert in these things, and I'd appreciate if there were more articles like this.
This is what a lot of us have had to do early on because we had no other resources than first-hand manuals (mostly only printed; Hackers scene with books was painfully true), and maybe someone on a BBS or Usenet (later IRC) who could answer a question or two if they felt generous enough with their time to not heckle us for being dumb. If you're looking into `ld`, you've crossed a point of no return.
And the `ld` manual is great and there is nothing wrong with it.
The dropbox comment is people who are completely misguided as to the market value of a product that solves a real pain point for users and the recommended alternatives of using rsync was comically out of touch with the technical acumen of an everyday person. (see also the great "Less space than a nomad. Lame." comment from that other site)
Using `ld` is on the opposite swing of that, and that discussion is very much res de facto technical one with no punches held back. This is what the "Hacker" in "Hacker News" actually stands for.
