4 ms·

Is the idea in a case like this to go full website, or use something like React/Vue to build a site that's just JS+HTML front end and API calls, and then ship a

Is the idea in a case like this to go full website, or use something like React/Vue to build a site that's just JS+HTML front end and API calls, and then ship a shim of an app which has a webview and the JS+HTML locally, and makes the same network API calls? Then it seems like the build process for native could be just about completely automated or at least reduced to it's basest components, and it's just dealing with App stores. Is this a normal thing that's already done? As is probably obvious, I'm not a front end or app developer.

bob1029 5y ago
Our long term goal is to go all-in on server-side rendered UI. For reference, we use Blazor server-side today and still feel this is still not extreme enough for us. What I would like to see is something where all browser events are piped to our server and we send basic WebGL draw commands back to the client. This would give us pixel-perfect control over how the application presents on any device without worrying about a particular vendor's quirks. Everyone's implementation of a web browser is a little different, but when you get down to the primitive behavior of basic WebGL/canvas usages, the consistency is very strong across all platforms. In order to accomplish this, the server would need to know about each clients' viewport dimensions, etc., so its not like its a free lunch on system resources. This is more about total control and maximum security.
- mwcampbell 5y ago
  > What I would like to see is something where all browser events are piped to our server and we send basic WebGL draw commands back to the client. Do you have a plan for also handling accessibility if you go in this direction?
  - bob1029 5y ago
    > Do you have a plan for also handling accessibility if you go in this direction? It is something I would certainly consider after meeting the most urgent objectives. There is no reason I couldn't consider offering alternative views for certain users which contain things like high-contrast or screen-reader enhancements. The initial scope of this work would be for a privately-used B2B application. Accessibility in this context would be driven by our business customers' specific requirements. That said, providing accessibility is more of a business/application problem than a UI framework problem in my opinion.
    - eropple 5y ago
      So from where I sit, and mind you I'm not claiming to be perfect about accessibility but I spend a good bit of time thinking about it, this answer gives me shivers. 'Cause like: > It is something I would certainly consider after meeting the most urgent objectives. In practice, this is pronounced "no." > That said, providing accessibility is more of a business/application problem than a UI framework problem in my opinion. In practice, this is pronounced "I don't care". An application cannot describe "a button with the caption of 'OK'" without a UI framework that can and does tell it that there is a button, that it has a caption, and what that caption is. To be honest, accessibility is a team effort from everyone and things are already bad enough without actively making them worse.
      - mwcampbell 5y ago
        > In practice, this is pronounced "I don't care". I appreciate that you're taking a stand for accessibility, but IMO, that kind of statement just adds to the shrillness of so much of our online discourse. We can discuss the pros and cons of various approaches to UI, and what it takes to make accessibility practical, without venturing into the topic of whether a developer cares about accessibility, which is likely to just make them defensive.
        eropple 5y ago
        Ooh. Shrill. I'm pretty okay with this as a stance, to be honest, because folks have been asking those of us who are fully abled, very nicely for a very long time, to stop making things harder for them. Blithe dismissal deserves to be received a certain way.
        mwcampbell 5y ago
        > folks have been asking those of us who are fully abled, very nicely for a very long time, to stop making things harder for them. Blithe dismissal deserves to be received a certain way. I'm one of those folks (see my profile). I still ask nicely, and try to be nice even when responding to what seems to be a blithe dismissal, because I want to focus on solving the problem, without making developers feel unnecessarily uncomfortable about honestly discussing a sensitive topic. I still struggle with this, and might not have gotten it right in my own response to bob1029 yesterday, since that response got downvoted. Also I'm not sure bob1029's original response is a blithe dismissal; he may just be honestly stating the decision-making process that makes sense in a business world where disabled people are a tiny minority. That sucks for us, but maybe I just have to have the serenity to accept what we can't change, and focus on what is feasible, such as reconstructing UI content and semantics using OCR and other machine learning techniques (like Apple is doing as an option on iOS), rather than trying to convince every UI framework and application developer to put extra work into accessibility. I've been resisting that conclusion, but I'm getting closer to accepting it.

bob1029 5y ago

Our long term goal is to go all-in on server-side rendered UI. For reference, we use Blazor server-side today and still feel this is still not extreme enough for us. What I would like to see is something where all browser events are piped to our server and we send basic WebGL draw commands back to the client. This would give us pixel-perfect control over how the application presents on any device without worrying about a particular vendor's quirks. Everyone's implementation of a web browser is a little different, but when you get down to the primitive behavior of basic WebGL/canvas usages, the consistency is very strong across all platforms. In order to accomplish this, the server would need to know about each clients' viewport dimensions, etc., so its not like its a free lunch on system resources. This is more about total control and maximum security.

mwcampbell 5y ago
> What I would like to see is something where all browser events are piped to our server and we send basic WebGL draw commands back to the client. Do you have a plan for also handling accessibility if you go in this direction?
- bob1029 5y ago
  > Do you have a plan for also handling accessibility if you go in this direction? It is something I would certainly consider after meeting the most urgent objectives. There is no reason I couldn't consider offering alternative views for certain users which contain things like high-contrast or screen-reader enhancements. The initial scope of this work would be for a privately-used B2B application. Accessibility in this context would be driven by our business customers' specific requirements. That said, providing accessibility is more of a business/application problem than a UI framework problem in my opinion.
  - eropple 5y ago
    So from where I sit, and mind you I'm not claiming to be perfect about accessibility but I spend a good bit of time thinking about it, this answer gives me shivers. 'Cause like: > It is something I would certainly consider after meeting the most urgent objectives. In practice, this is pronounced "no." > That said, providing accessibility is more of a business/application problem than a UI framework problem in my opinion. In practice, this is pronounced "I don't care". An application cannot describe "a button with the caption of 'OK'" without a UI framework that can and does tell it that there is a button, that it has a caption, and what that caption is. To be honest, accessibility is a team effort from everyone and things are already bad enough without actively making them worse.
    - mwcampbell 5y ago
      > In practice, this is pronounced "I don't care". I appreciate that you're taking a stand for accessibility, but IMO, that kind of statement just adds to the shrillness of so much of our online discourse. We can discuss the pros and cons of various approaches to UI, and what it takes to make accessibility practical, without venturing into the topic of whether a developer cares about accessibility, which is likely to just make them defensive.
      - eropple 5y ago
        Ooh. Shrill. I'm pretty okay with this as a stance, to be honest, because folks have been asking those of us who are fully abled, very nicely for a very long time, to stop making things harder for them. Blithe dismissal deserves to be received a certain way.
        mwcampbell 5y ago
        > folks have been asking those of us who are fully abled, very nicely for a very long time, to stop making things harder for them. Blithe dismissal deserves to be received a certain way. I'm one of those folks (see my profile). I still ask nicely, and try to be nice even when responding to what seems to be a blithe dismissal, because I want to focus on solving the problem, without making developers feel unnecessarily uncomfortable about honestly discussing a sensitive topic. I still struggle with this, and might not have gotten it right in my own response to bob1029 yesterday, since that response got downvoted. Also I'm not sure bob1029's original response is a blithe dismissal; he may just be honestly stating the decision-making process that makes sense in a business world where disabled people are a tiny minority. That sucks for us, but maybe I just have to have the serenity to accept what we can't change, and focus on what is feasible, such as reconstructing UI content and semantics using OCR and other machine learning techniques (like Apple is doing as an option on iOS), rather than trying to convince every UI framework and application developer to put extra work into accessibility. I've been resisting that conclusion, but I'm getting closer to accepting it.