Breaking up with JavaScript front ends

Post by sodapopcan » Sat, Dec 10, 2022, 11:57 PM UTC

0xblinq wrote: post #150

cphoover wrote: post #135

Earlier quoted context omitted.

My problem with liveview IMHO is that it requires an active internet connection and doesn't have offline support, which is a step in the wrong direction in terms of UI performance to me. It makes sense for a subset of applications that require connectivity but many apps or tools should be able to work offline or without a constant connection.

Livewire is intended to be used where you’d otherwise need to do an API call anyway. It is not intended to handle every single click and toggle and key press. You still do that on the front end, usually with Alpine. It is a way to avoid writing backend APIs. If you’re sending every click or every key press then it’s not the tools fault. I agree though, that this should be better explained in their docs.

Post by Rauchg » Sun, Dec 11, 2022, 12:00 AM UTC

CharlieDigital wrote: post #197

arcturus17 wrote: post #171

Earlier quoted context omitted.

I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing. I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable. Perhaps that's one dependency too many for some?

Next.js is really bad, IMO and perpetuates more bad practices. Both Target.com and Walmart.com are Next.js apps. Both utilize SSR to render the pages (view the markup in the network tab). Both then STILL send the full data model to the UI (check the `__NEXT_DATA__` on Walmart.com and `__TGT_DATA__` on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to A…

Post by crooked-v » Sun, Dec 11, 2022, 12:01 AM UTC

TranquilMarmot wrote: post #86

chiefalchemist wrote: post #68

Earlier quoted context omitted.

Yes "app-like-ness" when that's appropriate. But a lot of the web isn't that. Yet devs / agencies are using a sledgehammer (e.g., React) when a Phillips head screwdriver is what's need. Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).

I think the basic divide is something like "CRUD forms" vs "interactive applications". I've built basic CRUD forms with ASP.NET MVC. I've built them with Rails. I've built them with React (+ a hundred random libraries). I've also built interactive "apps" in those languages. Looking back, the amount of "interactivity" that React adds to a CRUD form is NOT worth the added complexity. But! Right now my dayjob is creatin…

Post by papito » Sun, Dec 11, 2022, 12:06 AM UTC

ostenning wrote: post #120

The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "librar…

Post by wruza » Sun, Dec 11, 2022, 12:09 AM UTC

wefarrell wrote: post #170

jokoon wrote: post #45

Why can't anybody talk about the fact that HTML was not designed for being dynamic? Isn't there any format that is a real alternative to HTML, which is truly interactive, lighter than the DOM, use text as a mediu, is multi usage and platform agnostic, can use whatever scripting language, and be easily rendered? It's not another new format, it's just that a new format is needed to make things simpler. I have zero pati…

No markup format will support interactivity well, you need a full scripting language with all of the standard features. I don’t think it’s possible to couple the interactivity and visual layout in a single language and have it make sense. We can certainly do better than JavaScript, HTML and CSS but I think there will still need to be at least two languages to describe layout and interactivity.

  i = 1
  def click(event):
    i += 1

  g.Window(
    g.Frame(title=“Hello”,
      g.VBox(
        spacing=10,
        g.Label(
          “i = %d” % i,
          expand=True
        ),
        g.Button(“click me”,
          click=click,
        )
      )
    )
  )