5 ms·

The traditional approach stopped working. It becomes chaotic and inefficient to always directly talk to Domo. No. The traditional approach was web 1.0, which

The traditional approach stopped working. It becomes chaotic and inefficient to always directly talk to Domo. No. The traditional approach was web 1.0, which was abandoned due to UX issues, not complexity. Later on, the chaos of direct DOM manipulation by multiple javascript entry points became too much and was formalized into the SPA frameworks we see today. An alternative solution is to go back to the true traditional approach & address the interactivity issues within that architecture (REST/HATEOAS).

chrischattin 6y ago
Yes! You 100% dont need a front end framework like React to achieve dynamic UI effects. I’d argue they’ve degraded the user experience over time, complicated development process, and slowed down the web experience for most people. The fact remains client side JS frameworks did not grow organically from the open source community. They had to be pushed into the dev mindspace by the mega-caps tech cos to offload processing power to the client. For the vast majority of companies (all but a handful), front end frameworks hold an org back. I’ve had this unpopular opinion for several years, and have yet to meet/work with a startup who didn’t regret choosing Angular/React/etc.
- slifin 6y ago
  SPAs designed to mirror state on the server have a distributed data problem, there are lots of problems there in terms of fetching, updating, ensuring the users are traversing from action, loading, success/failure etc Then there's the problem that the page could have changed since the user started filling out that form, what happens when those form values now conflict etc etc The difference between serving a dead fish of a HTML page, and a SPA application is vast because you're essentially creating 2 independent systems, server and client instead of just server and then adding one of the hardest thing in computing which is consensus between disparate systems I'm quite excited about React Server Components because it means for the majority of your web app you can return to the simplicity of shipping HTML it doesn't solve everything but at the moment client side applications have a lot of boilerplate to do with just keeping the server in sync that would have been historically "for free" in a server context
  - chrischattin 6y ago
    Yes. This exactly. You're basically writing the business logic in the app twice. It's an anti-pattern in my opinion that adds all kinds of tech debt. I'm loving it that the trend is starting to go back to rendering HTML from the server, then sprinkling on dynamic elements when desired. It's so much more efficient whether you're talking compute, developer time, or the ability to stay agile and change/add features as you learn about the market.
- franklampard 6y ago
  Curious why they regretted and how else would they have built the web app
- hombre_fatal 6y ago
  That clients exist to do work so that a company's hardware doesn't have to is cynical, a "client bad [if it's built with JS]" cargo cult, and it suggests that you can't think of any upside to doing things on the user's powerful device instead of a phone-home network request to a server.
- lucasmullens 6y ago
  You've never met anyone who didn't regret React? According to the Stack Overflow Developer Survey, 68.9% love React. I feel like you haven't talked to enough people. The idea that client side JS was pushed to offload processing power is a bit ridiculous. Do you have any evidence for that claim? Many React sites these days do SSR anyway (running the client-side code on the server) so it doesn't seem like they would save money doing that.
tshaddox 6y ago
That sounds nice, but isn’t it really just saying “the problem is too hard so the solution is to not even try?”
- recursivedoubts 6y ago
  No: https://htmx.org https://htmx.org
  - zdragnar 6y ago
    From the home page: "Why should only <a> and <form> be able to make HTTP requests?" Because of accessibility tools, especially screen readers. This looks like yet another DSL that has to be learned, and does not appear to do anything to solve the UX issues of Web 1.0 that jQuery didn't. (I recall plenty of attempts to build frameworks on jQuery that relied on automagically parsing commands out of data-x attributes). Additionally, you now need to know your server language's DSL, whereas the bigger tools all offer server side rendering via JS if that is your thing. I am not saying it is bad, only that I don't think it is an answer for this thread.
    - systemvoltage 6y ago
      Saying HTMX is a DSL is a bit much. It's a handful of attributes on existing elements.
    - recursivedoubts 6y ago
      htmx is different in that it stays within the original REST/HATEOAS model of the web, it pushes HTML as a hypertext. All interactions are via HTML, so you are truly using Hypertext as the Engine of Application State. Since htmx tries to fold in alongside the regular HTML concepts (which you need to know anyway) you need to know less, and your back end can be in whatever language you prefer. No javascript on the front end, no pressure to adopt it on the back end. Accessibility is a concern, but, like everything else, has to be traded off against other concerns.
      - 6y ago
franklampard 6y ago
Can you show me an example of such a solution?
- recursivedoubts 6y ago
  Yes: https://htmx.org https://htmx.org
paulie_a 6y ago
Web 1.0 involved massive amounted of tables. It was definitely abandoned due to complexity
- recursivedoubts 6y ago
  That was layout, not logic. It doesn't have much to do with the adoption of React and other front end libraries.
- systemvoltage 6y ago
  Also Tables are abandoned altogether even when we need them like displaying tabular data.

chrischattin 6y ago

Yes! You 100% dont need a front end framework like React to achieve dynamic UI effects. I’d argue they’ve degraded the user experience over time, complicated development process, and slowed down the web experience for most people. The fact remains client side JS frameworks did not grow organically from the open source community. They had to be pushed into the dev mindspace by the mega-caps tech cos to offload processing power to the client. For the vast majority of companies (all but a handful), front end frameworks hold an org back. I’ve had this unpopular opinion for several years, and have yet to meet/work with a startup who didn’t regret choosing Angular/React/etc.

slifin 6y ago
SPAs designed to mirror state on the server have a distributed data problem, there are lots of problems there in terms of fetching, updating, ensuring the users are traversing from action, loading, success/failure etc Then there's the problem that the page could have changed since the user started filling out that form, what happens when those form values now conflict etc etc The difference between serving a dead fish of a HTML page, and a SPA application is vast because you're essentially creating 2 independent systems, server and client instead of just server and then adding one of the hardest thing in computing which is consensus between disparate systems I'm quite excited about React Server Components because it means for the majority of your web app you can return to the simplicity of shipping HTML it doesn't solve everything but at the moment client side applications have a lot of boilerplate to do with just keeping the server in sync that would have been historically "for free" in a server context
- chrischattin 6y ago
  Yes. This exactly. You're basically writing the business logic in the app twice. It's an anti-pattern in my opinion that adds all kinds of tech debt. I'm loving it that the trend is starting to go back to rendering HTML from the server, then sprinkling on dynamic elements when desired. It's so much more efficient whether you're talking compute, developer time, or the ability to stay agile and change/add features as you learn about the market.
franklampard 6y ago
Curious why they regretted and how else would they have built the web app
hombre_fatal 6y ago
That clients exist to do work so that a company's hardware doesn't have to is cynical, a "client bad [if it's built with JS]" cargo cult, and it suggests that you can't think of any upside to doing things on the user's powerful device instead of a phone-home network request to a server.
lucasmullens 6y ago
You've never met anyone who didn't regret React? According to the Stack Overflow Developer Survey, 68.9% love React. I feel like you haven't talked to enough people. The idea that client side JS was pushed to offload processing power is a bit ridiculous. Do you have any evidence for that claim? Many React sites these days do SSR anyway (running the client-side code on the server) so it doesn't seem like they would save money doing that.

tshaddox 6y ago

That sounds nice, but isn’t it really just saying “the problem is too hard so the solution is to not even try?”

recursivedoubts 6y ago
No: https://htmx.org https://htmx.org
- zdragnar 6y ago
  From the home page: "Why should only <a> and <form> be able to make HTTP requests?" Because of accessibility tools, especially screen readers. This looks like yet another DSL that has to be learned, and does not appear to do anything to solve the UX issues of Web 1.0 that jQuery didn't. (I recall plenty of attempts to build frameworks on jQuery that relied on automagically parsing commands out of data-x attributes). Additionally, you now need to know your server language's DSL, whereas the bigger tools all offer server side rendering via JS if that is your thing. I am not saying it is bad, only that I don't think it is an answer for this thread.
  - systemvoltage 6y ago
    Saying HTMX is a DSL is a bit much. It's a handful of attributes on existing elements.
  - recursivedoubts 6y ago
    htmx is different in that it stays within the original REST/HATEOAS model of the web, it pushes HTML as a hypertext. All interactions are via HTML, so you are truly using Hypertext as the Engine of Application State. Since htmx tries to fold in alongside the regular HTML concepts (which you need to know anyway) you need to know less, and your back end can be in whatever language you prefer. No javascript on the front end, no pressure to adopt it on the back end. Accessibility is a concern, but, like everything else, has to be traded off against other concerns.
    - 6y ago

franklampard 6y ago

Can you show me an example of such a solution?

recursivedoubts 6y ago
Yes: https://htmx.org https://htmx.org

paulie_a 6y ago

Web 1.0 involved massive amounted of tables. It was definitely abandoned due to complexity

recursivedoubts 6y ago
That was layout, not logic. It doesn't have much to do with the adoption of React and other front end libraries.
systemvoltage 6y ago
Also Tables are abandoned altogether even when we need them like displaying tabular data.