That was my guess as well (re lobste.rs), so I went there for the first time, but while the favicon is red the site itself doesn't have a prominent color at all, so I've no idea.
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 come here to read interesting content about a variety of topics - even things that I spend very little time thinking about. I trust the community's ability to curate interesting content. Even if you think my trust is misplaced, I derive enjoyment from the articles and the ensuing content.
I go to lobste.rs for software development content exclusively. There seems to be a bit more of an intentional focus on that kind of content there.
“The orange site” is some weird euphemism twitter users use when complaining about HN. It’s also a great search term to chuck in to twitter for some entertainment.
because the name is harmless, uninteresting and unambiguous, but if anyone asks "what's that orange site" they can explain that it's bad because it's libertarian/capitalist/idealist/optimist/progressive/every-account-is-elon-musk-himself.
and this helps them to maintain their nice oversimplification too.
This post ultimately seems to spend a long time complaining about other people not putting in the effort to fix the problems of React... while the author doesn't offer any solutions or even ideas for solutions.
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).
That's a pretty inexperienced take, out of context. People should absolutely learn from elders, even if they feel the elders are wrong. Which is pretty much, every young person who has ever existed. There are often nuggets of wisdom buried inside resistance to change.
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.
"Wisdom" of elders should stand on its own by being well reasoned.
If someone needs to say "listen to your elders" then they aren't able to articulate their argument well enough to stand without it.
(I've been programming much longer than the 32 years claimed by the article author. No one should listen to me because I'm old, except in the case where I'm talking about specific incidents I witnessed that younger people didn't.)
> except in the case where I'm talking about specific incidents I witnessed that younger people didn't
All in interpretation. I implicitly assume 'listen to your elders' is about experience, not age. Perhaps others read that differently.
I don't think anyone is arguing a young PHD should do what an old chimney sweep tells him just because he's older. Unless of course said advice applies to PHD somehow.
No, teaching react is the opposite. When one is invested in the hammer all they see is nails type of analogy at play here. I personally dont do UI stuff and don’t know who is responsible for what I notice as a utter mess in UI, across the board not only on the web.
> the kind of stuff concurrent mode is supposed to fix (for example, React updates not happening fast enough to keep up with mouse dragging).
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.
Doesn’t it help with having only high priority ui updates on the main ui thread with everything else happening in the background? To get low latency ui updates that’s exactly what you want: move everything except the low latency work to different threads.
> Crucially, none of the React alternatives solve this
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.
>I'm not sure what's the point of React here nor "Saving React". Why it needs to be saved in which sense.
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)”
Yeah. The first paragraph is that point, but the follow up paragraphs are more of general sense of building UI.
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 do agree with you, but to play devil's advocate: This article is currently #9 trending on the front page. I've meanwhile seen similar critiques of React written in a different style, and seen them not get a vote or comment. Perhaps those rants do serve a purpose?
> I honestly think after reading 50% of the article is all about bragging knowing history.
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.
I kinda get him having to drag these historical UI to draw some points but ended up having no critical points for current context and title. I guess it's info for "Get in Zoomer" part but failed to demonstrate "We're Saving React". If a zoomer read that, what should they do, what's the point to get start here, and should they save React or start something new?
(As a zoomer,) I know that React is designed as the way it is because it's limited by the DOM model for all rendering and user interaction, whereas for native apps you have much more freedom in terms of design space of GUI toolkits (from a completely retained model like Qt to highly immediate ones like IMGUI).
The disappointment of the article is that he talks about how the Mac OS X apps were the pinnacle of desktop applications, but he never talks about how people have achieved this. Did the Cocoa API made some special design decisions (as opposed to MFC or Qt) that enabled devs to make more reactive apps?
You know it well (DOM, Retained | Immediate). There's nothing to do with saving react here. Talking about browser app specially, I'd keep eye on standard like Template Instantiation and the coming up Symbol as Map's key. It's closed to the recent "Signal (reactivity)" trend. A way to update part of tree more efficiently without re-render-the-whole-thing. As long as we still use DOM, it's not going to be more revolutionary than this.
The only possible Revolution I see is not using the DOM. JS + WASM is fast enough, the DOM is not fast enough, or good enough, enough here meaning enough for creating highly dynamic 60FPS experiences. Main issue with leaving it behind is A11Y though.
> FFS. The context is the web, nobody solves graphic problem like gaming for you, or need to…
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.
It's either DOM or Canvas as foundation we have right now in browser. Not seeing economy around WebGL that much. He talks about GPU multiple times. And these aren't thing related to React at all. React is not "the best at doing that", so I disagree here .. thoughtfulness is that it's repetitive thing to say on HN, people disagree with virtualDOM for a long while, Signal (reactivity) isn't new idea either. More thoughtful thing to say is get "DOM part" and "Template Instantiation" to work so that we have an efficient update mech basis to rely on.
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.
You mean like download qt and make an app that compiles on everything and integrates much better than a webpage while also being much faster and smaller?
If you don't care about what your potential users want, that's fine, but I don't see why you would be partaking in an argument that's mostly about trying to reach more users.
He does not mention gaming once though. The web quickly got to the point where UIs are possible, but lately there's seemingly little or no progress in making app-quality UI possible let alone easy.
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?
I don’t understand arguments like this. PHP is fortunate enough to run on a real operating system with real APIs. React is running in the browser which is quite possibly the worst place to make anything stable. It will never be as stable.
I thought this was the most insightful part, though it would be the second most if the author did more than allude to conflict-free replicated data types.
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.
I always thought the point of the template language was more to enforce the boundary of presentation and code. and thus any template language that grows too powerful is a bad template language, because it's no longer doing the one job it has. So I think a template language should have loops, (non mutable) variables and basic conditions, that's it. So if there's something you can't do in your template that you want to do, the solution then isn't to write some sort of hideous thing in a bespoke templating language, but to add another variable/loop/whatever to the template.
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.
If a template needs loops or even conditionals, it is already too complex for my taste as it leads to wrong design patterns blurring presentation/code boundary. Something that just allows to access variables and call functions will keep the boundary while allowing a non-programmer or even the end-user to edit it.
Logic-less template is ok despite some having loop because semantically, users also want to list things, add a thing to a list. I wouldn't add `if/else` but switch-case (this simulates category in user space, not complex condition). "Local variable" shouldn't be exposed to users. Collection name is ok. I think Shopify's Liquid is good, they just can't figure out decent UX on top of it.
A logic-less template is easily done, by exposing a few methods to the programmer providing the data. I remember Android XMLs to be logic-less and while it refers to concrete classes, something like this could easily be adapted to generate text. A designer wouldn’t need conditionals or loops because he could mark something as a container, the goes on to design the content (for loop, each cell). Desktop and Mobile had this for ages.
I’d be more than happy if a more powerful version of figma existed (capable of handling UI states). Then the designer would then hand the design files annotated with IDs to me, and then I could go on to implement logic. If we agree on some sort of contract for the UI, he can go play to his heart’s content with the Look and Feel.
I have this idea in mind, how do think about 1 AST <-> 3 different UIs? Content editor, Developer, Designer. Each expose different things but shared AST. Because I think 1 UI with mixed bag contracts is not going to do it.
disagree, because the alternative is having a million tiny templates, which is annoying and cumbersome. sometimes you just want a condition to check if a user has an avatar, or if there are replies to a post, or whatever else. same with loop, if something is specific to a template, there's no reason for repeating content to not be a loop (I don't think a template system should allow custom loops though, only looping over predefined content).
I prefer having one big template for a view, when doing SSR. Some layout components will have to be their own template if they repeat on different pages, depending on the template engine you can either pull other templates in directly (in which case using loops is also valid here IMO), or have a variable with a HTML blob generated from another template.
I don't really think either of those things count as code, because there's only logic that is relevant to how things are displayed. It's just, if the user has an avatar, show an image tag, otherwise, show a placeholder image/nothing. repeat this HTML once for each comment shown. That's not code in any meaningful way. I mean technically all of it is code, but you know what I mean.
If one wants a view for the whole page, then using a programming language with a good support for embedding strings will be a better solution as it avoids the need to learn one more language.
a simple template language is composed in its entirety of like 3 separate pieces of syntax, it should be something you can learn in 5 minutes. Like I said in my original post, the point of it is to limit what you can do, so that templates stay templates, and code stays code. If there's a learning curve to your template language, you've already lost.
The template system is somewhat like the type system in that it provides you guarantees. The templates cannot mutate any data or pull anything in that you didn't provide to it. You can be 100% sure that no one did a cute little temporary hack modifying the data inside the template somewhere, pulled in some external data real quick on a friday afternoon or did anything else that doesn't belong in the template. That's the advantage over just using a regular programming language.
DSLs have their place. arguably we have too few of them. we always use a general language. which is good, because it's general, sometimes great at a few things, but usually very awkwardly at most of the things.
Alan Kay (and his teammates during the STEPS project at VPRI) spent years and years thinking/experimenting with this, here's the final report from 2016: https://news.ycombinator.com/item?id=11686325
"The big breakthrough is making it easy to create new DSLs for any situation."
Yes, JSX (and React) is interesting in this way: it's not a (full) template language. Instead, it's a convenient way to write component fragments that include HTML/XML expressions and further components. Each component top-level is still JavaScript statements.
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.
Exactly, I was a bit undecided back in the day thinking React and Angular might be similarly valuable, and I don't remember if there was even Vue yet or not (I believe not yet). Angular had just split, and I had to help contracting for a company using Angular 1, and OH BOY the page was horizontal and most of the programming statements happened within those nightmarish ng-if, ng-repeat, ng-{please-kill-me-know}. I believe there were parts up to 350-400 columns wide.
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.
I just wanted to wire up shit, make pages, send requests & receive responses ... and not spend days trying to pick the right router, form, state and whatever library for my view layer, and look for TS definitions for them, so I stayed on Angular2+ ^^
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.
>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
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.
Yeah strangely it compiles to functions but they way they compose is not the way we compose function. Practically it's a template, compose via component mechanism. If it's a language it should be like Elm where attributes and children are also List and have return type, can be programed in function style.
I think the point is that React is a true programming language with syntactic sugar to make it look templates, vs templates that bolt on some language.
React is just JS as any other app using JS with templating. I really fail to see the benefit with the React approach. If anything it makes it more difficult to have a 100% match between design and the end product.
How much React have you written? Because React is just JavaScript, you can take traditional programming patterns and apply them to your UI, for example higher-order components. You can't do this with templating.
Hm, can you describe what do you mean by "can't do this with templating"?
Do you mean that since React/JSX kind of a superset of JS you can do higher order stuff in it, whereas in a simple templating language like Jinja2 you can't?
Isn't that a false equivalence? I mean I regularly use patterns similar to HOCs in Angular. It's easy to wrap components[0] and it's just as possible to project components into other components programmatically[1] with complete dynamism.
[0] depending on the use case there are different preferred ways: directives, which have access to the wrapped component and its template, and can interact with it in many ways, or you can do it from raw TS ( https://github.com/abumuawiyah/ng-ivy/blob/master/src/app/ap... see the withTheme and withStyles functions )
I wrote this on my phone. Hopefully it makes sense.
No templating language is going to beat a general purpose programming language as far as features go.
There’s no technical limitation of templated languages that would bar them from having the same functionality as a general purpose language. Whoever is designing the templated language is probably not going to design something as powerful as a general purpose language.
Angular built a specific set of keywords to include higher order components. React did no such thing — they exist for free because it’s all just JS. You could imagine that there are other patterns that exist in JS that you can’t express in Angular because it doesn’t have all of the flexibility of JS.
From your example you showed that you used TS to create your component, essentially using an escape hatch from Angulars templating language to do what you want. You don’t have to escape from React, because you’re already in JS.
I haven’t used Angular in a while, but I have been using Vue recently. The difference is huge. I can’t (easily) put a Vue component in a stack. I have to learn Vues syntax that will have zero transfer when I go to another framework, whereas React is just JavaScript (JSX does change some HTML attributes, but it is generally 1:1).
To close, I don’t think React is required to be productive or write good UI. I just really like it because there’s no magic going on. It’s just syntactic sugar over JS.
Hm. I find this kind of inconsistent, as you already have HTML in your JS, so it's not just JS. HTML is the templating. JSX is a super lightweight layer on HTML with its own weird rules.
I don't like Angular's default verbosity of separating the template from the logic, nor it's hijacking of the simple double quotes, but I disliked fighting with JSX and too too large files in React. Plus in my experience React projects grow their own verbosity too (in my last NextJS project every component had at least 2 files, one for wiring up the state and one for lowlevel view things, and it was awfully unclear what goes where). Plus the stringly typed state store :(
I don't think it's true that a general purpose language will be always better than a templating language. For one thing the template gets interpreted, there's already a context, it can be safer and more efficient. I mean JSX is great because it allows easy interpolation, in plain JS you would have to do backticks and ${} and the IDE/editor/linter would need to guess (or you would need to annotate the string like in Markdown) about the syntax and semantics of what you want to emit.
Of course making the jump from the host language to the target language too onerous leads to inefficient engineering, boundaries placed at convenient instead of optimal places, etc.
And it's very good that JSX allows stepping back to JS easily. Angular templates allow that too, but it's just not as fluid (probably because the syntax is just meh).
There are specific keywords to do things in template-land and there are non-template ways, that are more general and more messy. Because DSLs can be more effective for the things they were designed to express. The simple React HOC composition is similarly simple in Angular too, <ng-content /> and that's it. What's less appealing is that it happens in template land, and for some reason the wrapping in pure JS feels more powerful (to me too, don't get me wrong), but the actual hierarchy of components is defined in template - in JSX - in React too. It just feels closer to JS. (Rightfully so.)
> I find this kind of inconsistent, as you already have HTML in your JS, so it's not just JS.
You don’t write HTML in React. You write JSX that gets compiled down to function calls which at runtime becomes HTML. JSX is a nicer syntax to make function calls look like HTML. I know this sounds pedantic, but this is the exact thing that differentiates React from others.
People who use it from ClojureScript, for one. Due to the nicer Clojure syntax you don't need a templating language, just a data convention (hiccup in this case).
For those of us who hope JS will slowly become just a compile target, a downside of of JSX is that it's tooling is JS specific, and the syntax is tailored to JS. So it's great that React isn't married to JSX.
I wrote a GUI framework that uses React API directly.
It's more proof of concept than useable, the idea is that we don't actually have to write layouts, we can just describe the layout with code or a template language and let the computer work it out.
This article is weird linking together many unrelated strands of thought.
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.
As someone who has admittedly worked on approximately 0 user-facing programs, it seems like there are not many revolutionary ideas when it comes UI.
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.
It's a nice idea, but if it were easy it would have been done by now. I think a lot of the problem is that UI tends to be very specific, and often giving one component what it needs to work well imposes requirements on other components.
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.
Tk, and especially Themed Tk (Ttk) mostly fit this. It even has 3 geometry managers.
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.
To me this idea sounds a little bit like how Java Swing works. At least it seems similar to the pluggable LookAndFeel?
I think it was a great idea but it seems like it never got any traction. Or maybe more like Java never got popular on desktop.
I understand Haiku (née BeOS) has UI concept at the OS level, which should probably simplify many things.
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.
>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]
>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.
Check out the stylish 8 bit error diffusion dithered gradients and cheesy 90's drum loop in this delightfully retro but content-free "Apple OpenDoc Technology Intro" -- the take-away point is that Apple and IBM and Oracle were really pushing OpenDoc and making a lot of promises about supporting it for a while:
>Video clip from the original Apple OpenDoc: A Crucial breakthrough! CD
This one has a much funkier intro, and has more substantial down-to-earth information about OpenDoc. He's got HyperCard and AppleScript in their original boxes on the shelf behind him, so he knows what he's talking about:
>OpenDoc: A New Standard for Compound Documents, a lecture by Kurt Piersol. The video was recorded in March 1994.
>From University Video Communications' catalog:
>"OpenDoc represents a new standard method of building editors which support assembly and editing of compound documents on many computing platforms. Kurt Piersol discusses the need for compound document systems, their requirements, and OpenDoc's industrial and technical approach."
> 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.
It will never happen.
Companies want to "brand" their UI to use it as a marketing tool. Usability and integration be damned.
I've thought the same thing. A tech that lets you consume data from web sites but visualize it in any way you want. Despite the naysayers in other replies I think it is possible
in the early days of web2, everyone high on RSS feeds and dreaming about pubsubhubbub ... when a google maps embed was just a few seconds and half a line of code, when OAuth1a and JSONP were all the rage, well, back then 3rd party was not a swearword and it did not automatically meant ad-fucking-track-tech.
back then it was seen as the great, bold, and messy cross-linking organically-grown future.
it was called "semantic web", every day people were announcing how simple it is to encode more and more machine-readable stuff less-and-less intrusively into your HTML or xml+atom.
then facebook became the web, twitter became the truth and one day the dream got mugged, beaten up and left to bleed out in a back alley on July 1 in 2013.
everyone got mad and posted about it on their phone using an app from a nice boring, proactively curated walled garden.
> 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.
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.
desktop environments (from Windows to iOS, including OSX, macOS, KDE, Gnome and everything in between) sort of already do this. they provide services and they provide apps/programs that require those services.
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.)
The article started really strong and I believe the point about React and knock-off frameworks not evolving to really solve challenges modern web applications face is good and worth exploring.
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.
> This article is weird linking together many unrelated strands of thought.
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.
> What's really frustrating about all this is how passive and helpless the current generation of web developers seem to be in all this. It's as if they've all been lulled into complacency by convenience. They seem afraid to carve out their own ambitious paths, and lack serious gusto for engineering. If there isn't a "friendly" bot spewing encouraging messages with plenty of emoji at every turn, they won't engage.
> 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?
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
"Hard times create strong [developers]. Strong [developers] create good times. Good times create weak [developers]. And, weak [developers] create hard times."...?
I didn't read the article, but just based on the passages you have quoted and based on my recent experience, I will have to agree with the author.
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.
This isn't a new phenomenon. This strategy is proven to work largely because of people like you who put in time and effort to answer those types of questions with quality information. Stack Overflow was literally built on this very premise.
On the one hand I hate help vampires who appear to show no effort and just want "gimme da codez!"
On the other hand, it's impossible to remember what it was like to not know something. So often, just giving hints isn't enough. When I used to spend too much time answering S.O. questions I tried to, as often as possible, include a working snippet. One, to prove the solution worked, but two, so the questioner could start with working code.
Starting with working code is the number 1 thing for me because then I can start adding to it until it breaks and can always go back to working.
Maybe, but in some (many) cases you’d be better off spending the time developing your general knowledge of whatever it is you are working on to the point of solving your problem. This will not only solve your problem but also make you a better engineer. This is especially true with complex/dense material (e.g. kubernetes) where a lot of the learning is generally applicable.
> I recently learned that GitHub has a discussions page which is separate from the issues pages.
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.
Mostly likely it's neither, and the problems we notice is due to a very biased sample.
We don't see the many thousands who solve problems quietly, and even when we see them we tend to make note only of the most unskilled ones.
Compounding this with the fact that all over the world more people are motivated to learn and work in IT we are simply bound to see more extreme outliers.
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.
It's an hourglass where the width is accessibility and the height is abstraction. In the center is the sweet spot. Basic was near there. Pascal probably was. Ruby, PHP and Python are capable of being there...
As an example outside of computers, think about highly abstract art, highly abstract philosophy or poetry.
It comes across as obdurate and diffusive, aloof and needlessly distanced from materiality.
Now in programming you see the same thing. Abstract language that seems to exist in pure vapor. Factory, interface, provider, service, oh and a provider service and a service provider which are not the same things of course.
All these things mean very specific things that change depending on whose lips are moving - they're defined in code somewhere - they do something deterministic - there is a real materialist function here that's being obscured by confusing language. We've entered the age of Jurgen Habermas style programming.
It's fine if you want that, but don't pretend it's successfully easier to understand when poorly, vaguely, and also precisely defined.
The computer is a picky, unrelenting, uncompromising bratty jerk. Because of this programming concepts are best when they're nailed the fuck down and not dancing around in some abstract freeform jazz space pretending that it's more accessible that way.
All it does is create confusion and the emotion of confidence replacing the reality of competence. The computer is still going to be a bastard and we'll have to deal with it eventually.
Was about to upvote then you said 6502 asm isn't useful in 2022... If anything, learning 6502 asm is instructive because it isn't very abstract but forces you to turn abstract thinking to explicit instructions.
6502 is so bare bones, that programming it even over things like x86 is instructive, it really forces you (or it does for me) to think hard about doing things, even mundanely "easy" things that people who only program C say are fast and low level.
But anyway, it's not "useful" for actual everyday work, it's more of a nice challenge that keeps your mind sharp.
And for my c64, ah I need time to solder stuff so it can connect to another machine, much less the internet ;) one of these days...
It’s because older generations inevitably devalue an evolving culture they can no longer comprehend as a defense mechanism to avoid admitting they can’t keep up. Anyone who seriously makes this argument that the Kids These Days are lazy/bad/worse than their own generation is either delusional or just lazy.
(As an elder cusper due to being terminally online for 15 years) 2020s pop culture so far is miles better than what we had in the early 2010s and IMO the 20 year olds are far more tolerable than they were when I was 20.
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.
Including the complaint from the OP about how zoomers are passive? If it's true (which I'm not convinced of), it seems like a fatal flaw, unless you're saying that inaction is preferable to some of the pathologies of previous generations (presumably including mine; I was born in 1980).
Ah, makes sense. But then, the OP also said zoomers don't know how to dance. But, as an admittedly curmudgeonly early forty-something, I wonder if that's at least partly because so much of current pop music is garbage. Then again, I guess most of any generation's pop music has always been crap; we only remember the classics from the past.
Back to technology, though, I worry about what computing will be like for Generation Alpha (born after 2010 according to Wikipedia), including my nieces and nephew. Perhaps I didn't help matters by buying them Amazon Fire tablets when they were little, though my siblings and in-laws certainly appreciated it. I feel like intervening to get them started on some kind of more open computing platform, but I fear I might sabotage the development of a new, better computing culture if I try too hard to replicate what things were like for me growing up with an Apple II and early PCs. Edit: And no, I don't feel qualified to become a father myself so I can avoid meddling with others' kids. So I guess I'll just stay on the sidelines, watch, and try to keep my opinions to myself.
It is as old as history itself. What you're witnessing is a result of what I call the problem of knowledge.
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.
If I had to venture to guess based on how their APIs work, it's probably events. There's a system called "NotificationCenter" which can be observed to receive system events within Apple API's which is quite old.
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.
> Now, before you close this tab thinking "ugh, not another tech rant", let me first remind you that a post is not a rant simply because it makes you angry. Next, let me point out that I've been writing code for 32 years
Ha, I was wondering if I'm the only one allergic to that attitude. For me it was one sentence later at "You should listen to your elders" where I decided this piece won't be much of a value and head over to the comments which never fail to have some interesting insights without forcing me to read extended history and ramblings.
The author of this article also wrote the for me mind blowing things like MathBox2 [0], the Pixel Factory [1] and many more. The often mentioned clone of React in the article, described in "The GPU Banana Stand" [2] is something that wasn't heavily discussed here as I think the concepts are just very advanced. I mention this as I believe this is what the author is concerned about and what some might haven't experienced. Using React for "advanced" things were it just doesn't cut it and one has to go back to manual DOM manipulation, or having to dig very deep to understand how one can build UIs were the elements update 60 times per second. React works great for things were this is not a concern, but if the standard has these innate restrictions, what applications will the future hold if all people know is React?
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.
If this was a rant on boomers, it would be seen as ageist. Let's not blame all the new stuff on the new generation, it's not like a hoard of zoomersTM wrote react right after graduation.
I don’t blame it on the new generation at all and the boomer zoomer dichotomy bothers me quite a bit. I just want us all to steer away from this disaster in the making.
250 comments
[ 3.0 ms ] story [ 234 ms ] threadAnyone 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 come here to read interesting content about a variety of topics - even things that I spend very little time thinking about. I trust the community's ability to curate interesting content. Even if you think my trust is misplaced, I derive enjoyment from the articles and the ensuing content.
I go to lobste.rs for software development content exclusively. There seems to be a bit more of an intentional focus on that kind of content there.
and this helps them to maintain their nice oversimplification too.
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.
If someone needs to say "listen to your elders" then they aren't able to articulate their argument well enough to stand without it.
(I've been programming much longer than the 32 years claimed by the article author. No one should listen to me because I'm old, except in the case where I'm talking about specific incidents I witnessed that younger people didn't.)
All in interpretation. I implicitly assume 'listen to your elders' is about experience, not age. Perhaps others read that differently.
I don't think anyone is arguing a young PHD should do what an old chimney sweep tells him just because he's older. Unless of course said advice applies to PHD somehow.
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.
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?
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.
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
https://tamagui.dev/docs/intro/compiler
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.
The disappointment of the article is that he talks about how the Mac OS X apps were the pinnacle of desktop applications, but he never talks about how people have achieved this. Did the Cocoa API made some special design decisions (as opposed to MFC or Qt) that enabled devs to make more reactive apps?
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?
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.
I’d be more than happy if a more powerful version of figma existed (capable of handling UI states). Then the designer would then hand the design files annotated with IDs to me, and then I could go on to implement logic. If we agree on some sort of contract for the UI, he can go play to his heart’s content with the Look and Feel.
I prefer having one big template for a view, when doing SSR. Some layout components will have to be their own template if they repeat on different pages, depending on the template engine you can either pull other templates in directly (in which case using loops is also valid here IMO), or have a variable with a HTML blob generated from another template.
I don't really think either of those things count as code, because there's only logic that is relevant to how things are displayed. It's just, if the user has an avatar, show an image tag, otherwise, show a placeholder image/nothing. repeat this HTML once for each comment shown. That's not code in any meaningful way. I mean technically all of it is code, but you know what I mean.
The template system is somewhat like the type system in that it provides you guarantees. The templates cannot mutate any data or pull anything in that you didn't provide to it. You can be 100% sure that no one did a cute little temporary hack modifying the data inside the template somewhere, pulled in some external data real quick on a friday afternoon or did anything else that doesn't belong in the template. That's the advantage over just using a regular programming language.
Alan Kay (and his teammates during the STEPS project at VPRI) spent years and years thinking/experimenting with this, here's the final report from 2016: https://news.ycombinator.com/item?id=11686325
"The big breakthrough is making it easy to create new DSLs for any situation."
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.
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.
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.
Website proceeds to slowly load and runs like crap.
Ended up disabling Javascript on the site to make it readable (ironic I know)
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.
Do you mean that since React/JSX kind of a superset of JS you can do higher order stuff in it, whereas in a simple templating language like Jinja2 you can't?
Isn't that a false equivalence? I mean I regularly use patterns similar to HOCs in Angular. It's easy to wrap components[0] and it's just as possible to project components into other components programmatically[1] with complete dynamism.
[0] depending on the use case there are different preferred ways: directives, which have access to the wrapped component and its template, and can interact with it in many ways, or you can do it from raw TS ( https://github.com/abumuawiyah/ng-ivy/blob/master/src/app/ap... see the withTheme and withStyles functions )
[1] for simple things https://blog.angular-university.io/angular-ng-template-ng-co... ... see also the official working example from the docs https://stackblitz.com/edit/angular-568wsw?file=src/app/ad.s...
No templating language is going to beat a general purpose programming language as far as features go.
There’s no technical limitation of templated languages that would bar them from having the same functionality as a general purpose language. Whoever is designing the templated language is probably not going to design something as powerful as a general purpose language.
Angular built a specific set of keywords to include higher order components. React did no such thing — they exist for free because it’s all just JS. You could imagine that there are other patterns that exist in JS that you can’t express in Angular because it doesn’t have all of the flexibility of JS.
From your example you showed that you used TS to create your component, essentially using an escape hatch from Angulars templating language to do what you want. You don’t have to escape from React, because you’re already in JS.
I haven’t used Angular in a while, but I have been using Vue recently. The difference is huge. I can’t (easily) put a Vue component in a stack. I have to learn Vues syntax that will have zero transfer when I go to another framework, whereas React is just JavaScript (JSX does change some HTML attributes, but it is generally 1:1).
To close, I don’t think React is required to be productive or write good UI. I just really like it because there’s no magic going on. It’s just syntactic sugar over JS.
I don't like Angular's default verbosity of separating the template from the logic, nor it's hijacking of the simple double quotes, but I disliked fighting with JSX and too too large files in React. Plus in my experience React projects grow their own verbosity too (in my last NextJS project every component had at least 2 files, one for wiring up the state and one for lowlevel view things, and it was awfully unclear what goes where). Plus the stringly typed state store :(
I don't think it's true that a general purpose language will be always better than a templating language. For one thing the template gets interpreted, there's already a context, it can be safer and more efficient. I mean JSX is great because it allows easy interpolation, in plain JS you would have to do backticks and ${} and the IDE/editor/linter would need to guess (or you would need to annotate the string like in Markdown) about the syntax and semantics of what you want to emit.
Of course making the jump from the host language to the target language too onerous leads to inefficient engineering, boundaries placed at convenient instead of optimal places, etc.
And it's very good that JSX allows stepping back to JS easily. Angular templates allow that too, but it's just not as fluid (probably because the syntax is just meh).
There are specific keywords to do things in template-land and there are non-template ways, that are more general and more messy. Because DSLs can be more effective for the things they were designed to express. The simple React HOC composition is similarly simple in Angular too, <ng-content /> and that's it. What's less appealing is that it happens in template land, and for some reason the wrapping in pure JS feels more powerful (to me too, don't get me wrong), but the actual hierarchy of components is defined in template - in JSX - in React too. It just feels closer to JS. (Rightfully so.)
You don’t write HTML in React. You write JSX that gets compiled down to function calls which at runtime becomes HTML. JSX is a nicer syntax to make function calls look like HTML. I know this sounds pedantic, but this is the exact thing that differentiates React from others.
As far as I know all modern frameworks only produce JS files and the index.html only contains the <app-root/>.
For those of us who hope JS will slowly become just a compile target, a downside of of JSX is that it's tooling is JS specific, and the syntax is tailored to JS. So it's great that React isn't married to JSX.
It's more proof of concept than useable, the idea is that we don't actually have to write layouts, we can just describe the layout with code or a template language and let the computer work it out.
https://github.com/samsquire/additive-guis
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.
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.
[0] https://rkeene.org/projects/tkweb/
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.
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 S...
https://www.youtube.com/watch?v=oFJdjk2rq4E
>Video clip from the original Apple OpenDoc: A Crucial breakthrough! CD
This one has a much funkier intro, and has more substantial down-to-earth information about OpenDoc. He's got HyperCard and AppleScript in their original boxes on the shelf behind him, so he knows what he's talking about:
https://www.youtube.com/watch?v=2FSFvEIpm5o
>OpenDoc: A New Standard for Compound Documents, a lecture by Kurt Piersol. The video was recorded in March 1994.
>From University Video Communications' catalog:
>"OpenDoc represents a new standard method of building editors which support assembly and editing of compound documents on many computing platforms. Kurt Piersol discusses the need for compound document systems, their requirements, and OpenDoc's industrial and technical approach."
It will never happen.
Companies want to "brand" their UI to use it as a marketing tool. Usability and integration be damned.
back then it was seen as the great, bold, and messy cross-linking organically-grown future.
it was called "semantic web", every day people were announcing how simple it is to encode more and more machine-readable stuff less-and-less intrusively into your HTML or xml+atom.
then facebook became the web, twitter became the truth and one day the dream got mugged, beaten up and left to bleed out in a back alley on July 1 in 2013.
everyone got mad and posted about it on their phone using an app from a nice boring, proactively curated walled garden.
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.
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 :/
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.
> 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?
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
https://acoup.blog/2020/01/17/collections-the-fremen-mirage-...
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.
On the other hand, it's impossible to remember what it was like to not know something. So often, just giving hints isn't enough. When I used to spend too much time answering S.O. questions I tried to, as often as possible, include a working snippet. One, to prove the solution worked, but two, so the questioner could start with working code.
Starting with working code is the number 1 thing for me because then I can start adding to it until it breaks and can always go back to working.
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.
The only things worth posting to them are information you yourself weren't able to find on the internet.
We don't see the many thousands who solve problems quietly, and even when we see them we tend to make note only of the most unskilled ones.
Compounding this with the fact that all over the world more people are motivated to learn and work in IT we are simply bound to see more extreme outliers.
https://en.wikipedia.org/wiki/Eternal_September
https://en.wikipedia.org/wiki/XY_problem
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.
It's an hourglass where the width is accessibility and the height is abstraction. In the center is the sweet spot. Basic was near there. Pascal probably was. Ruby, PHP and Python are capable of being there...
As an example outside of computers, think about highly abstract art, highly abstract philosophy or poetry.
It comes across as obdurate and diffusive, aloof and needlessly distanced from materiality.
Now in programming you see the same thing. Abstract language that seems to exist in pure vapor. Factory, interface, provider, service, oh and a provider service and a service provider which are not the same things of course.
All these things mean very specific things that change depending on whose lips are moving - they're defined in code somewhere - they do something deterministic - there is a real materialist function here that's being obscured by confusing language. We've entered the age of Jurgen Habermas style programming.
It's fine if you want that, but don't pretend it's successfully easier to understand when poorly, vaguely, and also precisely defined.
The computer is a picky, unrelenting, uncompromising bratty jerk. Because of this programming concepts are best when they're nailed the fuck down and not dancing around in some abstract freeform jazz space pretending that it's more accessible that way.
All it does is create confusion and the emotion of confidence replacing the reality of competence. The computer is still going to be a bastard and we'll have to deal with it eventually.
I haunted Radio Shack back in the day, but would have loved to grow up doing single board computer stuff.
(if it is, I would like to read your blog)
But anyway, it's not "useful" for actual everyday work, it's more of a nice challenge that keeps your mind sharp.
And for my c64, ah I need time to solder stuff so it can connect to another machine, much less the internet ;) one of these days...
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.
Including the complaint from the OP about how zoomers are passive? If it's true (which I'm not convinced of), it seems like a fatal flaw, unless you're saying that inaction is preferable to some of the pathologies of previous generations (presumably including mine; I was born in 1980).
It’s not the zoomers fault though. It was the previous generation or two that built this hellscape of cloud software and addiction oriented UIs.
Back to technology, though, I worry about what computing will be like for Generation Alpha (born after 2010 according to Wikipedia), including my nieces and nephew. Perhaps I didn't help matters by buying them Amazon Fire tablets when they were little, though my siblings and in-laws certainly appreciated it. I feel like intervening to get them started on some kind of more open computing platform, but I fear I might sabotage the development of a new, better computing culture if I try too hard to replicate what things were like for me growing up with an Apple II and early PCs. Edit: And no, I don't feel qualified to become a father myself so I can avoid meddling with others' kids. So I guess I'll just stay on the sidelines, watch, and try to keep my opinions to myself.
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.
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.
Well I closed that tab.
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
[2]: https://acko.net/blog/the-gpu-banana-stand/
Yeah, give us millennials a shot! The oldest of us are just 42!