by tylerchr on 9/24/22, 3:04 AM with 245 comments
by mwcampbell on 9/24/22, 6:50 AM
> As someone who took a classical engineering education, which included not just a broad scientific and mathematical basis, but crucially also the necessary engineering ethos, this is just alien to me. Call me cynical all you want, but it matches my experience. Coming after the generation that birthed Git and BitTorrent, and which killed IE with Firefox and Konqueror/WebKit, it just seems ridiculous.
> Fuck, most zoomers don't even know how to dance. I don't mean that they are bad at dancing, I mean they literally won't try, and just stand around awkwardly.
> Just know: nobody else is going to do it for you. So what are you waiting for?
It seems like ranting about how the older generations were better, and conversely the younger generation is decadent, is as old as history itself. Anybody know why this is the case? Is it that our overall character has really been heading downhill for all of history? Or is it something else, like how we generally remember the best of the past but mostly notice the worst or merely average in the present?
by hantusk on 9/24/22, 12:35 PM
Point 1: React solved all the right things, but its current trajectory, does not prioritize developing the fundamental tooling we need. React does not allow us to build a new Figma (consistent undo/redo in collaborative settings, immediate low-latency mutation of app state to reflect user changes and building fundamentals to SaaS interoperability)
Point 2: People are overwhelmed by the work, and too timid to target the fundamental architecture we need to solve these things. We're just going with the flow.
He is leading https://usegpu.live/ to build the fundamentals right, an encourage people to either:
- help out there, if it fits your use case, or
- start working on targeting these fundamentals, where most needed for your own use cases, don't just go with the flow.
by genezeta on 9/24/22, 9:02 AM
After going through the first two thirds of the article with mostly uninteresting "I'm old; I know better" detours, the author seems to sort of relate React to "reactive", and goes on yet another detour on unrelated architecture. So, we're now reaching the end of the article and the only conclusion we get is... hey, stuff is hard, you need to do the work, you can't avoid putting in effort. And... that's it. That's all there is to the article. Eh.
by fifticon on 9/24/22, 10:09 AM
I particularly lament that scroll bars have become a lost art. We have gone from scroll bars working perfectly in windows 3.1, to .. whatever passes for a scrollbar these days.
Often they are even hidden, so you have no idea how big the document is,or where you are in it. But it sure does look minimal and slick, until you have to actually use the thing. Many established keyboard shortcuts are going missing,but that is OK, since modern people dont like keyboards.
My favorite is when installing current windows 10, when you select language and country. You get a list that displays .. 4 items at a time, from hundreds of choices. Unlike earlier versions, you can no longer press a key to jump to a letter. You must page through the whole list. Sorry if I made more millenials cry.
by chris_armstrong on 9/24/22, 6:20 AM
Like linking reactive programming to “reactive” UIs, when really they mean UIs that are forgiving to their users instead of breaking down.
Or how by coding on the web we’ve lost the immediacy of a UI that runs on our desktop, and the primitives (like undo/redo stacks) that make desktop user interfaces friendlier, at least without having to build them ourselves.
And that new UI frameworks show up claiming to solve the problems that React creates with complexity, by forgoing the functionality that React provides that they pretend is unimportant by hiding behind toy examples.
There’s actually not much in this article that doesn’t resonate with a jaded millenial like myself who knows their computer history, but could have been expressed more cohesively.
by AaronFriel on 9/24/22, 5:08 AM
Whenever you build a tiny language for the purpose of templating, it's worth asking yourself if it's really worth it to have to reinvent variables, loops, branches, scoping, expressions, and functions... Poorly.
> Many competing frameworks acted like this wasn't so, and stuck to the old practice of using templates. They missed the obvious lesson here: every templating language inevitably turns into a very poor programming language over time. It will grow to add conditionals, loops, scopes, macros, and other things that are much nicer in actual code. A templating language is mainly an inner platform effect. It targets a weird imagined archetype of someone who isn't allergic to code, but somehow isn't smart enough to work in a genuine programming language. In my experience, this archetype doesn't actually exist. Designers don't want to code at all, while coders want native expressiveness. It's just that simple.
by crooked-v on 9/24/22, 4:13 AM
Also, the author makes repeated digs at React 18's concurrent mode work while at the same time complaining about the kind of stuff concurrent mode is supposed to fix (for example, React updates not happening fast enough to keep up with mouse dragging).
by TN1ck on 9/24/22, 8:20 AM
Though not a fan of some rants and the bashing on Zoomers, give them a chance to build the next iteration of the common tools, the oldest Zoomer is 25 at the moment.
[0]: http://acko.net/files/pres/siggraph-2014-bof/online.html
[1]: https://acko.net/files/gltalks/pixelfactory/online.html#17
by ccorcos on 9/24/22, 5:15 AM
This realization is what initially sold me on React. I just wanted program and build abstractions with an actual programming language!
by Existenceblinks on 9/24/22, 4:37 AM
FFS. The context is the web, nobody solves graphic problem like gaming for you, or need to. At this point it doesn't matter because HTML/DOM stuff is not going to suffice what you are talking about either.
I honestly think after reading 50% of the article is all about bragging knowing history. I'm not old but I was there too. WIN32, MFC, QT, 8086 assembly whatever. I got a god damn computer engineering degree too but doesn't make me smarter, having better vision, knowing solution better than random ppl on the internet.
I'm not sure what's the point of React here nor "Saving React". Why it needs to be saved in which sense.
Do you mean, saving the web from React?
by foobarbecue on 9/24/22, 11:40 AM
> A templating language ... targets a weird imagined archetype of someone who isn't allergic to code, but somehow isn't smart enough to work in a genuine programming language. In my experience, this archetype doesn't actually exist.
In my day job, I write "sequences" to command a spacecraft, in a neutered "sequencing language" with conditionals but no looping. Several people on our team who are great at writing sequences for the spacecraft feel they "can't code" and don't learn other languages. I had assumed the deal with templating languages was similar and this type of people were the target users.
by absolutelynobo on 9/24/22, 4:43 AM
by makeitdouble on 9/24/22, 3:13 PM
This is a small part of the rant, but he is fundamentally mistaken about what backends are. The real life equivalents are not bridges, but kitchens or back-offices: a place where you make the sausage so that the customer can have a delightful experience without the gory business part in sight.
It’s not disconnected from end-users, quite he opposite, as it’s suppose to realize the core value of the product.
I don’t agree with a lot of other parts of the rant either, but the global message of “react needs to evolve in a different direction” is I think interesting.
by agumonkey on 9/24/22, 10:45 AM
It always pains me to remember a p2 cpu could do realtime nurbs procedural animation (very complex) and yet we still have manual state machines for simpler tasks like documents / filesystems etc
This article is right that there's a lot to gain in terms of ergonomics by finding leaner ways. I also think the web stack and dev culture is ready to respond well to this idea.
by torginus on 9/24/22, 6:11 AM
Strange sentiment. Isn't React templating as well? Besides one of the most famous use of templates is macros (in C as well as other languages). Would people who generate code be allergic to coding?
by qprofyeh on 9/24/22, 8:32 AM
by LAC-Tech on 9/24/22, 8:54 AM
I still think plain old CSS - separate from any JS or HTML or JS that generates HTML - is the way to go.
Just so much easier and less brittle. I get that CSS being too hard for binary tree inverting geniuses to learn is now widely accepted folk wisdom, but it's really not true.
by stasm on 9/24/22, 6:52 AM
How does macOS achieve its reactivity? Is it two-way bindings? Events/messages? Immediate mode re-renders?
by personjerry on 9/24/22, 5:00 AM
by bdcravens on 9/24/22, 5:58 AM
Ended up disabling Javascript on the site to make it readable (ironic I know)
by encryptluks2 on 9/24/22, 5:43 AM
Website proceeds to slowly load and runs like crap.
by DonHopkins on 9/24/22, 11:08 AM
Also from 6502 to 65C03 to 65C816 to 68k to PowerPC... But Apple ][ users were painfully aware of the 68k transition. ;)
by mkl95 on 9/24/22, 7:50 AM
Well I closed that tab.
by bagels on 9/24/22, 4:01 AM
Anyone know what this means?
by Aeolun on 9/24/22, 8:55 AM
by AtNightWeCode on 9/24/22, 12:11 PM
by makeitdouble on 9/24/22, 3:41 PM
I know Chrome OS is really seen as the way forward for many many people, but what if they are just betting on the trend to last, when it is just the usual cycle of “applets” vs local applications ?
The same way Java was pushed in the browser, to then cement its role in desktop apps (or the Flash -> Air progression), wouldn’t javascript heavy work sites at some point move to a native JS hooked into the system and opening the door to system wide drag and drop, undo etc.
by wildermuthn on 9/27/22, 5:02 AM
He’s not wrong, but I wonder what kind of applications he’s working on that require all three of those characteristics simultaneously. If you only need 2 out of his 3 data requirements, then React + Apollo can handle it just fine in experienced hands.
For apps that truly do need all 3 capabilities, the problem isn’t React per-se. The problem is that such apps are just complex by their very nature — even by reducing accidental complexity to zero, you are still stuck with a huge amount of essential complexity. That’s just the nature of the beast.
Although I have long since moved on from Clojure since Rich Hickey made it clear Clojure was not about me but about him and his consulting business, you really need a powerful language like Clojure to do something as tricky as the author wants poor little JS to do. Someone one described JS as a cute dog with three legs — you feel for it, and take care of it, but you know it really isn’t capable of too much. A hard problem needs a powerful tool, and nothing written in JS (kinda-typed or not) is going to get the job done.
by anthk on 9/24/22, 11:21 AM
And, well, Kopete was pretty much the "Adium" for Linux/BSD, and KDE3.5 (once you disabled Artsd and enabled DMIX on the Penguin) it was a beast.
by wheelerof4te on 9/24/22, 9:20 AM
If I learn some fancy framework today, I expect to use it for years to come else my knowledge and time is wasted.
by 199X on 9/24/22, 4:47 AM
by amelius on 9/24/22, 1:23 PM
by AtNightWeCode on 9/24/22, 11:42 AM
by Fervicus on 9/24/22, 7:59 AM
by llIIllIIllIIl on 9/24/22, 4:47 AM
by arminluschin on 9/24/22, 11:59 AM
by EugeneOZ on 9/24/22, 5:27 AM
I also remember something, and you forgot to mention it: other frameworks were honestly saying that they took some ideas from React (or improved their solutions being inspired by React’s ideas).
I don't think it was a good idea to use such a hostile style of writing - it is ok for web frameworks to evolve. It is more than ok to share ideas. Every time I see that some new framework took some idea of React (or Ember, or Angular, or PHP) - I see the “credits”, the authors are not trying to hide it.
Some people are criticizing some frameworks - it is ok, no need to start holy wars because of that. Valid criticism will help, pointless toxicity will just shade away.
by nathias on 9/24/22, 10:07 AM
by akdor1154 on 9/24/22, 4:30 AM
by pkrumins on 9/24/22, 7:21 AM
by DonHopkins on 9/24/22, 10:39 AM
>Menus let you cross over empty space and other menu items, instead of strictly enforcing hover rectangles.
I know the guy, Frank Leahy, who implemented that feature invented by Bruce "Tog" Tognazzini.
When he was at Apple, he rewrote the Menu Manager for Mac SE and Mac II.
We were working together on a project at Current TV, and reminiscing about how great the original Apple Human Interface guidelines were, and how Apple had totally lost their original devotion to excellent user interface design, and I mentioned how the original edition of the Apple HIG book I had actually illustrated, documented, and justified that subtle feature.
Frank proudly told me he was the one who implemented it for the Menu Manager, and that he was touched that somebody actually noticed and appreciated it as much as I did.
https://news.ycombinator.com/item?id=17404401
https://bjk5.com/post/44698559168/breaking-down-amazons-mega...
>Breaking down Amazon’s mega dropdown [...]
>DonHopkins on June 26, 2018 [–]
>The comments are actually great -- even Tog weighs in! It also mentions Frank Lehey, who rewrote the Menu Manager for Mac SE and Mac II.
>Jake Smith • 5 years ago This was first implemented by Apple's HID team back in the 80s, specifically Bruce Tognazzini, I believe.
>Bruce "Tog" Tognazzini Jake Smith • 5 years ago Yes, I did invent it back in 1986 and it is firmly in the public domain. From what I remember, it was Jim Batson who worked out the math and coded it for the Mac OS. The OS X team later failed to copy the algorithm, so I am happy to see that amazon has resurrected it.
>Josh Davenport Jake Smith • 5 years ago I think it was yes. It looks like it was originally implemented by NeXT and then removed by Apple when they bought NeXT. Tog himself talks about what happened here: https://www.asktog.com/columns/022DesignedToGiveFitts.html in the answer to question 6 - "When I specified the Mac hierarchical menu algorthm in the mid-'80s, I called for a buffer zone shaped like a <, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu...........Sadly, the NeXT folks, when coming to Apple, copied Windows, rather than the Mac"
>markr_7 • 5 years ago Can't comment on the HID team, Bruce, or possibly the many times it was even implemented at Apple, but as a young developer at Apple in the 80s, I remember stopping by Frank Leahy's office as he was tweaking his code to get menus to "work right." I've often recalled the experience because of the time he was spending to get it right, and how the behavior wasn't simple once you started really trying to meet a users expectations. If I remember right it wasn't just the direction, but also time and therefore velocity. For example, you wouldn't want to stick with the wrong menu if the user wasn't really moving with purpose in the direction of the sub-menu.
by gardenhedge on 9/24/22, 1:19 PM
by impetus1 on 9/24/22, 6:04 AM
by faangiq on 9/24/22, 7:57 PM
by DonHopkins on 9/24/22, 10:13 AM
This is exactly what I was getting at when I wrote this recent post about Smarty (in response to the following parent comment proposing building a crippled scripting system for designers), to which somebody insightfully commented "Someone doesn’t like Smarty…"
https://news.ycombinator.com/item?id=32886317
parent> Even in game development, it often turns out to be a huge mess that coders have to go and sort out after the fact, it's almost inevitable if it's general purpose enough. If you do decide to build a scripting system for designers, I would recommend being very conservative with features and thinking twice before adding any new feature.
https://news.ycombinator.com/item?id=32886424
>DonHopkins 5 days ago | prev [–]
>Just hire competent and trustworthy designers, instead of purposefully crippling the tools you spend so much time developing. The best designers can also code, and if you design a system that discourages instead of encourages designers from coding, you're wasting the potential of those precious coder/designers, and wasting the opportunity to train your best designers to code too.
>It's not as if Rock Star can't find anybody qualified who wants to work for them, or any designers who are willing to learn to code in a powerful visual scripting language.
>This attitude causes disasters like PHP's "Smarty" templating language.
>PHP was already a templating language, but somebody got it in their head that there should be an iron-clad separation between designers and programmers, and that PHP gave designers too much power and confused them, and that their incompetent untrustworthy designers who refused to learn anything about programming deserved something even "simpler" than PHP, so they came up with Smarty.
>Then over time the realized that their designers were powerless, so their programmers would have to learn TWO languages so they could wade into the Smarty templates to make them actually work with all the extra code they had to write because Smarty was so crippled, so they nickle-and-dimed more and more incoherent programming language elements into Smarty, making it EVEN HARDER to use and more complicated and less consistent than PHP, yet nowhere near as powerful.
https://news.ycombinator.com/item?id=20736574
DonHopkins on Aug 19, 2019 | parent | context | favorite | on: YAML: Probably not so great after all
One of the most ridiculous examples of this was the Smarty templating language for PHP.
Somebody got the silly idea in their head of implementing a templating language in PHP, even though PHP is ALREADY a templating language. So they took out all the useful features of PHP, then stuck a few of them back in with even goofier inconsistent hard-to-learn syntax, in a way that required a code generation step, and made templates absolutely impossible to debug.
So in the end your template programmers need to know something just as difficult as PHP itself, yet even more esoteric and less well documented, and it doesn't even end up saving PHP programmers any time, either.
https://web.archive.org/web/20100226023855/http://lutt.se/bl...
>Bad things you accomplish when using Smarty:
>Adding a second language to program in, and increasing the complexity. And the language is not well spread at all, allthough it is’nt hard to learn.
>Not really making the code more readable for the designer.
>You include a lot of code which, in my eyes, is just overkill (more code to parse means slower sites).
https://web.archive.org/web/20090227001433/http://www.rantin...
>Most people would argue, that Smarty is a good solution for templating. I really can’t see any valid reasons, that that is so. Specially since “Templating” and “Language” should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is “better for designers, since they don’t need to learn PHP!”. Wait. What? You’re not learning one programming language, but you’re learning some other? What’s the point in that, anyway? Do us all a favour, and just think the next time you issue that statement, okay?
http://www.ianbicking.org/php-ghetto.html
>I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.
by rco8786 on 9/24/22, 11:05 AM
by pier25 on 9/24/22, 1:58 PM
One thing I do agree is the rant at the end about zoomers. We see stuff like tailwind popping up which really reflects the zoomer ethos of not wanting to learn fundamental stuff like CSS. "It's so easy to get started! Why would I learn anything else?"
I think gen Xers and late boomers will be the most tech developped generations because we had to use computers that were hard to use.
by pts_ on 9/24/22, 5:44 AM