The next thing in user interfaces is combining LLMs with GUIs to create a flexible interface that isn't fully defined in advance but works with the user to adapt to their needs. This is a total departure from the pixel-copying design methods we have today and there is no tooling yet for designing such an interface.

In a few years time, we'll expect all applications to have LLM inputs and full natural language understanding in addition to their menus and buttons, just like we expect all software today to make use of the internet where before, none did.

> combining LLMs with GUIs to create a flexible interface that isn't fully defined in advance but works with the user to adapt to their needs

I doubt this. Or, I doubt that it'll catch on.

Unlearnable UIs, as in those that 'adapt' to a user's needs (meaning change unpredictably) will just confuse and put off users.

LLMs being wrong at least enough of the time to make you not trust their output also makes me doubt this style of interface.

Nothing says it has to be unlearnable or change at whim. Imagine your bank's website allowing you to say "show me what I earned from Wilco last year" and have it make the UI selections to achieve this.

We will absolutely see these type of interfaces. Imagine how much Photoshop could be improved if you could simply ask to surface the tool you need instead of rearranging the interface yourself and hunting things down. Just like we expect apps now to be able to use the net, not just info on our own machines.

You can already ask ChatGPT about many interfaces in popular software and it will give you step by step instructions for nearly any scenario. Soon, apps will integrate the understanding with the button and menu selections and offer to do it for you.

I think we will see more frameworks that uses only ES modules and don't new a bundler/compile step, improving a lot the dev experience.

I hope in the future we have more of flutter and flutter like frameworks and less of the web, it'd be a little more cost effective as it'd reduce server costs and it'd lessen the effect of cloud companies on climate change.

The next big step in the web will be economic. It has gotten far too expensive.

Back when I started learning this stuff the idea was for ignorant moms and pops to quickly markup some text to create web pages. Now you need a mountain of technology thousands of times larger and more complex than people putting people on the moon just to put text on screen using layers of unnecessary bullshit like Next and React. WTF?

It’s only a matter of time before absolutely everyone, except for web developers, start looking at alternatives. Seriously, if the only goals are putting text on screen and handling user interactions both employers, hobbyists, and moms/pops going to consider anything else that costs less a million per year, minimum, for a technology team who delivers so incredibly slowly.

> It’s only a matter of time before absolutely everyone, except for web developers, start looking at alternatives.

Wait a minute? This has already happened. Most real people and small businesses publish their stuff on social media or do their business on huge platforms. The old school web is the exception nowadays.

Do you have any such "alternatives" in mind, apart from Desktop GUI software?

I would imagine a new medium that directly competes with the web. The competition/replace will most likely occur unintentionally, which likely means some existing technology will gain some new feature that does one thing and yet just happens to do it better than they web. If this is what happens then it will be unexpected and not well predicted.

I say it will be unexpected because all the incumbents are utterly reliant upon ad fueled data hoarding for their revenue. Anything better would be massively disruptive economically. Pablo wasn't about to give up cocaine just because rebels were taking over his country. He had to be killed, by surprise.

However, if I were going to intentionally replace the web I would do so around these features:

* Prioritize around streaming sockets. Use something like HTTP as a fallback when everything else has gone to shit, as a security policy allows. HTTP is session-less. Socket first communications will allow must faster full stack interaction, greater security, and ad hoc authentication without all the bullshit of OAuth or SAML.

* Force TLS on everybody all the time without exception, but not rely on certificate authority madness. If you have authentication builtin by default, because everything is socket first, then the certificate madness is only necessary to compensate for the guessing at trust or unknown external parties.

* Abandon HTML and use markdown instead. HTML is mostly simple, and yet nobody can seem to figure out accessibility, semantics, or basic content organization. It has to go.

* Use a new programming language to replace JavaScript. There are several absolutely tremendously amazing things JavaScript got so completely correct, and yet most people who write that for a living will never figure it out. The next language must be single paradigm, strongly typed, and never forgiving. It should retain lexical scope and functions as first-class citizens. It should eliminate access to inheritance outside of custom extensions to the language/environment and should eliminate unintentional type coercion. It would also be nice to have procedures (blocks) that can be assigned to variables and reused without the overhead of a function, and that would also eliminate the gap between declarative and imperative programming styles. Sometimes people deserve to fail, and that concept has worked well for Rust. Its not about what's easy for illiterate people who shouldn't be in that line of work in the first place, but instead what allows rapid prototyping at minimal expense and minimal overhead.

* Pages/documents should eliminate calls to resources outside of the page's serving domain. Third party asset requests, especially script logic, is just a shitty excuse to transfer the cost of privacy/security violations to the user wholesale at no cost/liability to the server, and that's bullshit.

* Allow coupling of media types with codecs and media container support. When that is offloaded to a transport mechanism you don't have to worry about bullshit like iOS media restrictions so that they can entice you to spend money on their app store and iTunes bullshit.

The next big step is dependent on JS language/runtime features. Specifically the Record-Tuple proposal (https://github.com/tc39/proposal-record-tuple)

TL;DR: It's a way to designate data as being immutable.

JS doesn't currently have a good way to do this, so everything built for it tries to assume that data hasn't changed since it was last set. This leads to headaches for developers and wasted cycles for runtimes.

When JS has a proper way to make data immutable, it makes it easier for libraries/frameworks to make guarantees about the underlying data and makes it possible for runtimes to better optimize code.

I wish Web App could be built in one single language as I despise JS. But for that, browsers need to be created differently.