Android actually has one real way to build UIs — it's the views and the resource system. Everything else is just Google's abstractions over that, which are either beta or deprecated.
I'm not sure what kinds of tools do you expect. You do have to make layouts for different screen sizes, no real way around that. You'd usually want two breakpoints, so you have phones, small tablets (and foldable inner screens), and large tablets.
I'd like to see equivalents of UIKit/SwiftUI components that do most of the layout/navigation heavy lifting for you. For most apps, either the iOS 18+ UITabController or UISplitViewController comfortably covers every platform, orientation, and screen an iOS app can possibly run on with a tiny fraction as much boilerplate and manual ratcheting as is required in Compose.
There are, watch the "Strike a pose with adaptive layouts" video they posed yesterday (https://developer.apple.com/iphone-duo/). High level components like split views will adapt automatically, while things like scroll views won't, so there are new adaptive views (AdaptiveView, UIArrangementViewController) to help you move things around.
Even if you don't have sympathy on an individual level for hundreds of thousands of ordinary, working-class people with decades-long careers suddenly losing their livelihood (and you really should have sympathy for them), you should at least care on a selfish level for the increased risk of civil unrest that such a socioeconomic upheaval can cause.
I'm from a country that transitioned from free market and private property to planned economy and socialism, and then, 70 years later, back again. I'm sure it'll be fine. You can't scare me with such things :)
Very much this. And another problem is that the US forced most of the world to adopt similar laws through various cartels, oh, sorry, trade agreements. I distinctly remember when suddenly it was no longer okay to openly sell pirated software in Russia "because we're joining WTO". I still have no idea why we joined it.
I'm surprised there's an online component to that. I've never seen such a device in real life but I've always assumed that these have some sort of automatic commercial break recognition and that such features were first introduced way back in the 90s when requiring an internet connection was impractical to say the least.
Adversarial interoperability works well for this. Facebook did it in its early days — it let you connect your account on then-popular competing social media website (MySpace, probably, I don't remember for sure) and would import your social graph and crosspost on your behalf.
You mean you used to be able to just send a bag without flying yourself, and have someone else pick it up at the destination airport? Was this something that people did intentionally or did it happen accidentally?
I'm pretty sure that they are loading before the gates open. If my memory isn't entirely gone, I recall watching them load luggage while waiting at the gate for the cleaners to finish.
I've never heard of this happening, and I'm skeptical. I fly a decent amount and my luggage gets misplaced likely in the low percents (more than 1%, less than 5%). I struggle to believe they'll be aware enough to unload a full cargo compartment.
But I could be wrong. Maybe it's just rare enough that I haven't run into it. I would expect it would delay the flight by a noticeable amount. And it would be fairly obvious that they're unloading luggage and then reloading it. It's not like they can just send someone in to climb around and find it. They pack them in tight.
Yeah, I meant doing that intentionally to send something to someone else for the cost of flight without having to wait days for shipping. Could you even get to the baggage claim area of an airport pre-9/11 without having flown into it?
> I meant doing that intentionally to send something to someone else
Someone told me they'd done that in the 70s. In their case, they were planning to travel and bring along stuff that belonged to a friend at their destination. At the last minute, they couldn't make the trip and they decided the easiest solution was to check the bags and scurry out of the airport. They were worried the airline would deny a refund, but they got their money back just fine.
Baggage claim was no problem. Anybody could (and mostly still can) access it. I remember a time where they kind of corralled it all in and checked your bag tag and stub to make sure you weren't wandering off with someone else's luggage. That was a chaotic, ineffective, and short-lived effort.
I wouldn't say false especially when quoting the whole sentence. What you suggest is so rare (worldwide) it might as well be false. It's such a bad idea for the airline to ship your bags before the passenger makes it onto the plane.
Running code by itself isn't that bad, it's the fact that browser developers have decided for some reason that this code needs to be as performant as possible, so, JIT.
I don't get it! The way JS is typically used, it doesn't even benefit from JIT all that much. Making ajax requests, doing stuff with strings, and moving DOM elements around doesn't need every CPU clock cycle to be used as optimally as possible. It's exceedingly rare for websites to actually be doing something that needs raw performance. And SPAs will be slow no matter what.
I disagree about JIT performance not mattering. I enabled "Lockdown Mode" on iOS which disables the JIT for the mentioned security reasons, and it causes a very noticeable lagginess on many sites. Of course, the primary cause is the unnecessary JS monstrosities wasting CPU cycles. But practically speaking I can say that disabling the JIT results in a very subpar experience of many JS heavy pages.
That's largely because a lot of developers have made the devil's bargain of replacing standard web stuff with badly re-implemented JS versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stuff, JIT wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like V8 and Node appeared, JS became ubiquitous. Pandora's container, if you will.
> See most of the ecosystem around React, for reference.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.
The DOM is the slowest part of the browser. It's not Javascript, it's the DOM. React is an attempt to manage the slowness of the DOM. One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.
With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser developers. HTML/CSS/JS is a very powerful system, but it's also complex and can cost a lot of compute. When you understand this, then the reasons for React and other front-end frameworks become easier to accept.
> One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.
I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalculated, potentially going up the tree as necessary. The only exception is if your script tries to get any layout-related property, e.g. offsetWidth. Then, as if as part of the getter of such a property, the layout recalculation will run immediately.
That is to say, if you need to make a lot of changes to the DOM, you should make them within one JS invocation so only one layout pass happens sometime after you're done.
OP here. The steel-man argument for React is not that it is faster at rendering. It cannot be, because it ultimately relies on the same DOM that everyone else does to do the job, and it has to set up a massive JS data structure to do what it does, which uses a lot of memory and has big GC costs. Arguments that assert that the React virtual DOM are faster than the native/shadow DOM are simply wrong [1]. Even the React team admits this [2] (though back in the day, they made a number of puffed-up claims about speed that never made sense).
The principle argument in favor of React today are developer ergonomics. People don't have to manually alter individual elements anymore -- they just describe state, and React takes care of the UI change set. On top of that, you have components, etc., that are debatably more pleasant to work with, and at the least create an ecosystem advantage for users of the framework. One can certainly see the argument for something like facebook, where there are probably dozens of different things changing independently at any given time.
But that said, one really has to question whether React makes sense anymore, given LLMs. Back when the alternative was that someone had to bespoke code every UI component, it might have been worth taking the hit of having to adopt the entire React ecosystem. But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
[1] Though sadly, many front-end devs don't know this.
Well, I'm an old-school guy. I'm all for developer ergonomics, as long as they don't affect the runtime. I use PostCSS and TypeScript in my own projects precisely for this reason, because they both make things more convenient for me yet leave no trace in the finished product that the users see.
> But now that LLMs are writing the code
Hopefully that's a temporary state of affairs and everyone will eventually go back to writing code by hand. I've never even considered using an LLM to get my job done, the whole idea is as alien to me as are these types of UI frameworks. To me, the best language to describe what you want from a computer isn't English, it's a programming language.
>But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
The popular coding AIs go down all the time. Last week all of them were down at the same time. If there's a bug causing losses of thousands or millions of dollars per minute, do we really want to let the LLM write incomprehensible code?
You may not need react. If you want to make the smallest possible change to the dom to reduce latency, then make the smallest possible change to the dom. Choose solidjs. (Not a sponsored post).
> Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
It's so that you have the page reflecting your data at all times.
The browsers should have been written this way, instead of having byzantine update functions with all forms and a pair of *Text to rule them all. But creating it in Javascript is a really bad idea.
The problem is not url management. That should happen just once or twice during the life cycle of a page. If it takes 0.1ms or 1ms doesn't have any impact on the usability.
One of my problems was that I wanted to show data in the browser. It is a convenient delivery platform, after all. However, Chrome (and Chrome in particular) has tremendous trouble displaying large pages. A 400x400 table takes a long time to render. I could solve that in JavaScript. I had to, really.
So, as practically always, the problems stem from a combination of factors, and bad programming definitely is one of them.
That's largely because a lot of developers have made the devil's bargain of replacing standard hardware and OS primitives with badly re-implemented C versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like compilers and standard libraries appeared, C became ubiquitous. Pandora's container, if you will.
> It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
Cute, but no, not even close to a good metaphor. The C example is abstracting away fundamental complexity in a new platform. The other is completely re-writing -- in duplicate and slightly broken -- what the platform gives you for free. There's nothing about implementing form controls or URL management in JS that is more abstract. It's just different; a downstream bad decision that branches off a long tree of other bad decisions.
The equivalent level of idiocy in a C-related metaphor would be...I dunno...if you decided that you didn't like the way that header files worked, and decided to keep the C compiler, but build an external header-file management system in Fortran [1] that calls the C compiler for you. Or even closer to the JS metaphor, you shipped a special C compiler that had an embedded interpreted language that only activated at compile time, and you then used that language to allow any user to fundamentally change the syntax of C.
(It hopefully shouldn't be lost on you that this exact approach to language features has been repeatedly tried in the javascript world, including right now, with package management. But see also: typescript, coffeescript before that, Dart, etc. Javascript is a mess, and history repeats itself with regularity about every 5 years.)
[1] ...and then you re-write that about sixty times, each time being slightly incompatible with the last, and all having different fundamental incompatibilities with C headers.
Sites are slow because with all that excess performance they do more tracking, instead of keeping the website as-is.
Because that's the only thing business managers can come up with in that situation. It's a misaligned goal of users vs businesses.
In my opinion the "user agent" behavior of browsers is long gone, because they're not acting on behalf of their users anymore. They're acting on behalf of businesses.
I suspect the people who agree to buy Jira & Confluence are not particularly heavy users of them. At least, that's the only explanation I can fathom for their continued sales.
I've never seen an SPA which scales properly and doesn't become a bloated mess, maybe that's possible but it's definitely harder to make it work than using traditional server side template rendering
I don't only mean "scale" in terms of users but also scale in terms of features.
So you have to guarantee that your product will stay low users and low features forever or spend a very high effort to try to partially overcome that block when you change your mind.
And guaranteeing that it will stay low features is much harder than low users I think.
In exchange for that you get a better talent pool for recruiting but does that matter if your product has to stay low scale anyways?
Or you have to distribute your code in such a fashion, and structure your business model in such a way, that “scale” doesn’t require you doing things that have nothing to do with providing the feature set (most SaaS).
I'm currently working on a SaaS at my company and we have a lot of issues because of the SPA, I estimate we spend around 5% at least, maybe 10% of the workforce just on SPA complexity.
It can work for some SaaS but if you stay low employee count, low users and you have a core feature used everywhere in the whole product and nothing else
I don't have a final opinion on the subject, it's just the results I witnessed after a long time in the industry. The ones I've seen with Angular suffered from the same issues.
I'm sure counter examples of well managed SPAs do exist somewhere, it's just that it seems much easier to do the wrong thing compared to a traditional stack. This is why I'd not advise for it unless you have a very good reason.
The good stacks should make the good choices the natural way to do things, again my opinion.
At this point SPA pretty much implies React. But even if you optimize everything the best you could and avoid any third-party runtime dependencies, it's still going to be significantly more work to make API requests and do client-side rendering vs just rendering HTML server-side.
Not always. Consider an SPA that connects via WebSockets and streams in data, adding points to a chart. The JS-less alternative would be refreshing an SVG or even the whole page once a second. The SPA is clearly more efficient here (unless someone screws it up badly).
I wouldn't consider that an SPA at all, it's just a page with an interactive element. An SPA is something that renders everything client-side and uses a generic client API to talk to the backend. A telltale sign of an SPA is that the first thing you see when you open it is some sort of loading indicator instead of the actual page you're visiting.
Right but the implication of a SPA is that it’s an application which has many logical pages, but only one real page. The logical pages are constructed by dynamically updating the DOM using JavaScript. As opposed to navigating to a new, server-provided page.
For example, a search function. For a MPA, each search query would be a new page. For a SPA, each query is a new logical page, served on the same real page.
Technically yes, a SPA may have minimal client side rendering. But then it’s not doing much of anything at all - it’s just a site. When people say SPA, they typically mean an application with client side rendering.
This reply means basically nothing to me or anyone.
To expand on what I mean, if the implication isn’t obvious: a SPA with no client side rendering is just a single HTML page. It’s a document, not an application.
So SPA naturally implies client side rendering.
The difference between a SPA and MPA isn’t the amount of pages, they both have about the same amount of logic pages. It’s about where those pages are rendered. Dynamically on the front end, or on the back end.
EDIT: okay okay to expand, my website has a contact form. With JS enabled, the form submit displays a little box that says “thank you for submitting”. With JS disabled, it navigates you to a “thank you for submitting” page.
Both are the same logic page, they have the same function. One page is just rendered client side, and one server side. Most websites or applications are hybrids. There’s very few true single page applications, and very few true multi page applications. Most SPAs have multiple real pages for different things. Most MPAs combine multiple logic pages into one real page.
The features of HTML are still greatly limited. You can’t really create applications with just one HTML page and no client-side rendering. You can play a video, sure, but that’s not an application. You can also do magic with CSS but that’s an experimental fun thing, not a thing people actually do.
As soon as you, say, use JS to update the DOM or a canvas, I consider that client-side rendering. That you can do, and that would be a SPA.
But I’m curious, what are some examples, even hypothetical, of applications consisting of one HTML page? I don’t think I’ve ever seen it.
CSS (.css)
JavaScript (.js)
Plain Text (.txt)
HTML (.html)
SVG (.svg)
Raster Images (.png, .jpg, .jpeg, .gif, .webp, .bmp)
Audio (.mp3, .wav, .ogg)
Video (.mp4, .webm)
JSON (.json)
PDF (.pdf)
plus bring in other source resources as needed.
To answer your question:
The installer for GrapheneOS / Google Pixel phones is an “SPA” (or “webapp”).
I’ve seen bespoke fitness trackers of all kinds,
appliance control apps,
budget and pace-tracking stuff,
basically all of what computer programs used to do - before we started dynamically loading a ton of extra stuff onto the screen that nobody needed to do the task they came to do.
Right, but if you’re dynamically changing the HTML from JS, like the graphemeos website does, then that’s client-side rendering, which is my whole argument. Embedding the JS in HTML makes zero difference, it’s the same thing.
So, they are truly inseparable IMO. You can’t have a SPA without some amount of client side rendering, your example demonstrates that. So, what makes a SPA a SPA is the rendering. A SPA is “single page”, but only in literal meaning. Logically, every SPA is many pages, you just render them purely client-side.
By that definition, Smithereen, my fediverse server software, is also an SPA, since it does what I call "ajax navigation" on desktop, so that the notifications websocket doesn't get disconnected and reconnected every time you click a link. It's technically a single page that gets most of its content replaced at runtime when you click a link, after all, right?
It's one of those technologies that makes you wonder what would've happened if they just kept advancing it instead of outright replacing it with something else entirely. How tiny could cores be made? Could modern chip manufacturing techniques be used to make nano-scale core memory?
See also: vacuum tubes (there were attempts to miniaturize them to try to compete with transistors), CRT displays (there were some wild concepts like a flat-panel CRT where the gun is at the top and the beam makes a 180° turn at the bottom before it gets deflected into the screen; also late CRT TVs that had slimmer tubes).
The modern tech industry is fundamentally broken, the incentive structure is wrong. No one even knows how to ship finished software any more. Everything's a perpetual beta now. It makes me really sad.
The Cloudflare captcha checkbox fingerprints the crap out of your browser. It's an opaque risk-based thing, which is the worst. Anubis just makes your browser brute force hashes, that's it.
I'm not sure what kinds of tools do you expect. You do have to make layouts for different screen sizes, no real way around that. You'd usually want two breakpoints, so you have phones, small tablets (and foldable inner screens), and large tablets.
reply