So after years of being gleefully told that AI will replace all jobs an omniscient state of the art model, with heavy assistance, takes more than two weeks and thousands of dollars in tokens to do what child me did in a few days? Huh.
I used to think the same until latest agents started adding perfectly fine features to a large existing react app with just basic input (in English) . Most of the jobs require levels of intelligence below that. It's just a matter of time before agents get to that.
I disagree - having worked on backends most of the time, I find modern frontend much more complex (and difficult to test) than pure backend. When I say modern frontend - its mostly React, state management like Redux, Zustand, Router framework like React Router, a CSS framework like Tailwind and component framework like Shadcn. Not to mention different versions of React, different ways of managing state, animation/transitions etc. And on top of that the ever increasing complex quirks in the codebase still needed to be compatible with all the modern browsers and device sizes/orientation out there.
> When I say modern frontend - its mostly React, state management like Redux, Zustand, Router framework like React Router, a CSS framework like Tailwind and component framework like Shadcn
AI is the best at adding standard things into standard boilerplate situations, all those frameworks just makes it easier for AI. They also make it easier for humans once you know them and have seen examples, that is why they exist, once you know those frontend is not hard.
Actual complexity depends is not imposed by the framework, but by the application itself, and the amount of front-end logic tends to be lower. Yes, there is more complexity in the setup of front end code (now there are dependencies and build pipelines), but ultimately they should simplofy things especially for slighly more complex websites.
Testing is one of the things that's generally tedious in front end applications, but not inherently complex. There may be lots of config needed (e.g. for setting up and controlling a headless browser), and long turnarounds because tests are slow and shaky. But they are also boilerplatey.
That's just a farmiliarity thing. I've worked on project doing full web FE, mobile and BE.
It's hard to generalize but modern frontend is very good at isolating you from dealing with complex state machine states and you're dealing with single user/limited concurrency. It's usually easy to find all references/usecases for something.
Most modern backend is building consistent distributed state machines, you need to cover all the edge cases, deal with concurrency, different clients/contracts etc. I would say getting BE right (beyond simple CRUD) is going to be hard for LLM simply because the context is usually wider and hard to compress/isolate.
>Most modern backend is building consistent distributed state machines, you need to cover all the edge cases, deal with concurrency, different clients/contracts etc. I would say getting BE right (beyond simple CRUD) is going to be hard for LLM simply because the context is usually wider and hard to compress/isolate.
Seeing the kind of complexity that agents (not standalone llm) are able to navigate - I can only start to believe - just a matter of time it can do all kinds of programming, including state of the art backend programming - even writing a database on its own - good thing with backend is its easily testable and if there is documentation that a developer can read and comprehend - an llm/agent would be able to do that - not very far from today.
Isn’t frontend more complex? If my task starts with a Figma UI design, how well does a code agent do at generating working code that looks right, and iterate on it (presuming some browser MCP)? Some automated tests seem enough for an genetic loop on backend.
>Isn’t frontend more complex? If my task starts with a Figma UI design, how well does a code agent do at generating working code that looks right, and iterate on it (presuming some browser MCP)? Some automated tests seem enough for an genetic loop on backend.
Haven't tried a Figma design, but i built an internal tool entirely via instructions to agent. The kind of work I could easily quote 3 weeks previously.
Training data is quite readily available as well, and the online education for React is immense in volume. Where enterprise backend software tends to be closed source and unavailable, and there's much less good advice online for how to build with say Java or .NET
That said, I still get surprising results from time to time, it just takes a lot more curation and handholding.
Or perhaps the sort of things it's been trained on? There's not really a huge corpus of material re: beating Pokemon in the manner it has to play Pokemon, especially compared to the mountains of code these models have access to.
Yes and no. <table> layouts were a hack that solved a real problem but came with massive downsides. People didn’t tell you to not use <table> to lay out content because grids are bad (they are quite handy! take a look at Grid Systems by Josef Müller-Brockmann) but because <table> both posed technical and accessibility problems. A layout grid is not a table (or a <table
>). A table (with and without <>) comes with attached semantics, hierarchy, reading direction etc. and is extremely rigid, which makes it a bad fit for differing screen sizes.
It’s true that this was a blind spot for a long time and that it was frustrating to not be able to efficiently lay out content in 2D when <table> was just there. But it was the wrong choice then as it is now and it has been baseline available for 8 years now. I hope it won’t take another 8 years until the comparison stops :o)
They don't! Layout grids are less about the rows and columns and more about the lines separating them (which is why those get a lot of attention in CSS grid). Take a look at how layout grids are used in design and you will quickly find examples that are extremely inconvenient to realize with HTML tables. I'm sure it can be done and I'm sure some poor email marketing dev had to, but the result would be entirely static and not able to reflow.
You have just restated the similarity I referred to. The ways they are different make them important enough to distinguish.
“Tabulate” doesn’t just mean organising anything by rows and columns, it means organising data for a particular purpose. And layout grids usually end up looking quite different to tables because although they have a broadly similar underlying structure, the purpose is quite different.
They're not quite deprecated, but they're also not quite not deprecated at all:
> Historically, the <b> element was meant to make text boldface. Styling information has been deprecated since HTML4, so the meaning of the <b> element has been changed.
I think CSS grid is too powerful to be represented in markup. I rotated the idea in my head for a bit but the most I could come up was elements that covered a small subset of CSS grid and which completely lost the entire appeal of being able to handle tracks dynamically.
This is a classic problem I identify across a wide variety of types of software. I call it "forcing a graph into a tree" and it comes up any time you have something that must be evaluated across multiple axises but the earliest assumptions (now invalidated) about the data restricted it to a tree, or the most really available tools to process it is with tree-like data structures and algorithms.
HTML is a tree. It's really great at trees. But defining a grid layout sometimes requires organizing data by both the rows and the columns. That can't fit into a tree.
I think a lot of people's complaints that "CSS is too complex, why can't we just do this in HTML" would go away if they could understand that CSS--being a rules-based system--can process the graph, but HTML can only ever define a tree. There are things that will just never work in just HTML.
This gets hard because trees are easy for people to understand. We have lots of examples of them: file systems (if you ignore symlinks). Family trees (if you ignore inbreeding). Tree of life taxonomies (if you ignore more than basic undergrad biology). You can probably guess by my caveats how much I feel it is important to study graphs. But graphs are "scary Computer Science" stuff to a lot of people, so they don't take the time to learn.
That also could have been from the phone manufacturer OR from the carrier.
This is why I've avoided non Pixel phones since the Pixel5 came out. None of that 2 or 3 apps for the same thing so everybody can get their ad cut payout.
Whenever I'm forced to help with iPhones, I'm baffled how hard everything is. And I had my own iPhones previously. Download a file, unpack it and open in an app is an exercise is frustration, and that's just hoping that I will find the file due it being newest. Working with directories and old files properly, like on Android, I'm not sure if its even possible on iOS. And all that with a crappy keyboard with hidden numbers and special symbols, making searching even harder.
I love Android but Android does that too. Apps have their internal storage area which you can't access unfortunately (not without root anyway). Nor system files.
There's a difference between "can't see 'special' folders" & "can't access anything but the app-specific storage". iOS loves the latter, while Android lets you organize files mostly normally even if doing highly stupid/discouraging things for power users & some app developers making questionable non-default choices.
The history lesson is appreciated but how does this relate to the current state of the stock file explorer that ships with the OS? I’m using my phone now and not ten years ago.
edit: oh, I think I get it. My original post wasn't intended to be read "iOS invented the file explorer, has Android also a file explorer app" (which would be silly, of course) but "when Files app released, the AOSP file explorer that commonly ships as the default was lacking, has this improved (caught up to Files app)"
When I had an iPhone (a few months ago), there was no way for apps to see files in the filesystem. I wanted to play some music and I had to copy it over to each of the music player apps separately. Is that not the case any more?
Am I supposed to be mad about them not supporting a feature during a time when I didn’t use iOS or is this somehow supposed to impact my current day use of Files app?
Try connecting to a WebDAV server on File. It's possible but it's shitty. And try using Syncthing on iOS to keep your files synced across devices without having them uploaded to servers you don't control.
Also, on Android, you can choose any file explorer. You're stuck with Files and it sucks (but it looks nice).
The one major issue is that it doesn’t work inside other apps. If I save something in Word, it pops up the standard File dialog and every storage provider available for my iOS device - Dropbox, OneDrive, Google Drive, iCloud Drive, local storage, network drives, and locally connected mass storage devices are available.
I can only navigate to a video by long-pressing, copying the URL and pasting it into the URL bar, otherwise I get a meaningless "something went wrong" type error message. Mobile Safari, no content blockers, not logged into a Google account. After almost two decades of making the website worse they finally succeeded in breaking "clicking a video". I wonder what the hotshots at Alphabet manage to break next :o)
This was happening to me browsing in FF with uBO. It would work as soon as I disabled uBO. I realized uBO needed an update, and it went back to working with uBO active after the update. For a couple of hours I was ready to never use YT again if it meant suffering their obnoxious interruptions with ads.
Suspicion: they’ve fingerprinted me hard and know I have premium but like to watch occasionally from Safari private (with content blockers) and don’t hassle me.
Mainly suspect this given lack of anti-adblocking symptoms.
If platinum-rated, should run fine with latest Proton, and maybe also some environment variables on launch to force using the dedicated GPU. Assuming the kernel and drivers are up-to-date.
Every frog will be boiled. Remember this when you argue “oh but it will still be possible to sideload via adb” “oh but you can turn it off” “oh but you only need it on the first run” “at least they don’t…”
You won’t be able to. It will be mandatory. They will do it. If you give these companies an inch, they’ll take a mile.
The moment they don’t actively work entirely aligned with your interests, they work against you.
Trying and doing aren’t the same thing. I’ll take competent community members over incompetent leadership any day of the week. And I am right to think so, seeing how they entirely bungled even kicking out the people they wanted kicked out. They literally had their first security incident at second zero of their attempt to “bring security up to this decade”.
reply