Hyperview – Native mobile apps, as easy as creating a website
hyperview.org

・

242 points

・

brickers

・

4 days ago

147 comments

recursivedoubts ・ 3 days ago

Hyperview is a very interesting mobile-oriented hypermedia system created by Adam Stepinski.

He talks about is in the third part of our book, hypermedia systems:

https://hypermedia.systems/part/hyperview/

I have said before that I regard his work as much more innovative than htmx in that he developed an entire hypermedia client and format for his system.

  • toddmorey ・ 3 days ago

    I'm curious about the limitations that prevent these apps from writing / caching local data. It doesn't seem like the paradigm would have to change entirely to support that.

    • recursivedoubts ・ 3 days ago

      There aren't any, with hyperview you actually own the hypermedia client as well as the server and you can write and cache local data in the form of custom extensions you make to it.

      I think that needs better documentation though.

      • smackeyacky ・ 3 days ago
        ・ 2 more

        So, basically it's like every other non-native development environment for mobile: basically useless when you want to use any feature of the phone.

        These things always implement the easiest bit of mobile development (the UI) and then make everything else harder, so it's useless for anything non-trivial.

        • recursivedoubts ・ 2 days ago

          i don't know if being that pessimistic is warranted i'd need adam to comment

YuukiRey ・ 3 days ago

I overlooked it at first even though it’s right there on the landing page but this is ultimately still React Native with all the baggage that entails.

  • strogonoff ・ 3 days ago

    I briefly investigated using React Native on a project. Obscure installation and linking process which no one seems to understand exactly, no SPM support on iOS, incomplete documentation that from the start pushes to adopt yet another layer on top (such as Expo, and I suppose Hyperview is now another option)… It felt like I am adopting some rusty legacy software, and not in a good way (more full of quirks than mature, well-documented and time-tested). Judging by discussions, most people would somehow get it working and then not touch it again until it breaks. My intuition was to stay away and to recommend, if PWA is not an option and resources are limited, to go with a native app for one platform (whichever more familiar) & later pay someone to port it for the other.

    • iforgot22 ・ 2 days ago

      Probably has changed since then, but I remember the RN docs telling me to use Expo. I was wondering the whole time, do people actually use Expo or no. And why is it uploading my code to some website? Soon I had a clear answer; I had to "eject" from Expo to do a prod build or just add any native components. Not a good first impression.

      That said, RN was a win in the long run. It was a lot less baffling than the notorious Xcode/Swift/ObjC/UIKit ecosystem I'd used for years.

      • robertoandred ・ 2 days ago

        That hasn’t been true for quite a while. No need to upload code to build or submit, though it certainly makes it easier.

      • strogonoff ・ 2 days ago

        For what it’s worth, the RN investigation I did was just last month, and impression was not good.

        On the other hand, regarding iOS in particular, SwiftUI docs improved a lot recently. I remember them being baffling indeed from a few years back.

    • tarentel ・ 3 days ago

      If resources are limited and you plan on charging any type of money for the app, either one time or as a subscription, it's almost always better to go iOS first and port to Android later. I obviously can't speak for the ecosystems as a whole but anecdotally of the last few companies I've worked for a strong majority of paying users came from iOS.

    • mijkal ・ 3 days ago

      In my xp, React Native was far more fragile a few years ago, but it has improved immensely since then. I quite enjoy working with it these days.

biosboiii ・ 3 days ago

As a reverse-engineer tinkering with iOS this reminded me of some system apps.

E.g. in the app store you click a button, send a request, receive the response which contains a xml-like structure describing the UI mutation to your action.

<Alert>

   <Header>iTunes Login</Header>

   <Body>We could not find a user with those credentials.</Body>
</Alert>

type stuff.

  • LudwigNagasena ・ 2 days ago

    Server-Driven UI is a very common architectural pattern.

globular-toast ・ 3 days ago

Any "app" framework that isn't offline-first seems broken by default to me. It seems ridiculous to me that client-server architecture is considered the easy thing now. Where did it all go wrong?

  • vincnetas ・ 3 days ago

    When companies decided that they need to know as much as possible about the end user, and don't want to care about backwards compatibility (old version apps, all users are using latest)

    • mihaaly ・ 3 days ago

      And consequently when they started to give no f about if users like or not the new version of the app forced on them. So before the Enterprise Oriented Design.

  • Hilift ・ 3 days ago

    Making mobile platforms second class citizens was wrong.

paradite ・ 3 days ago

Ah finally the Western tech ecosystem has caught up with WeChat/Alipay mini programs.

https://developers.weixin.qq.com/miniprogram/en/dev/framewor...

China had this DSL for building mobile apps for years. Those these apps are initially embedded inside WeChat/Alipay, there are now frameworks that allow it to run outside, like uniapp.

https://en.uniapp.dcloud.io/

  • klausa ・ 3 days ago

    I've had very limited exposure to Alipay mini-programs (took a daytrip to Shenzhen from HK); but anything I had to touch (couples of restaurant menus; buying tickets for metro) was _screaming_ "this is poorly constructed webpage", not native-like experience.

    Are there some you would recommend to see as an example of it being done right?

    • nsonha ・ 2 days ago

      > poorly constructed webpage", not native-like experience

      yes "poorly constructed" is the key here. Poorly constructed "native" apps are not better.

      Let's not pretend that all apps need native capabilities. The vast majority of them, or the vast majority of their functionality, can boils down to showing lists and images. Pretty wasteful to make apps in native languages just to do that if you ask me.

    • paradite ・ 3 days ago

      You can buy plane tickets, railway tickets, book hotels on wechat via popular 3rd party booking platforms.

      I think there are first party integrations in wechat app, go to Me - Pay and Services, you can see a bunch of them.

      • klausa ・ 3 days ago
        ・ 21 more

        Sorry, just to clarify — I meant examples of services that "feel" nice to interact with in the app; not examples of what they can be used for.

        • paradite ・ 3 days ago
          ・ 14 more

          I mean those 1st party integrations directly listed in WeChat services page are probably good examples of services that "feel" nice to interact, because they are used by millions of people everyday and they are need to optimized and polished to be able to serve millions of users.

          Here's a screenshot of the list, if you want to Google and check out some of them: https://imgur.com/a/KKEdliE

          • InsideOutSanta ・ 3 days ago
            ・ 3 more

            There's a pretty big difference in what UX "feels nice" to East Asian audiences vs Western audiences. This video provides some insight into why this might be: https://www.youtube.com/watch?v=WSMFnJnY7EA

            • sgoschi ・ 3 days ago
              ・ 2 more

              The comments make it seem like it's more a case of users tolerating it due to the apps usefulness. Interesting video though, haven't had any contact with Chinese apps, so that was enlightening.

              • strogonoff ・ 2 days ago

                Tolerance of bad UI because of its usefulness (or if it is the only available option due to approval process and/or lack of competition) strikes me as a time-tested approach in enterprise environments. I dread to imagine that, but in real life. Is that how it is for people in the most populous country?

          • mathverse ・ 3 days ago
            ・ 9 more

            Minions of people use SAP daily that does not mean it's a nice thing to interact with.

            • paradite ・ 3 days ago
              ・ 8 more

              I agree that numbers alone might not mean much, but I do think B2C apps with millions of users have a higher bar in terms of design and polish compared to B2B/ERP apps.

              Also, fixed typo!

              • HWR_14 ・ 3 days ago

                It's probably easier to switch jobs to avoid B2B apps you don't like than to avoid WeChat in China.

              • mathverse ・ 3 days ago
                ・ 6 more

                But it's not like you can choose in China either :)

                • TeMPOraL ・ 3 days ago
                  ・ 5 more

                  It's not like you can choose in the West either, either :).

                  Number one goal of any software service today is to make its offering exclusive in some way - exclusive content, exclusive deals, exclusive integrations, exclusive set of participants (network effects), going super-broad super fast because infinite VC money lets you keep operating at a loss indefinitely, etc.

                  • YuukiRey ・ 3 days ago
                    ・ 4 more

                    You're making it sound as if the difference in choice between China and western countries is negligible. Surely that's not the case? If every VC company tries to pull you into their walled garden, I can still choose from among a variety of said walled gardens.

                    I could be wrong of course, since I don't know how many AliPay and WeChat competitors there are.

                    • TeMPOraL ・ 3 days ago
                      ・ 2 more

                      > If every VC company tries to pull you into their walled garden, I can still choose from among a variety of said walled gardens.

                      When they play it right, you're forced to choose all of them, or at least a significant subset of them, so that their partially overlapping offering add up to the actual thing you need.

                      • herewulf ・ 2 days ago

                        Ah, modern video streaming services and every restaurant's special snowflake app.

                    • z2 ・ 3 days ago

                      The competitors at the consumer-facing super app level (with mini programs of varying awkwardness) include Meituan, XiaoHongShu, and to an extent, Toutiao, JD.com, and Baidu. But you don't need those gardens as a publisher if you're on Android--ironically because Google services are banned, there are over a dozen app stores to competing to fill the void. Compare that with the western duopoly of Apple App Store and Google Play.

          • iforgot22 ・ 3 days ago

            That's all fine if the particular customers you want to reach are among the millions used to WeChat services.

        • scotty79 ・ 3 days ago
          ・ 6 more

          It's a bit like asking which power company has pretty technicians.

          • klausa ・ 3 days ago
            ・ 3 more

            We're in a thread talking about a technology that purports to make creating "native mobile apps, as easy as creating a website"; and the parent claimed that the Alipay/WeChats mini-app stacks are similar.

            I don't think asking for examples of this resulting in an experience that's pleasant is unreasonable?

            • afavour ・ 3 days ago
              ・ 2 more

              I think the point OP is making is that the relative pleasantry of the experience isn't as important for end users as it is for us developers. My anecdotal experience bears that out: I shudder when I see a web-heavy native app, my non-tech friends don't bat an eyelid. People learn UIs, no matter how janky, very quickly if the end goal is important to them.

              • scotty79 ・ 2 days ago

                I think my point was that an application that exists, is up to date and works is a better application than the one that doesn't exist or is stale because it's harder to write and maintain but feels (or would feel if it existed) nice and polished.

                For practical purposes like buying stuff or accessing information I want practical applications that can be quickly iterated on.

          • gadflyinyoureye ・ 3 days ago

            FPL. Tone bodies with good tans. Don't see that with IP&L.

          • 1shooner ・ 3 days ago

            Well, do those WeChat services have competition? That's where I've seen the push for better UX: it's a signal to users that your product is overall higher quality. So not so much 'pretty power company technicians' and more 'Is the lobby of the hotel clean?'.

  • lolpanda ・ 3 days ago

    Those mini apps are built on the same web stack. I believe the main advantages of creating mini apps are that the platform provides identity (allowing you to know who the users are upon permission approval) and payment APIs.

    • paradite ・ 3 days ago

      They use a mixture of web rendering stack and native rendering stack. See my other comment.

      There are also more architectural diagrams thst illustrate the layers in the links I posted in my original comment.

    • aquariusDue ・ 3 days ago

      I believe Telegram has something similar too.

  • flohofwoe ・ 3 days ago

    Aren't those just web apps running inside a webview widget? What's "native" about that? (but tbh, at first glance this Hyperview thing looks like it's just re-inventing web browsers too).

    • anonzzzies ・ 3 days ago

      When I was still using wechat (and in china); it was a mix; native buttons and payment integrations mixed with webviews for content.

    • paradite ・ 3 days ago

      I think the key idea is not the renderer layer, but the concept of DSL so that it can run on multiple platforms natively.

      To go back to your question. WeChat actually has two sets of renderers for mini programs, one based on webview, and one based on native iOS / Android components. But you are right that most mini programs are using mostly webview to render, with only a few things being natively rendered.

  • aa-jv ・ 3 days ago

    The "Western" (whatever that is) tech ecosystem has long had this technology out there .. its the "Western" marketing ecosystem that has been squashing it - for example, Apple quashing any and all use of JITs and VMs in order to keep their native platform relevant ..

happytoexplain ・ 3 days ago

>as easy as creating a website

This strikes me as odd - I have a much easier time making a well-functioning native app (iOS or Android) than the equivalent website. That's not typically a checkmark in the web column for web vs app pros and cons.

Unless we're including distribution when we say "creating".

  • LVB ・ 3 days ago

    >Unless we're including distribution when we say "creating".

    I think it has to be included given how much traffic I see from mobile devs I follow about getting stuck in some review blackhole, running afoul of a TOS or payment rule, etc. Getting the app built is in your control, but getting it to end users has a big dependency on others, potentially. The idea of being able to push code to a server you control and deliver instant updates is appealing.

  • strogonoff ・ 2 days ago

    Engineers have vastly different definitions of “well-functioning” and “easy”. Once I saw an app that used accelerometer API to determine in real-time whether the user is walking. It was done as a web app (native was considered too difficult) and the data was sent to GCP for processing. Even without the GCP code, which involved a custom ML model, it was in the hundreds of LoC. I don’t know how well it would function in real use, since it did not really reach mass production, but I do know it is possible to do completely on-device with very little bespoke logic and a very small LoC count on iOS (and I’m sure on Android) where APIs would give you exactly that (and even movement speed, if needed).

donatj ・ 3 days ago

I am very unclear reading the documentation and clicking around, how do you actually implement the logic? Some sort of JavaScript runtime?

SillyUsername ・ 3 days ago

How does this improve on w3c standard of xforms + CSS?

tjmtjmtjm ・ 3 days ago

I'm more of a Floral Green person.

  • latortuga ・ 3 days ago

    Underrated joke, did not expect a Title Fight reference when I opened this thread!

sirjaz ・ 3 days ago

I'm wondering if they could get that to work with React Native for desktop apps

  • openrisk ・ 3 days ago

    You'd have to run a server in the background which complicates things but otherwise it would seem to be feasible.

ipnon ・ 3 days ago

Not even a day after the post about HTMX not living up to its promise! There are only two certainties in life, death and frontend churn.

  • Cthulhu_ ・ 3 days ago

    > frontend churn.

    Frontend churn hasn't been as much of a thing for years now, see e.g. https://2022.stateofjs.com/en-US/libraries/front-end-framewo.... If you stuck with Angular or React 10 years ago, you're still good today. jQuery is even older but still on 75% of websites (https://w3techs.com/technologies/overview/javascript_library), and Bootstrap is on nearly a quarter.

    Frontend churn is only a thing if you try to stay on the left side of the Gartner Hype Cycle.

    • ricardobeat ・ 3 days ago

      That’s only true on the surface: if you chose React, you had to rebuild and relearn everything about once every two years. Averages out to about the same workload as following the latest fad. Maybe more, since refactoring legacy code is 10x harder than building from scratch.

      • agos ・ 3 days ago
        ・ 5 more

        this is just not true. even the worst offenders (looking at you, react-router) do not require to "rebuild and relearn everything". What an unnecessary hyperbole.

        • ricardobeat ・ 3 days ago
          ・ 3 more

          Maybe not React itself, but the ecosystem as a whole. I can list some of these changes that generated a lot of work from memory:

          - the move from in-browser JSX compilation to build tools / webpack

          - the move from class components to functional components and hooks

          - all the changes related to ES6 classes and modules + build system

          - server-side components

          - Flux -> Redux

          - Redux -> MobX -> Relay -> Redux Toolkit -> Context API -> Zustand / Jotai / Recoil -> react-query (next: zero?)

          - Next.js and Remix, 7 react-router versions (latest with major breaking API changes again)

          - Signals and more SSR stuff (I stopped looking at this point)

          And this is ignoring all the React Native churn over the years as I imagine not everyone is involved with that.

          Even if your particular project didn’t go through all of these migrations, you had to relearn things to be able to work in other/newer projects.

          It’s impossible to measure, but having written and used a ton of different frameworks, I really do feel like the overhead of keeping up with the changes was equal to or larger than learning a new one every couple years.

          • iforgot22 ・ 2 days ago

            Also Typescript, if your team started using it.

          • gr4vityWall ・ 3 days ago

            From that list, I believe Server-Side Components is a big offender in terms of complexity.

            React Router changing its API so often felt unnecessary too.

            I wouldn't call all of that churn though, as I believe most devs only had to deal with a subset of those. Some who got into React in 2019 could be writing the same kind of code today.

            Frontend as whole, on the other hand...

        • iforgot22 ・ 3 days ago

          I really do have to relearn react-router every time I use it, then I pin it to that version so it doesn't break later. Last time was v6, now there's v7 since Nov '24.

          Besides that, React churn isn't too bad. I have to fix builds, but I don't have to relearn everything about React. Unlike Angular.

    • flamwenco ・ 3 days ago

      Angular of 10 years ago... you mean the 1.0 framework that's wholly incompatible with 2+ because it was a ground up re-write?

    • iforgot22 ・ 3 days ago

      React didn't have hooks 10 years ago, but at least they're compatible with classes

  • JodieBenitez ・ 3 days ago

    > the post about HTMX not living up to its promise

    You read that wrong.

  • mpweiher ・ 3 days ago

    Which post was that?

dbbk ・ 4 days ago

Surely this will be redundant with React Server Components on RN/Expo?

  • sibeliuss ・ 3 days ago

    Server components + RN + Expo.... Could it get any more pointlessly complicated?

    • netghost ・ 3 days ago

      This is a ReactNative app that consumes XML and maps it to ReactNative components, so you're still using those pointlessly complicated technologies, but through a proxy application that abstracts some of the complexity away (https://github.com/instawork/hyperview?tab=readme-ov-file#hy...).

      When you hit the boundaries of what Hyperview can do, you're going to need to dig into some of the details, but mayhaps you don't need those features. Either way, it's an interesting project, but like everything else it's going to have _some_ drawbacks

      • j45 ・ 3 days ago

        Less time spent building a stack temple to venerate oneself.

    • satvikpendem ・ 3 days ago

      Just because there are multiple technologies does not make it complicated per se. Indeed, something could evolve to a simpler model, which it seems RSC on RN is.

      • sibeliuss ・ 3 days ago
        ・ 2 more

        Keep dreaming man. Just look at what Next has become... It has taken "render component on the screen" and turned that into an experts domain. It's a nightmare for anyone who isn't the most skilled, for projects that are more than just toy apps and AI one-offs.

        • satvikpendem ・ 3 days ago

          Not sure about that, it's gotten easier as time goes on, especially with server actions. Previously we used something like OpenAPI to map types on the frontend and backend and had to make separate HTTP endpoints for everything. Now I just write a function and it's all taken care of automatically, I can put types and functions in any folder I want and it just works.

      • 52-6F-62 ・ 3 days ago
        ・ 2 more

        Doesn’t it require Expo’s servers for a development environment?

        All these companies have given up on the gold rush long ago and are just slinging fancy shovels.

    • dbbk ・ 3 days ago

      Well if you want to remotely update a mobile app UI from your server backend, it seems like the simplest option...

  • benpacker ・ 3 days ago

    This is more of an HTMX native

    • mrbluecoat ・ 3 days ago

      Yeah, the moment I read "Serve your app as XML" my brain instinctively began to move on but it's really just HTML-like semantic snippets that remind me of WebComponents. Example:

      https://github.com/Instawork/hyperview/blob/master/demo/back...

      However, this warning statement should be in bold at the top: "If your app relies on offline data or local computations, Hyperview won't be the right choice."

      For that reason, I lean toward https://volt.build/

      • giwook ・ 3 days ago

        A key distinction here is that Hyperview is free, which makes the offline capabilities or lack thereof a more than reasonable tradeoff IMO.

        Volt looks great, but $15/mo. for the basic plan, $37/mo. for the pro plan that you likely need for the ad hoc builds alone (unless you test in prod).

      • dbbk ・ 3 days ago

        If it doesn't do offline data or local computations what is the point?

captainepoch ・ 3 days ago

For the love of God, stop putting "Native" in web frameworks. No, React will never be native.

  • dbbk ・ 3 days ago

    What does this mean? There are plenty of big, native apps using React.

    • nipponese ・ 3 days ago

      It's "native" in that the wrapper is a native binary, but it's still a webpage.

      • agsnu ・ 2 days ago
        ・ 7 more

        React Native actually constructs a view hierarchy in the platform's UI toolkit, so I'm curious what you mean by "still a webpage"?

        • tstusr20190823 ・ 2 days ago
          ・ 4 more

          React Native constructs only single UIView by default and draw actual UI using poorly man browser engine using JS. This UI does not "feel native" to user, because it has wrong animation timings, scroll speed, border elevation, missing "native" gestures, etc.

          • agsnu ・ 2 days ago
            ・ 2 more

            That is certainly true of Flutter, which has its own rendering pipeline. React native, if you create a Button then on iOS you'll get an actual UIButton instance constructed, etc.

            • tstusr20190823 ・ 2 days ago

              It is true for a few components derived from TouchableOpacity like Button, sure. That is NOT true for most other components. You does not have UICollectionView, UINavigationView (only solvable with third-party buggy components), etc.

          • dbbk ・ a day ago

            With respect, literally the exact opposite is true. I think you're mistaking it with something else.

        • kelnos ・ 2 days ago
          ・ 2 more

          But everything in that view hierarchy is still drawn using HTML and CSS, and all the logic is implemented in JS, no? If that's the case, then that's not "native".

    • captainepoch ・ 3 days ago

      React is a web framework. You can put Native behind React, it'll never be.

      • tstusr20190823 ・ 2 days ago

        React allows you to write custom renderer and React Native is a quick and dirty example of that custom renderer. The only reason it does not "feel native" is because Meta does not invest much into it and only subset of the "native" features is implemented in "native way".

trey-jones ・ 3 days ago

Using web technology to build "native" mobile apps has been around almost as long as mobile apps themselves. I used Appcelerator Titanium and Phonegap to do this beginning in 2012 (maybe even 2011) before eventually trying Native development later after finding these options underwhelming.

I have a reasonable amount of experience doing both, and my opinion is that development tools aren't really the problem. The biggest pain point is the platform specific deployment and maintenance requirements (including legal and technical documentation) that will be needed regardless of what technology you use to actually build the product. Because of this I always advise clients that they don't really need a mobile app. Just build it on the web.

If you absolutely must have a mobile app, you need to fully commit and hire an internal development team and be prepared to keep paying them as long as the app is going to be in use.

  • giancarlostoro ・ 3 days ago

    > Just build it on the web.

    It takes a very insignificantly small amount of JavaScript to make a website a Progressive Web App, which iirc can be listed on app stores.

    If you dont use React or any fancy frameworks, I believe last time I ever did such a project our JS was under 50 lines of code to have our PWA working fully offline. There were some odd hacks, like detecting network connectivity.

    • Lerc ・ 3 days ago

      Is there a super simple tool for turning statically served websites into PWAs?

      Last time I looked all of the simple tools had been deprecated in favour of complex tools that do way more than I need.

      If I had a site in a directory that works fine from

          >cd MyWebApp
    >python3 -m http.server
      I would like a command line tool That worked like

          >becomepwa MyWebApp
      Which produced a PWA that downloaded everything on install and could be run henceforth offline.

      I thought this would be a common use case, but I failed to find anything that supported it without intruding on my workflow.

      • giancarlostoro ・ 3 days ago
        ・ 5 more

        Three things you need:

        * Manifest file

        * HTTPS - for localhost I dont remember the workaround, browsers have made this increasingly more complicated from recent experiences

        * Service Worker - This is where I said I had maybe 60 lines of JavaScript.

        If you have these three things, a browser should pick up that your sites a PWA and server running it should be irrelevant... So you MUST have a minimal amount of JavaScript, but I did it using pure vanilla JS, you dont need a fancy framework.

        On that same note, there might be a tool that could inject the bare JS necessary for this, but I dont think it exists, certainly could be built.

        • Lerc ・ 2 days ago

          HTTPS isn't an issue, dropping whatever the command generates onto a HTTPS supporting server isn't an issue.

          I want the manifest to be automatically generated from whatever is in the directory. The service worker should download everything from the manifest at first launch. I'm ok with a download-on-demand build option, but by default it should grab everything needed. If a user installs something, it should be assumed that they can use it offline.

          I feel like the tool should already exist. If it does not yet exist, it seems like there must be a reason for that that I am not aware of.

        • iforgot22 ・ 3 days ago
          ・ 3 more

          The service worker thing is a weird amount of boilerplate. Every time I go back to making a PWA, I skip through 10 search results explaining what a service worker is (idc) until I just find whatever .js code I have to copy. And it's not some trivial one-liner.

          I get that in theory a PWA can do offline stuff and whatever, but 99% of the time someone is only making a PWA to make the app installable on a phone home screen.

          • giancarlostoro ・ 3 days ago
            ・ 2 more

            It is not a trivial one liner no, but you need 3 events implemented in your service-worker file, then in your main.js file you register it.

            Service workers are just JavaScript that runs in the background in their own process in a browser. Could think of them as separate threads. Anyway, all of that can be done in less than 20 lines of JS?

            I consider it simple compared to people building React apps and making the process more complicated than it needs to be just to build a PWA.

            I was able to build a PWA out of a bootstrap HTML5 web app, with minimal JS for REST calls and ag-grid population.

            • iforgot22 ・ 2 days ago

              Yeah, it's no big deal, I just find it odd that it's even a requirement. And using React doesn't get you out of making a service worker either.

  • pjmlp ・ 3 days ago

    What I have learned after all these years, is either do a Web site that is mobile friendly, or go native, anything else is a kludge in the search of holy grail of cross platform development without costs.

    However this is a lie, because after going after the dream of cross platform, one lands on the (N + 1) reality, with team having anyway to master the leaky abstractions of the underlying platforms.

  • etothet ・ 3 days ago

    This * 100. I have a lot of experience with these types of apps and the biggest issue I've encountered is the platform keeping up with native technologies and OS updates.

jsiepkes ・ 3 days ago

"Serve your app as XML"

As someone who started his professional career in 2005: All the old is new again.

  • openrisk ・ 3 days ago

    It sort of proves the point that certain technology choices are not the result of some monotonic "progress" towards a theoretical optimal but rather a random walk under stochastic influences in what we might call "conventions space".

    Serious randomness is induced by the decisions of whatever entities happen to be influential, typically (but not exclusively) by having the most successful economic model. Causally that earnings model need not be at all related with the tech. After all, most 'big tech' is not actually selling the tech itself.

    People mostly code for money so they are attracted and incentivized to use the more visible money-making conventions (be part of wining teams) irrespective of particular technical merit.

    But there are additional more objective dimensions that complicate things. E.g. SPA conventions did solve a user experience problem at the time. It was not pure lemming behavior. In retrospect we know that it could have been solved otherwise but at that time we didn't.

  • scotty79 ・ 3 days ago

    I think webapps should be xml (with all the data to display) transformed into html on the client side with XSLT generated by framework templating system).

    There's a really nice binary XML format that browsers haven't implemented yet: https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange

    • ricardobeat ・ 3 days ago

      Symphony CMS [1] was based on this idea over a decade ago.

      The developer experience was amazing, you could easily inspect the data backing any page. XSLT was hard but probably easier than React these days.

      [1] https://getsymphony.com

    • baggachipz ・ 3 days ago

      What a blast from the past. We did exactly this in '99-2000 (yes), and it was ridiculed as being over-engineered. At the time, it was the future because "XML will underpin all data transfer everywhere", and therefore we would be set up to run on any device, should any other device begin to exist. Needless to say, the winds changed way sooner than that became a real use case.

      • scotty79 ・ 3 days ago

        I originally had this idea about 20 years ago. I still think it's good. At least better than brotli compressed json loaded with JavaScript.

    • iforgot22 ・ 2 days ago

      How would such a webapp make API calls and act on the responses? Even for a static website, HTML isn't very good at handling arbitrary sizes, which I think was part of the original motivation for React.

  • donatj ・ 3 days ago

    Literally. I wrote a fair number of Konfabulator widgets in the early aughts this way. I did a bit of Adobe Air like this as well, everyone insisted it was THE FUTURE, it wasn't.

  • Devasta ・ 3 days ago

    The web is, was, and forever will be stuck reinventing shitty versions of things that they could have had decades earlier if they stuck with XML.

    Custom elements, client side templating, form validation against schemas, they had it all and threw it away.

    • yaldooshi ・ 2 days ago

      Yup. They’re learning why XML needed to be complicated, one simplistic bolt-on HTML/CSS/JS layer at a time in a musical chairs fashion.

  • magic_smoke_ee ・ 3 days ago

    Someone will inevitably create an app to create apps using Brainfuck encoded in Morse code running on a 16-QAM wireless protocol... just beam your app with your data.

  • j45 ・ 3 days ago

    I wonder what going back to the 90's will bring up.

    • iforgot22 ・ 2 days ago

      Was going to say "please no XMPP again," but apparently that was 2000.

  • revskill ・ 3 days ago

    JSON is same as XML.

    • Cthulhu_ ・ 3 days ago

      No it isn't, XML is an ecosystem with things like dedicated transfer protocols (EXI), schemas (XSD), transformers (XSLT) that JSON still doesn't have standardized/normalised even though JSON has been the norm for nearly 20 years. There's some projects of course (JSON Schema, OpenAPI), but they're separate and not part of the same standardization committee.

      • iforgot22 ・ 2 days ago

        I don't remember anything about the XML ecosystem, but XML is already a totally different format from JSON without considering that.

          <body myattr="yeah">
    <thing>hi</thing>
    <thing thingattr="cool">hi2</thing>
    <otherkindathing>hi2</otherkindathing>
  </body>
        can be thought of as nested objects, each having a typename, text content, and children. It doesn't translate nicely to JSON. Maybe:

          {"type": "body", "attrs": {"myattr": "yeah"},
   "children": [{"type": "thing", "content": "hi"}, ...]}
    • mathgeek ・ 3 days ago

      As someone who works with JSON every day and almost never deals with XML directly, it’s important to realize saying they are the same is like saying a pocket knife and a Swiss army knife are the same because they both have an extremely useful tool (and why would anyone ever use the thing with all that extra stuff I never use?). Not a perfect analogy but the one I think of for simplicity.

    • beagle3 ・ 3 days ago

      And XML is essentially lobotomized and extra verbose Lisp S-expressions, going back to the 1960’s

      • xarope ・ 3 days ago
        ・ 2 more

        don't talk about my thesis, written in LaTeX, like that...

        /j

        • magic_smoke_ee ・ 3 days ago

          Back in my day, real cowboys wrote their papers in PostScript, making their papers as inaccessible as possible for user of consumer-grade devices. /s

          PS won on human readability and editability but lost on portability to Adobe's own internal competitor, PDF, and because it fought and lost to (La)TeX -> PDF & (La)TeX -> DVI -> PS.

          PS: I once printed out and bound the PDF 1.3 spec[0] on 24 lbs. bleached dead trees on an HP LaserJet IIIP with over a million page count. Some of the nuclear engineers and scientists an office containing <50 people routinely printed thousand page documents every week.

          0. https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...

    • j45 ・ 3 days ago

      JSON is great in it's own regards but the features are not comparable.

      • withinboredom ・ 3 days ago
        ・ 2 more

        At least with XML, you can have custom datatypes, not just strings and numbers and booleans.

        In all seriousness, everything in JSON can be expressed as XML; but not necessarily the other way around.

        • iforgot22 ・ 2 days ago

          Other way around works too (I gave an example above), it's just not pretty in either direction.

          XML makes sense for open-ended, human-written things like documents or apps. It doesn't work so well for APIs and other machine-read/written things where you'd normally use JSON.

    • baxtr ・ 3 days ago

      Text is the same as JSON.