I wholeheartedly agree. I have some hope in full-stack efforts such as Redwood and create-t3-app, and maybe Blitz tools. But I've come to the point I can't see a decent full-stack solution that isn't based on JS, since it's a necessity on clients, as @ryansolid mentions.
I would probably use SolidStart for all my projects, if it weren't for the desire to make a cross-platform app that also runs on native (without duplicating the code and effort). So I'm left with React, as it enables React Native Web.
But if SolidStart had a native story, with an integrated setup, something akin to Hotwire Turbo (but maybe more like React Native Turbolinks, so I never have to touch Swift or Java, even if customising the nav bar) that would by default be set up to enable native iOS Safari push notifications, plus maybe in-built shared element transitions, then I would love to choose SolidStart. Just for the fact that I would for the most part avoid the native ecosystem: separate build and release pipeline, App Stores, and whatnot. Only important thing would be that the React Native Turbolinks shell app had enough native features not to get thrown out of the App Store, even though it wrapped a SolidStart PWA.
The more obvious answer for SolidStart's native story would perhaps be CapacitorJS. But the caveat (and dirty little secret) there is that it actually bundles your PWA and ships it with the App Store bundle. Although I've read you could also use CapacitorJS to ship the App Store bundle with a WebView so that the PWA would always be served fresh. With the aforementioned risk. So only as long as the shell app had enough native features (something besides just notifications I have learned, preferably at least some navigation nav bar, like React Native Turbolinks and Hotwire Turbo has) to get past App Store review process.
if it weren't for the desire to make a cross-platform app that also runs on native (without duplicating the code and effort). So I'm left with React, as it enables React Native Web.
The thing is—from the commercial perspective I can understand the appeal of the "cross-platform" approach but from an engineering perspective "cross-platform" is an immediate compromise towards sub-mediocre outcomes because it leaves you in a postion where you cannot optimize for any platform without heavily penalizing the others.
And React/Native demonstrates this beautifully. Look at how much bloat Preact got rid of, compared to React, by not having to support native while preserving "declarative UI" and DX. And look at the rings that Inferno runs around React because it doesn't have to support native.
So my attitude is:
If you need native features that the web can't deliver commit to native and deliver the best you can that way.
If you need the web's reach and universal access then commit to the web and deliver the most appropriate solution approach there.
A compromise is just going to leave everybody unhappy. Commit to the approach that is going to generate the most value.
The thing you have to have (JS) will eventually eat up all the competing things you would like to have (Ruby etc.).
That's a very personal perspective. I remember tossing Dave Thomas's Programming Ruby (2005) across the room because it made no sense to my C/C++/C#/Java/SQL/PLSQL brain at the time. Similarly JavaScript didn't jive with me either, until Clojure/Elixir/Erlang put my brain through the ringer. Once I realized the Scheme-ish tactics that were available in JavaScript I was off to the races.
For the longest time I resented that the rise of JavaScript CSR framework SSR restricted server side choice by forcing running Node and therefore JavaScript on the server. But once I realized that eBay with marko deliberately (and successfully) abandoned Java-based web development I had to reevaluate my position (and then the whole Gen 3 thing happened).
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
You cold well use PWA everywhere if it wasn't for apple's greed and users won't probably notice the difference.
The capabilities were somewhat limited but growing step by step:
Being able to use it without installing it (low-end devices, targeting many countries nowadays).
Auto upgrade (security concerns on outdated native Apps, piracy avoidance...).
Thinking about this topic, why don't just stop building "native" applications and instead add and maintain capabilities to PWA platform to unify it?
I've tried PWAs in Windows, Android and iPadOS and I've no complains. Good experiences overall.
My question is do we really need yet another platform specific language and environment just to proceed to limit it's capabilities for different concerns?
Starbucks, Aliexpress, Trivago, Android Go platform, The Washington Post, NASA... Did a case study and/or have their PWA online (some available depending on the country) but maybe Tinder and Telegram are the best examples of a company built on the top of a PWA.
The second law of thermodynamics states that in an irreversible process, entropy always increases, but thermodynamics doesn't apply to software AFAIK and we still have a chance to spread a bit of love and KISS a bit here and there.
Putting aside the "popular-culture stack" of Next.js/Tailwind CSS the popularity that tRPC is gaining is more than a little troubling and seems to once again exemplify Dave Thomas's observation:
"I think there is a horizon of maybe 7 years, 8 years that developers just don't look back beyond that, so every 7 or 8 years somebody re-invents something that already existed past that horizon"
Developer's have been trying to make RPC work since 1974 and invariably run into limitations because "to make distributed computing more like local computing" defies the laws of physics.
I guess it's one thing to use it as a more "ergonomic fetch" but I think the more likely outcome is the development of applications that are in complete denial of the constraints that the server-client-chasm will always impose on web applications.
Given the recent work on hydration and resumability the server-client-chasm is finally being appropriately addressed in terms of rendering but it seems that when it comes to post-initial-load server-client-communication the realities of the server-client-chasm are still being willfully ignored (if not by the library itself then perhaps by the developers who use it).
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I won't really say that there's a "chasm" between servers and clients, we've an infrastructure that's Internet, which is "just" a network, with it's characteristics. And we use that network to send and receive communication packages from one system to another, that's all.
I agree with:
The network is not reliable, at all
One of the key limiting factors in front-end performance, more so even than bandwidth, is latency.
Despite being less critical for general web browsing than latency, bandwidth is still a key limiting factor.
In this post but I've never heard an individual saying a single of those fallacies mentioned in it 😅 (Probably because none of them are true).
On the other hand, those infrastructure limitations affect also desktop and mobile apps as interacting with servers is as requirement (the major part nowadays).
I don't think it can beat GraphQL but this tRPC thingy seems interesting (Added to the "must try" list) thanks for sharing!
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
The main reason (I guess) is Apple not allowing full support to PWAs so you need to pay the yearly subscription to the store plus a great % of your in-app payments...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I wholeheartedly agree. I have some hope in full-stack efforts such as Redwood and create-t3-app, and maybe Blitz tools. But I've come to the point I can't see a decent full-stack solution that isn't based on JS, since it's a necessity on clients, as @ryansolid mentions.
I would probably use SolidStart for all my projects, if it weren't for the desire to make a cross-platform app that also runs on native (without duplicating the code and effort). So I'm left with React, as it enables React Native Web.
But if SolidStart had a native story, with an integrated setup, something akin to Hotwire Turbo (but maybe more like React Native Turbolinks, so I never have to touch Swift or Java, even if customising the nav bar) that would by default be set up to enable native iOS Safari push notifications, plus maybe in-built shared element transitions, then I would love to choose SolidStart. Just for the fact that I would for the most part avoid the native ecosystem: separate build and release pipeline, App Stores, and whatnot. Only important thing would be that the React Native Turbolinks shell app had enough native features not to get thrown out of the App Store, even though it wrapped a SolidStart PWA.
The more obvious answer for SolidStart's native story would perhaps be CapacitorJS. But the caveat (and dirty little secret) there is that it actually bundles your PWA and ships it with the App Store bundle. Although I've read you could also use CapacitorJS to ship the App Store bundle with a WebView so that the PWA would always be served fresh. With the aforementioned risk. So only as long as the shell app had enough native features (something besides just notifications I have learned, preferably at least some navigation nav bar, like React Native Turbolinks and Hotwire Turbo has) to get past App Store review process.
The thing is—from the commercial perspective I can understand the appeal of the "cross-platform" approach but from an engineering perspective "cross-platform" is an immediate compromise towards sub-mediocre outcomes because it leaves you in a postion where you cannot optimize for any platform without heavily penalizing the others.
And React/Native demonstrates this beautifully. Look at how much bloat Preact got rid of, compared to React, by not having to support native while preserving "declarative UI" and DX. And look at the rings that Inferno runs around React because it doesn't have to support native.
So my attitude is:
A compromise is just going to leave everybody unhappy. Commit to the approach that is going to generate the most value.
Obligatory Scott Jenson "The App is a Technology Tiller" references :
That's a very personal perspective. I remember tossing Dave Thomas's Programming Ruby (2005) across the room because it made no sense to my C/C++/C#/Java/SQL/PLSQL brain at the time. Similarly JavaScript didn't jive with me either, until Clojure/Elixir/Erlang put my brain through the ringer. Once I realized the Scheme-ish tactics that were available in JavaScript I was off to the races.
For the longest time I resented that the rise of JavaScript CSR framework SSR restricted server side choice by forcing running Node and therefore JavaScript on the server. But once I realized that eBay with marko deliberately (and successfully) abandoned Java-based web development I had to reevaluate my position (and then the whole Gen 3 thing happened).
You cold well use PWA everywhere if it wasn't for apple's greed and users won't probably notice the difference.
The capabilities were somewhat limited but growing step by step:
With some bonus:
Thinking about this topic, why don't just stop building "native" applications and instead add and maintain capabilities to PWA platform to unify it?
I've tried PWAs in Windows, Android and iPadOS and I've no complains. Good experiences overall.
My question is do we really need yet another platform specific language and environment just to proceed to limit it's capabilities for different concerns?
Starbucks, Aliexpress, Trivago, Android Go platform, The Washington Post, NASA... Did a case study and/or have their PWA online (some available depending on the country) but maybe Tinder and Telegram are the best examples of a company built on the top of a PWA.
The second law of thermodynamics states that in an irreversible process, entropy always increases, but thermodynamics doesn't apply to software AFAIK and we still have a chance to spread a bit of love and KISS a bit here and there.
Putting aside the "popular-culture stack" of Next.js/Tailwind CSS the popularity that tRPC is gaining is more than a little troubling and seems to once again exemplify Dave Thomas's observation:
"I think there is a horizon of maybe 7 years, 8 years that developers just don't look back beyond that, so every 7 or 8 years somebody re-invents something that already existed past that horizon"
Developer's have been trying to make RPC work since 1974 and invariably run into limitations because "to make distributed computing more like local computing" defies the laws of physics.
I guess it's one thing to use it as a more "ergonomic fetch" but I think the more likely outcome is the development of applications that are in complete denial of the constraints that the server-client-chasm will always impose on web applications.
Given the recent work on hydration and resumability the server-client-chasm is finally being appropriately addressed in terms of rendering but it seems that when it comes to post-initial-load server-client-communication the realities of the server-client-chasm are still being willfully ignored (if not by the library itself then perhaps by the developers who use it).
I won't really say that there's a "chasm" between servers and clients, we've an infrastructure that's Internet, which is "just" a network, with it's characteristics. And we use that network to send and receive communication packages from one system to another, that's all.
I agree with:
In this post but I've never heard an individual saying a single of those fallacies mentioned in it 😅 (Probably because none of them are true).
On the other hand, those infrastructure limitations affect also desktop and mobile apps as interacting with servers is as requirement (the major part nowadays).
I don't think it can beat GraphQL but this tRPC thingy seems interesting (Added to the "must try" list) thanks for sharing!
It should be said that both Tinder and Telegram have native apps, but in addition they now also have PWA's called Tinder Online and Telegram Web.
The main reason (I guess) is Apple not allowing full support to PWAs so you need to pay the yearly subscription to the store plus a great % of your in-app payments...