The state and future of web dev: your vision, wishes and celebrations

One thing that is trying to change that is Deno but I haven’t even tried it.

Yes! I looked at Deno and played with Fresh and Aleph.js (the later was more to my liking) over Christmas break, and indeed this is heading towards the same direction.

Deno is also a Node.js-free environment based on V8, and that’s another trend - for Next.js you can also deploy it over pure V8. You still need Node.js to build it, but can decide on page-by-page basis which runtime (Node.js or V8) the whole thing runs on the server. And, according to my tests, V8 is significantly faster too.

1 Like

Another interesting thing I read about Deno is it can build your project as snapshot so startup time is really fast.

1 Like

I can’t find anything about it. Can you send me a link? My google-fu fails me.

They are calls v8 snapshot and it’s a feature of V8 itself. Can’t remember actually did I read about it or did I listen to a Deno developer interview. I didn’t dig deep but found this from 2018. Could it be that they currently only use snapshot for TypeScript and libdeno compilation?

This is interesting and very exciting indeed. The next step I guess would be to provide a snapshot with JIT already pre-trained somehow so that there’s no “warmup” although I believe V8 is doing an excellent job here already.

That circles back to OP’s questions, I feel.

A common classification these days is that something is either:

  • A library / micro-framework / collection of tools, where you assemble your app and its components together yourself.
  • A full-blown framework where file structure, building data and UI flows, making releases, talking to a DB etc. are going well as long as you comply with the conventions.

There’s a spectrum here but it’s not a wide one. You usually can categorize the technology in question to either of the above fairly easily.

1 Like

So far I’ve seen that the new “JavaScript Frameworks” are not shipping with a DB access layer, instead there may or may not be data-fetching layer, as in making API requests to the backend. This is probably a good thing too, as I’d prefer my data to be handled by something other than JavaScript, up until the moment when it’s in the need of being displayed to the end user. This still leaves the space for reliable and robust backends to be written in, let’s say, Elixir + Phoenix + Ecto.

Something completely different.

What are your predictions about how people will interface with the web in the future. Five years from now. Ten years from now. And beyond.

As mentioned before, browsers are still hugely popular. I catch myself using Word Online over the desktop version all the time. And as a teacher me and my colleagues also use online tools very often. Desktop apps less than before. PowerPoint is getting used less, in favor of web apps.

On the other hand, some large companies are investing astronomical amounts of money into VR/AR. What does that potentially mean for the web and the browser as a medium?

And Siri, Alexa, and their friends, are getting smarter. I don’t like using them… yet. Have my doubts I will in the future, but who knows.

Don’t have kids that age, but wonder if younger generations find it natural to “converse” with them. Or at least, give them orders. Instead of whipping out their phones… if they have one.

In other words. Will browsers ever become marginalized?

Or maybe better: “when”?"

I think companies like Google will do this at the first opportunity they get. Since their company operates on tracking and fingerprinting their users, the non-tracking enforcement that nowadays becomes more widespread in browsers will kill their ads business slowly, and they will try to push a different technology to the market.

1 Like

It is a sad thing that web applications are killing off cross-platform GUI applications. Single platform native GUI applications will always have their place because of speed and user experience; however, things like Qt, wxWindows, or Java/Swing are having an existence crisis now.


Said push is already under way :slight_smile:


Indeed. Even things that were traditionally reserved for OSes like Qnx, and only more recently Linux, where reliability is a key feature that you cannot do without. For example, SpaceX UIs in the Dragon capsule are Chromium and JavaScript based: JavaScript Reaches the Final Frontier: Space

Headed - Don’t attempt to build generic cross platform tools for desktop, Android, ios, and browser, use native tools for each. For web front ends, I would stay with spa’s, but keep accelerating how fast it is to implement rest/graphql clients and accelerate adoption of static types with elm/rescript/etc. I would use more web sockets and pages with real time updates. For back ends, I would want to keep moving towards strong type systems like rust and haskell. I also like the descendants of heroku for simple deployments.

Why - I think attempts at building one tool to create all front ends are overly complex and result in bad experiences for each platform. I like spa’s because they provide a clean separation between rendering and navigation and data retrieval/updates. I don’t see much gain from server rendering, beyond people who want to avoid implementing an API. I like stronger typing to be able to refactor faster.

Shortcomings - js ecosystem creates busy work keeping up with constant churn and identifying and avoiding bugs in libraries. I think elm solves this. There is a lot of effort to implement front ends for each platform, but I think that is an inherent complexity. Graphql feels a little overly complex/bloated and it feels like too much effort to avoid n+1 queries - should be something that steers you away from those by default.

Most important recent developments - growth of rust for backends speeding up adoption of strong typing, native esm to help scale SPA’s more easily, constant innovation with elm ecosystem


Thankfully LiveView Native is coming to freshen up this space!

I agree, but if you haven’t looked at LVN yet, it strikes the right balance IMO: you’ll write bespoke UI components for each platform using its native UI framework (Jetpack Compose, SwiftUI, etc).


I am very much inspired by the Fediverse. You may have heard of Mastodon, which is a Twitter-like microblogging app and decentralized instances form an ever growing social network. But Mastodon is based on the W3C ActivityPub specification, a standards-based approach to create any type of social networking system and interoperate with other systems.

If you consider our Web 2.0 it is full of interactive multi-user platforms. They are packaged applications, and are like silo’s locking people in. If you consider people collaborating online, this happens on some socio-technical system. Thinking further and considering the Fediverse, we can go much further than what Social Media have to offer us, and we come into “social networking”. This is what humans do for 1,000’s of years and we now also do online. And ideally our online activity fits seamlessly with our day-to-day activity.

What is possible with the Fediverse, that currently exists of many different apps, is to move onto a new paradigm of app-free computing (a term coined by Chris Gebhardt) where social experiences are composed by the services anyone offers on the Fediverse. This is task-oriented, whereby people create tailored social graphs and engage in personal social networking. From social perspective I call this a Peopleverse.

Erlang/Elixir is a perfect fit in this technology vision. ActivityPub is an actor-based protocol with similarities to how email works with inboxes and outboxes where actors exchange messages. These messages are Linked Data (JSON-LD) and you can define your own vocabulary extensions to the protocol to model your particular domain, e.g. Podcasting or Blogging. All decentralized, open to anyone.

A particularly interesting field is in forge federation. MS Github is the forge platform for millions of developers. It is also increasingly a walled garden, locking people in by the portfolio of services they consume. There are alternative forges, such as Gitea and Sourcehut that can be self-hosted. But people can’t find them easily, and there’s network effects and FOMO keeping people on Github. Now ForgeFed is an ActivityPub vocabulary extension specification that can change all that, and Forgejo and Codeberg (running on Forgejo) will add federation support.

In the new paradigm of app-free computing it is not just different code forge server instances that will federate, i.e. on an application silo level, but the actual processes will federate. Federated Free Software development that covers the entire software lifecycle! Software development deeply tied to decentralized social networking.

This vision is possible. Many people got their eyes opened to how Social Media can be different, after moving away from Twitter, and delighted by the current Fediverse. They may realize the full potential of decentralized social networking. Yet it is a challenge that requires massive collaboration and co-creation in a grassroots movement. As a final inspiration to this vision I drop this thought-provoking article by Robin Berjon:

Update: Since this is on the Phoenix Forum category… how does Phoenix fit into this? When conducting social experience design (SX) and composing federated services into task-oriented solutions, there’s a similar composition need for the UX/UI each of these building blocks provide.

How do we nowadays work on the web? Well, we have numerous different apps with radical different UI’s and they don’t integrate much. We context-switch and copy/paste significant amount of time. There are standards for composable UI’s, like Web Components and new ones like Block Protocol. Phoenix Liveview does components really well, and better in each new release.

Where I’d love to see UX/UI going is into new directions, out of familiar ways and exploring creative possiblities. Here I am most inspired by people like Bret Victor and radical UI design prototypes such as MercuryOS.


As for the current shortcomings, one area that needs improvement is web security. With the increasing number of cyber threats, robust security measures are crucial. Additionally, some websites still struggle with accessibility issues, which need to be addressed for inclusivity.