> 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?
I recently learned that GitHub has a discussions page which is separate from the issues pages. To pass the time and to give back to the community I try to help people and answer their questions.
It's a bit concerning to me that when I point some people to the right direction by making suggestions, linking to the docs, or linking to a relevant stackoverflow answer, they are unable to formulate an answer for their problem. Sometimes I literally have to create a reproduction repository so that they can see how the answer I gave can solve their problem.
I am not concluding anything here. But this has been my experience so far when engaging the community of an open source frontend framework.
The people who are good won't be using that.
When I was a student working on my thesis I realised I was too advanced to ask questions on stackoverflow and I would not be receiving useful help there. My issues were too uncommon and specific, because the simple ones that stackoverflow is good at solving were not blocking me.
I guess something similar happens there, with the extra thing that very few people know and use discussion pages.
For instance, I've been looking at old Byte Magazine issues on archive.org
Let's take November 1982. Here's an article on building a video digitizer (https://archive.org/details/byte-magazine-1982-11/page/n175/...) complete with circuit diagrams, signal examples, and a control program in 6502 assembly.
Hobbyist magazine. For enthusiasts.
If I had a candidate that did things like that for fun I'd hire them before getting their name.
Dev work has gotten too abstract and covered in bullshit.
Not that 6502 assembler is useful in 2022, but computers were a focused study that would result in productive capacity. For whatever reason that's been diffused and our attention is spent less fruitfully.
That's a reflection of modern business (especially tech).
With AI tools I think there will be a similar if not greater distance between python and something else.
I haunted Radio Shack back in the day, but would have loved to grow up doing single board computer stuff.
Because it's often true, although it's more cyclical than downhill. You have an open emerging technology and people start out self-reliant and have to learn from the ground up out of necessity, and over time things become so tower of babel like that new people can't or don't need to understand it anymore. Then it gets so bad that someone tears it down and you're back to the starting point
All the complaints about them are still valid IMO but even then I see it as less of a problem than the pathologies of previous generations.
Realize that, everything that is learned, any knowledge gained, and new technology invented, will eventually be lost and forgotten - as the people who gained said knowledge or invented said technology will eventually die, and the next generation is born ignorant. Yes, we as a species try to pass our knowledge to the next generation, via teaching, books, or what have you, but it's a never ending problem that can't ever be resolved.
Think about it, If I were to invent - say a new programming language tomorrow, the entire world would be ignorant of its existence, let alone know how it even works. Now I could go on to teach others that my new programming language exists and how it works, but this takes time, and people don't have infinite time to learn things. So as time goes on, and we learn and invent more and more things as a species, the next generation has a greater amount to learn than previous generations. Eventually there comes a point where there's too much knowledge to learn, that even if you spent your entire lifetime trying to learn what your ancestors had recorded, you would die before having learned everything. So knowledge inevitably does get lost between generations, and thus, history tends to repeat itself, and the next generation seems decadent for not knowing what you came to know.
Computer technology is just a perfect microcosm demonstrating this problem, as new things get created all the damn time (often to be just reinventions of old things). Heck, even most old programmers I know say they struggle to keep up to date on things.
And it is as old as history itself, as this is what Ecclesiastes 1:9-11 is essentially talking about. Heck, look at most ancient civilizations, and how little we can comprehend what we still have of their writings.
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.
Figma is a work tool where a designers are supposed to spend a decent amount of time, and when working on a specific project there is little navigation or moving to other pages. It being in the browser is a technical artifact to help the business model, but inherently there would be nothing lost if it was a local application synching data and changes with a central server.
If time had to be spent making react closer to desktop apps, can’t that time be spent instead on making desktop apps as sandboxed, OS compatible, easy to download and execute as web pages ?
This is something Apple doesn’t care much about, but react core devs also don’t care about desktop likeness, so it seems a to me to be a suitable alternative solution.
was Word 3.1 better than TeX or Quark Xpress or whatever? No, but it allowed people to do stuff quickly. To get things done. It was bad at scaling up, though.
Then online/cloud tools enlarged the pool even more. And finally it was possible to compete with the curse of the default, the shit forced on the world by OS vendors, corporate office suites.
Figma-like tools are the endpoint that can serve 99% of possible users. Both professionals and clueless casuals (and they don't even need to download and setup anything).
It can! This is (sort of) the vision of my current company [1]. Its founding belief is that web tech is reaching end of life and it's time for our industry to start looking at what comes next. The long term goal is to create a new competitor to the web, but not all at once. Instead we're doing it via incremental iteration on current desktop development. Starting with better distribution tools we want to work up to sandboxed, streamed, cached, crawl-able, embeddable app/document hybrids just like the web has but with very different architectures that benefit from what we've learned from 30 years of the web.
The starting point is to make it as easy for people writing desktop software to distribute their work cross-platform as it is for people making static websites. The resulting UX is that of a normal desktop app as far as the user is concerned but from the developers perspective they just grab the tool we've made and run "conveyor make site". Out pops a set of files you can upload to any static HTTP server, which are fully signed, notarized and self updating for every desktop OS. It can do this because all the packaging and signing code is implemented by the tool itself, so there are no native dependencies and it can thus be very convenient to use.
For people who like the React model an interesting way to use this is to write an app using Jetpack Compose [2] for Desktop [3]. You get a fully functional/reactive UI toolkit but without needing a mishmash of HTML/CSS/JS - it's all just Kotlin. Your Android code can be shared directly with the desktop version (with layouts for larger screens of course), and you can then go ahead and start integrating with native OS capabilities as you see fit by directly invoking their APIs. For "mobile first" companies that develop a web version primarily for desktop users, this can eliminate the need to build a web app entirely (or you can use a minimal one for search engines). Next week we'll be releasing an update that improves support for Compose Desktop apps, in fact.
There's more work to do on making distribution trivial for everyone, and of course you can use Conveyor with Electron apps if you want to - the goal here is to be layered so the lower levels are usable by everyone including web developers, and the platform gets incrementally more opinionated as you go up the layers. Once the core product has matured further we'll be exploring an experimental architecture in which RDBMS' fully replace the web server, and what advantages you get from doing so.
[1] https://hydraulic.software/
If I wanted to write the next Figma, the first thing I’d reach for is Phoenix Liveview + Channels with Vaxine/AntidoteDB or some other eventually consistent CRDT store for collaborative editing and host it on fly.io - I’d forgo the ‘front end’ completely
Not to dismiss your argument/stack preference, but forgoing the front end for a graphic design tool might prove difficult. EDIT: But yes, CRDT-backed stores are definitely the way to go for a requirement like this.
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.
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.
I'm typing this on OS X 10.9 Mavericks.
Modern UI """design""" in a nutshell. So-called designers (1) optimise for "looking good on a screenshot / promo screen", rather than for usability and aesthetics for the user, and (2) do so according to their own subjective tastes, instead of evidence-based approaches. These are to me the two major sources of the atrocious design of much of modern software.
[1] https://www.cgpgrey.com/blog/the-difference-between-the-unit...
- you first need to lay out the scrollable content normally, without a scrollbar
- then you need to detect whether it spills over, and whether a scrollbar is needed
- if so, you need to lay out all the content again, in a slightly smaller area
- if the content ever shrinks, you need to detect this too
- and if the content only _just_ fits, then it is possible that without a scrollbar, it doesn't need a scrollbar, but if there is a scrollbar, it needs to be scrollable. Chicken and egg.
This is actually pretty nasty to get right. Now factor in layout models like flex box, which also require part of the content to have a "pre layout" pass done in order to estimate "natural size", and it can get quite gnarly. And if you want to mix vertical and horizontal layouts... oof.
I got an equivalent of HTML/CSS box+flex working in Use.GPU but it took plenty of iteration.
I think the lesson here is that UI is always more complicated than you think. There are countless little tricks and mechanisms that you would only ever notice it if they didn't work. When they do, it is so "obviously" right you literally can't tell.
(As an aside, whoda thunk that a generation raised on participation trophies would be easily triggered???)
(Yes this is an alt)
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.
I have some dream of a sort of user-interface system that exposes controls and data more directly to the user, independent of the author's stylistic choices. Sort of like semantic HTML with style-sheets that are configured on a per-user basis. It would be analogous to the unix shell in the sense that it would allow small programs to easily inter-operate, like plan9's pumbing or something. Instead of having a big monolithic program like kdenlive or blender, you would have a number of modifiable general-use programs that can be re-arranged to fit many use-cases in an extensible way.
But instead of that it just seems like every toolkit or library wants to be highly specialized and complex, and provide for a very specific use-case rather than making the most general-possible user interface that is universal. Programmers should not be concerned with the appearance of their UIs like window decorations or the layout of buttons or text fields, for the same reason they should not be concerned with the minutia of optimizing assembly-code. It leads to a non-portable design. That should be left up to the system.
In order for a UI to work well and be comprehensible, there has to be a sensible hierarchy over the entire layout. If you don't achieve that, the whole might be less than the sum of its parts.
But I think React is actually probably the closest thing to what you are describing. It does a pretty good job of encapsulating UI components into fairly small chunks which can be styled externally to fit into a larger layout.
I also agree it would make sense to break things like Blender into smaller applications. But actually I think that would have more to do with having a standardized interoperable model layer, with a clear interface, so different applications could modify the same data with a different UI layer.
It will never happen.
Companies want to "brand" their UI to use it as a marketing tool. Usability and integration be damned.
I've ported some code from Tk to run on the web (including working correctly in Lynx, as much as possible) [0], and the problem is still impedance mismatch. It's worse when running it on a phone, because you want a fundamentally different UI than you can easily describe. For example, Toplevels (aka windows) don't make any sense on Android or on the Web, but work well on the desktop.
Blender, and 3d modeling in general, is a very specific use case which probably couldn’t just have some UI code thrown up over a library and be expected to work. Not like displaying some text and an image or two to rant about “those damn kids”, there’s real math behind being able to transform mouse movements into 3d space. Expecting to display a 3d environment in whatever front end UI code you want so it can have a pretty wrapper is very unrealistic.
I’m having a hard time even imagining how this would be possible without a large team working behind the scenes to do all the heavy lifting to make this even remotely possible. Wasted time IMHO as having a specialized tools for specialized domains is just how these things work.
For UI, you also need to extend programming languages to add so "nested structure with logic" as first class (which is the real value of jsx, and could, I suppose, be trivially done in lisp ?)
I would love to have a Rust + Nested trees syntax + native UI lib that look decent on all system.
But it's never going to happen for now obvious reason, so, never mind.
what they don't provide is interchangeability of programs from different environments. probably the closest thing is the freedesktop.org semi-standards, but there's not much compatibiltiy or interoperability between KDE and Gnome stack. (KDE's Plasma needs all the usual K-things and Gnome's thing needs, well, I don't know what it needs, but it does almost nothing but needs a bunch of things to do that :D Xfce sort of piggybacks on Gnome, but also uses a lot of their own shit, but at least Xfce is great.)
basically this is due to Conway's law:
https://www.youtube.com/watch?v=5IUj1EZwpJY&t=2153s
because there's no counteracting force that's pushing back to make things use a standard :/
https://en.wikipedia.org/wiki/OpenDoc
>OpenDoc is a defunct multi-platform software componentry framework standard created by Apple in the 1990s for compound documents, intended as an alternative to Microsoft's proprietary Object Linking and Embedding (OLE).[1] It is one of Apple's earliest experiments with open standards and collaborative development methods with other companies. OpenDoc development was transferred to the non-profit Component Integration Laboratories, Inc. (CI Labs), owned by a growing team of major corporate backers and effectively starting an industry consortium. In 1992, the historic AIM alliance launched between Apple, IBM, and Motorola—with OpenDoc as a foundation. With the return of Steve Jobs to Apple, OpenDoc was discontinued in March 1997.
[...]
>After three years of development on OpenDoc itself, the first OpenDoc-based product release was Apple's CyberDog web browser in May 1996. The second was on August 1, 1996, of IBM's two packages of OpenDoc components for OS/2, available on the Club OpenDoc website for a 30 day free trial: the Person Pak is "components aimed at organizing names, addresses, and other personal information", for use with personal information management (PIM) applications, at $229; and the Table Pak "to store rows and columns in a database file" at $269. IBM then anticipated the release of 50 more components by the end of 1996.[7]
WWDC 1996 Cyberdog demo
https://www.youtube.com/watch?v=UhiUncy5qW0
Steve Jobs put a bullet in Open Doc's head, and defended his decision at WWDC '97:
https://donhopkins.medium.com/focusing-is-about-saying-no-st...
“Focusing is about saying no.” -Steve Jobs, WWDC ‘97
As sad as it was, Steve Jobs was right to “put a bullet in OpenDoc’s head”.
Jobs explained (and performed) his side of the story in this fascinating and classic WWDC’97 video: “Focusing is about saying no.”
"Focusing is about saying no" - Steve Jobs (WWDC'97)
https://www.youtube.com/watch?v=H8eP99neOVs
Steve Jobs Insult Response - Highest Quality
https://www.youtube.com/watch?v=oeqPrUmVz-o
>Steve Jobs handling a tough question at the 1997 Worldwide Developer Conference. He had just returned to Apple as an advisor and was guiding sweeping change at the company. The full video is here - [original video taken down by Apple - new link: https://www.youtube.com/watch?v=GnO7D5UaDig ] - this interactions is at 50:25.
I highly recommend taking the time to watch the entire WWDC 1997 video -- it is historically profound.
Steve Jobs walked on stage and announced he wanted to take questions from the audience, right after his return to Apple from NeXT and the sweeping changes he made.
Some of the best most difficult questions really made him stop and think before speaking, and he delivered frank fascinating answers.
We all know what happened next, but it's amazing to hear how deeply and confidently he thought about it before it happened.
WWDC 1997: Steve Jobs about Apple's future:
https://www.youtube.com/watch?v=GnO7D5UaDig
>Apple's Worldwide Developers Conference (WWDC) in the San Jose Convention Center (May 13-16) was the first show after the purchase of NeXT, and focused on the efforts to use OpenStep as the foundation of the next Mac OS. The plan at that time was to introduce a new system then known as Rhapsody, which would consist of a version of OpenStep modified with a more Mac-like look and feel, the Yellow Box, along with a Blue Box that allowed existing Mac applications to run under OS emulation.
>The show focused primarily on the work in progress, including a short history of the development efforts since the two development teams had been merged on February 4. Several new additions to the system were also demonstrated, including tabbed and outline views, and a new object-based graphics layer (NSBezier). Source: wikipedia.org
Then it took an awkward and very long detour into gushing over Apple design.
And it "circled back" to a rant that seemed to trivialize things like collaborative editing and undo/redo like they were generically solved problems in the past. No, collaborative editing was not a solved problem 20 years ago. It's an evolving space with recent advancements in the CRDT space from Yjs and Automerge really opening things up.
Started really good but I was hoping it would have ended up with an analysis of the gap between where React (and browsers in general) are currently and where it ought to be; with some ideas around how to cross the gap.
You know, this isn't the first time I've thought as much about Acko's writing :\ Often there isn't a coherent thesis, but a bunch of interesting related thoughts that don't add up to anything specific.
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.
Of course this requires coordination and the larger the organization, the more this is going to slow things down. I also don't think this separation is as important on frontend javascript code, since the lines get blurry there anyway.
There's also an escape hatch to include arbitrary JS expressions inside your JSX expressions, although perhaps we should use it only to include variables and not more complex JS expressions.
In the end, templates are not important, components are. JSX provides just what's necessary to make it convenient to define components in JS.
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).
I often wonder how much further along we'd be as a society if we didn't spend the first couple decades thinking we know everything. Myself included.
How does concurrent mode help with mouse dragging? I went reading through the React docs on this and they only really talk about data fetching patterns. I'm not sure I understand how it would apply to mouse events.
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
Yeah, give us millennials a shot! The oldest of us are just 42!
This realization is what initially sold me on React. I just wanted program and build abstractions with an actual programming language!
That's exactly when I learned that same realization, and decided never to use (if I can avoid it) a programming environment that defines its own templating language.
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?
Don’t talk down and condescend to your audience for no reason
I think the article should be rewritten and all the ranting removed
It’s also difficult to follow where the author‘s going with all the side rants and unrelated remarks
And yes, that is considered ranting, contrary to what the author claims in the beginning of the article
I read it as “svelte et al gain traction due to inferior younglings, therefore react is a sinking ship, let’s not let it sink because the tooling I use is the adequate choice (despite having to be saved)”
The other frameworks or libs lately move towards non virtual dom and reactivity. Solid, Preact, Svelte, Vue, Lit are superior engineering wise. But React is about the whole economy (unbelievable VCs put 100+ millions on that), so more libs more stuff created, rich ecosystem, poor engineering.
I don’t think you understood the article.
The point he was making is that a good user interface is hard to build and is “app like”, with all the weird edge cases.
…and that, for better or worse:
1) react is the best at doing that.
2) react is (frustratingly) not making itself better at it, and is instead prioritising weird stuff like server side rendering, that is pretty niche in terms of value.
3) react competition is basically just “still the same shit web ui” but easier to build and with nicer tooling.
So, I mean, yeah it’s a rant.
…but hey, I think you’re failing if you walk away from it going “wtf was that?”.
He’s right.
Making “app like” websites is pretty hard; it’s very hard with some frameworks.
Apps are better, in almost every way.
That sucks.
No one except react was really even fighting that battle, and they seem to have lost interest.
That kind of sucks too.
Does react suck? Maybe.
…but, tldr; if you’re gonna take a big dump on react from a grey height, at least do so from a position of thoughtfulness.
“No, I’m happy with building a web ui, I don’t need slick user interactions or an interface design rather than just a form”
Cool. That’s fine. The MVP will be quick to build.
Not everyone needs to be figma.
…but pick the tool for the job; and some of the new frameworks are very finely crafted tools for a very specific job; and that job is building a generic web ui.
…but hey, the web is the context right?
So that’s fine, if you don’t care.
I wanted to build browser app without DOM too, but this is what we have! People will complain about accessibility and all default behaviour goodness that will be thrown away.
I care, we have to start with the right basis which is not React's.
In this sense, we might be in a situation where the floodgates are about to open, but who and what is able to make it happen?
This is why I can't read most tech articles these days. Won't get to the point without a long detour into the background of the problem; as someone in my forties, it's hard to justify the expense.
> 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.
There are two forces at work here when this division of labor disappears: 1.) increasing complexity in the tool designed for non-computer engineers and 2.) the subtleties of a class of worker who don’t want to do literal manual labor like typing in SQL.
At many firms it seems as if there is a layer of operations that is only capable of interacting with a CRUD UI, constricted either by ability or tooling.
That is, there is a pressure from management to split a firm in two: those that code and those that do not. This means that even something as simple as making updates to a CRUD interface is entwined with the the rest of the engineering practices.
Case in point: computer engineers writing SQL at the behest of some other entity at a firm who is not capable or allowed or even encouraged to learn or understand SQL.
I guess it depends on the domain and the lines along which you want to divide your project along. If someone can write back end code but doesn't really know that much about databases, you might end up with an application that does hundreds of database queries just to display one application view or prepare a REST query response.
If someone counts as a full stack developer but ends up producing a singleton app that cannot scale to more than one instance (e.g. stores important data in application memory, even things like user sessions), then you also probably have a bit of a problem on your hands.
If someone counts as a DevOps engineer but doesn't think too much about security, you might end up with a database instance that's publicly available, increasing the attack surface of your system a whole lot.
You can have a division of technical and non-technical folks, you can have a division between the different types of technical folks, but you absolutely do need at least someone who can wear all of the different hats (e.g. partake in a particular role) out there, in addition to them being present at the correct time to bring up things that are actually (or should be) blockers, which would otherwise get overlooked and would result in a horrendous implementation.
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.
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.
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?
Nope! You can make React apps with just a plain ol' JS file (and doing so is frankly instructive). Most folk add in JSX for extra syntactic sugar tho, so the confusion with templating is understandable.
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.
I also do think CSS is hard to learn because of how vast it is with the decades of shit piled on. There’s no clear way to do a lot of things, and if I have a solution, there’s always this doubt that I’m holding it wrong and fucking over future me.
People that know CSS tend to hate things like tailwind and css-in-js because it’s an absolute abuse of the core design principles of “correct” CSS. But these things succeed for not 100% bad reasons.
How does macOS achieve its reactivity? Is it two-way bindings? Events/messages? Immediate mode re-renders?
Cocoa also lets you two-way bind a state object with the view as long as the state object (whether it's a controller or a model or a view model) implements key-value coding; notably, the blessed data framework (Core Data) is KVC-compliant, so apps that use Core Data sort of get all this for free. Core Data also has fairly good support for undo/redo. That being said, Core Data is a fairly idiosyncratic relational data layer. It's sort of a double-edged sword: it's easy to do 90% of what you want, and the last 10% will involve some deep dives into Apple's documentation. But it's been a long time since I've written an app on OS X -- someone will have to correct my errors.
I've long thought that the inverse of what the OP suggests, bringing reactive UI programming techniques to Cocoa, would be much more interesting. Making native apps just as easy and as fun to build as web apps would be great! ReactiveCocoa/ReactiveSwift are promising, but the underlying, mutation-heavy Apple APIs still peek through. SwiftUI also seems promising, but still relatively immature to the, gosh, decades-old OS X platform.
Ended up disabling Javascript on the site to make it readable (ironic I know)
Website proceeds to slowly load and runs like crap.
Also from 6502 to 65C03 to 65C816 to 68k to PowerPC... But Apple ][ users were painfully aware of the 68k transition. ;)
Well I closed that tab.
Anyone know what this means?
Perhaps it's not a reference to the site's design, but that lobsters are red and that lobste.rs is, as I believe I saw [someone] once put it on twitter, "for people who need a second orange site in their lives?"
(I removed the name because I can't find the tweet & don't want to risk putting words in their mouth.)
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.
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.
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.
If I learn some fancy framework today, I expect to use it for years to come else my knowledge and time is wasted.
The most long lived framework currently is emberjs. But it is not the hottest, so you won't find it discussed much. The most "future proof" framework is "React" which is the one mentioned in Original article.
It goes without saying but React is the cause of a lot of churn in js ecosystem, particularly due to its "no-battery included" approach.
## what about other popular frameworks?
Other popular frameworks are angular and Vue.
Angular has gone through such a major shift between angular 1 and angular 2, that angular 2 should have been renamed.
That being said Angular2+ is also going through a paradigm shift (albeit in right direction this time)
The other popular framework is Vue. Vue's templates have has gone through minor changes. And it has gone through a major change (vue 2 to vue3) recently. It is unlikely that another such large rewrite will happen for next 3-4 years. But after that, who knows?
The only option here is to refresh your skills regularly every 2-3 years
Didn't it? I recall it was called AngularJS when it was v1.
(Yes, I'm purposefully nitpicky here, you're still right a completely new name could have been helpful here)
if someone sends you a link to a piece of content on FB and then you use the back button it sends you to your feed, and now they have a much greater chance of trapping the dear user in their algoverse.
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.
>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.
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.
There's value in separating the presentation layer from the other parts. There are nice things in Twig that are not in PHP. (Pipes, for-else, etc.)
Of course PHP was (is?) far from a general purpose language, but a templating lib allows PHP core devs to focus less on "templating".
And it's just reality that fixing/improving/iterating/evolving a library is much easier than the host language. Updating a lib version is easier than updating language version. Similarly it's a real constraint that not every company/team/engineer will be able to "just hire competent designers".
React is also suffering from this. (Due to its popularity, hence it's the victim of its own success. Or looking at the big picture it's the normal part of the hype cycle.) The article mentions that every React repo/project is different and full of their own conventions. (And implies that they are broken too.) Oh, who would have guessed? After all it's just a view layer and people will put a myriad things on top of whatever the current "create react app" spits out.
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.
I argue that it solves a clear design deficit in CSS. You cannot have tight coupling with CSS and a lot of the time you want tight coupling. In-line styles are insufficient, so we have tailwind. It’s an API to css that lets you tightly couple your styles. The re-usability of those styles is accomplished by composition of components or composition of atoms via @apply.
Popularity doesn't mean much. I mean, look at React.
And Tailwind isn't that popular. From Twitter you might get the impression everyone is using it, but if you look at the State of CSS you'll see is not even close to something like Bootstrap or SASS.
