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.
D4no0
derek-zhou
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.
5
mcrumm
Phoenix Core Team
hubertlepicki
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 - InfoQ
0
kanishka
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
3
mayel
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).
2
brownerd
aschrijver
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.
2
nathandiaz
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.
3
D4no0
While performance is also a important factor, I think accessibility is a huge concern these days that got to the point that it needs to be addressed.
There is a huge number of sites that are broken on mobile, and because they don’t rely on proper mechanism to decide which version(mobile or desktop) to deliver but on the screen size, it’s impossible to switch to desktop version to temporarily overcome those issues. It got to the point that my business internet banking site suffers from these issues and I had to find a notebook to be able to perform the operations I needed.
I think that there was some people on the forum that were trying to bring some component libraries to phoenix that respect accessibility standards, but I’m not sure they succeeded.
1