81–90 of 136 posts
Earlier quoted context omitted.
Check out Canonic https://www.canonic.com/ for an experimental take on an alternative web
Was that supposed to do something other than show half a page and not respond to clicks and scrolls? iOS 15 on iPhone SE 2.
hello, I am the author of this article it is a response to a talk that Mr. Harris gave at JamStack entitled "Have Single-Page Applications Ruined the Web?": https://www.youtube.com/watch?v=860d8usGC0o in the article I show how a hypermedia-oriented (rather than javascript-oriented) library like htmx can address many of the usability concerns that Mr. Harris raises with MPAs, without abandoning the fundamental REST-fu…
On one hand you suggest the culture of complexity is overwhelming, when just a few paragraphs earlier you suggest that sql-tuning and redis caching are how to deal with some of htmlx's problems with latency. That seems highly complex. You have to make deep changes to the back-end and data persistence systems to solve a front end issue.
It feels like the article is trying to say you shouldn't use javascript frameworks in a lot of cases, but then it advocates for using htmx, which is a javascript framework, in those cases?
In my experience the issues people have in front-end come from using tools and frameworks incorrectly, because they don't understand the tradeoffs being made -- so they don't account for those tradeoffs in a reasonable way that eventually comes back to bite the team. Handing people a new JS library that is seeming to intend we completely avoid javascript and therefore the library itself, creating an incentive not to learn how it works.
Earlier quoted context omitted.
Check out Canonic https://www.canonic.com/ for an experimental take on an alternative web
Was that supposed to do something other than show half a page and not respond to clicks and scrolls? iOS 15 on iPhone SE 2.
In other words, it's a demo of what Web performance and usability will be like ten years from now. Twitter and Reddit are already working on redesigning their websites to incorporate this new technology.
(In all seriousness, it's a demo of a subset of Qt compiled to run in a web browser, and it seems to work better on desktop.)
Earlier quoted context omitted.
From the article: > This is, unfortunately, part of the culture of front end development right now: sky-high levels of complexity are tolerated in application frameworks, in build tool chains, in deployment models and so on, and, when problems arise due to all this complexity, more complexity is often offered as the answer. > "Simple" is disparaging and "sophisticated" is high praise. So, rather.
Seconded. There was a series of similar Twitter discussions when a popular JavaScript "influencer" published an article[0] on how they built their website. The amount of complexity that is self-inflicted in the said article was obviously enormous for proponents of MPAs. However the JS community mostly echoed that the complexity was absolutely within norm. The cultural chasm between JS developers and people who push f…
Yet another cheap shot. Might as well say 'fu js devs'. How come every time we have a thread on this thing its devs and supporters always come across as arrogant, bitter folks with an axe to grind.
I don't like your technology. I didn't like it several years ago when I was introduced to it, and I don't like it now. It's not a bad idea but calling me an idiot for not doing UI on the backend is not going to win over anyone that doesn't already hate js and the people who write js.
Anyone who claims one language or tech stack is going to become the be-all, end-all of how we build things on the web is either naive or selling something. I've gotten a lot of mileage out of ignoring grandstanders and focusing my time and energy on learning how browsers work. If you understand the DOM, CSS and core JavaScript fundamentals, you can apply your skills to virtually any front-end stack. In the end, the t…
Ironically this is why I prefer angular to react - people say angular is more complex, but IMHO it removes complexity by being "batteries included": reduced cognitive load because and angular project is an angular project so you only need to learn angular itself, and not a zillion extra libraries or frameworks.
hello, I am the author of this article it is a response to a talk that Mr. Harris gave at JamStack entitled "Have Single-Page Applications Ruined the Web?": https://www.youtube.com/watch?v=860d8usGC0o in the article I show how a hypermedia-oriented (rather than javascript-oriented) library like htmx can address many of the usability concerns that Mr. Harris raises with MPAs, without abandoning the fundamental REST-fu…
Earlier quoted context omitted.
Agree. The other thing I'd add is that we're long overdue for a more fundamental paradigm shift in webdev. That is, we've changed our goal from the original page request/response model to one of delivering native-like SPA experiences. But, the frameworks that win don't fundamentally reconsider the old technology. Instead, they stop at the DOM layer, speak heavy HTML/CSS, make us manage browser mechanics like URLs, hi…
Check out Canonic https://www.canonic.com/ for an experimental take on an alternative web
All those shitty restaurant web sites that were forced to become almost useful when flash went away, can rejoice and go back to being as awful as they were.
Using HTML to drive an app's interface has nothing to do with the tech stack, in fact, I think it opens the door to a more diverse tech stack. Optimistic UI updates, state management, and other "modern" JS techniques are cool, but often, the complexity is not worth it.
Also, let's not forget that web browsers are already good at taking HTML/CSS and showing it in your screen. Somehow, we decided it was better to make all your users waste CPU cycles to do the same with Javascript and a Virtual DOM (but only after 10MB of JS files have finished downloading)
[0] https://developers.cloudflare.com/workers/examples/return-ht...
HOWl is a good idea.. either it will catch on and make web development fun again, or it will at least force the JS ecosystem to wake up and fix its terrible tooling and bloat.
For REST APIs one can use Nest.js or so to get a similar experience.
Earlier quoted context omitted.
From the article: > This is, unfortunately, part of the culture of front end development right now: sky-high levels of complexity are tolerated in application frameworks, in build tool chains, in deployment models and so on, and, when problems arise due to all this complexity, more complexity is often offered as the answer. > "Simple" is disparaging and "sophisticated" is high praise. So, rather.
Seconded. There was a series of similar Twitter discussions when a popular JavaScript "influencer" published an article[0] on how they built their website. The amount of complexity that is self-inflicted in the said article was obviously enormous for proponents of MPAs. However the JS community mostly echoed that the complexity was absolutely within norm. The cultural chasm between JS developers and people who push f…
It seems the backend community mostly echoes that the complexity is absolutely within norm. The cultural chasm between backend developers and people who push for simplicity is huge. And the refusal to admit the unnecessary complexity is nothing short of Stockholm Syndrome... imho