4 ms·

Yeah. The JS world is still so hung up about fat clients having all the control that it's missing all the interesting stuff happening in the server world. Rails

by pier25 3y ago

Yeah. The JS world is still so hung up about fat clients having all the control that it's missing all the interesting stuff happening in the server world. Rails Hotwire, Phoenix Liveviews, Laravel Livewire, etc. These solutions can solve 80% of your front end with minimal JS and almost no DX complexity.

TheCapeGreek 3y ago
Preach! I'm still keen to learn more on the Inertia side of Laravel, but Livewire (and especially with Filament in the mix) just feels insanely productive as a Laravel dev.
metadaemon 3y ago
Complexity has to exist somewhere, either in the engineer's hands, or swept under the rug for the framework to perform its magic on (really thinking about the Rails ecosystem here). When things go wrong, it's nicer, in my opinion, to have more control, especially in this fast paced clients-want-it-now environment.
- bob1029 3y ago
  In my experience, the complexity with most frontend development is accidental by way of splitting state between client & server. If you manage to consolidate nearly all state to the server, complexity reduces by an entire dimension. There is nothing to synchronize anymore. You don't need these universes of delta-detection tools, frameworks, protocols, etc. In most of our modern SSR apps, the only state the client needs to hold onto is a session token. If we find the client has a wrong session token, correcting this is quite simple. Everything else happens on the server. Certainly there are holes with SSR (latency), but we haven't run into a real-world scenario where this actually matters enough to introduce entire new universes of hell into our lives.
- worthless-trash 3y ago
  > Complexity has to exist somewhere, What is the complexity you are talking about here, is this the human (programmers) understanding of the system or the design of a complex system itself ?
- toddmorey 3y ago
  Yes. Definitely been bit here with ORMs and custom query languages.
- pier25 3y ago
  > especially in this fast paced clients-want-it-now environment But wouldn't a solution that makes you more productive allow you to deliver faster? That's what Livewire/Hotwire/etc are trying to achieve. Make developers more productive. When going full on SPA there's so much complexity you need to solve. Crossing the client/server barrier with APIs, managing state in the client, etc.
deleted 3y ago
[deleted]
ng12 3y ago
Why do people keep hiring front-end specialists, in that case?
- dboreham 3y ago
  Because a) they're available and b) people think it's a black art.
  - evilduck 3y ago
    c) backend devs often proudly hold contempt for front end work and do the job poorly
    - esafak 3y ago
      They don't want to get involved with tech that goes out of date every year.
      - evilduck 3y ago
        I love that trope honestly. It's a great way to discover bad developers without having to test them first.
      - mikebelanger 3y ago
        As a primarily frontend-developer, I can attest to this sentiment. I should add that most backend devs I know understand the basics of HTML, CSS and Javascript, but they're less interested in learning new framework/library/template system constantly. I have to admit, I share that attitude. It's funny how webcomponents alone are touted as an "alternative" to a framework, despite only being one component (no pun intended) of something that solves the problem of UI state-synchronization on the browser. A better comparison would be comparing a combination of custom elements, server-side rendered HTML, and proxy objects to some SSR framework like NextJS, Remix, etc.
- pier25 3y ago
  Because front end specialists only think about the front end. The tide is slowly turning though with Next, SvelteKit, Remix, etc. But still these frameworks are basically just rendering HTML and going full on fat client which is overkill for 80% of interactivity in web app but adds a lot of unnecessary complexity.
klysm 3y ago
Is it not just the same tradeoff space we've been exploring since the beginning of UIs about how thin the UI is? It's not like putting stuff on the server side via livewire doesn't have strong disadvantages around latency etc.
- pier25 3y ago
  > It's not like putting stuff on the server side via livewire doesn't have strong disadvantages around latency etc. It's exactly the same latency that a request to an API will have. Obviously Livewire is not a good option for interactivity that happens exclusively in the client.
  - klysm 3y ago
    > It's exactly the same latency that a request to an API will have. Every interaction in a livewire type system requires a round trip - that's not true for SPAs. Let's say I'm developing a node based editing UI with drag and drop that lets me connect things. How on earth are you going to make that work with livewire?
    - pier25 3y ago
      Obviously Livewire wouldn't be a good fit for that (extremely rare) use case.
      - 0xblinq 3y ago
        In those cases you use alpine, and do the interactivity on the client side.
    - 0xblinq 3y ago
      > Every interaction in a livewire type system requires a round trip You’re wrong on this. You’d use Alpine and do the interactivity client side. If you don’t miss use the tool, Livewire is supposed to reach to the server in the same situations an SPA would reach to the server (updating or refreshing server state)
toddmorey 3y ago
Isn't it possible that both the frontend and backend are maturing & more capable? Isn't that what we want? I've built some feature-rich FE apps that read and write to dbs & object stores with no servers needed! Very portable, the only install step is to upload a few files. They can be run right from a simple CDN. And they are super fast. Most FE devs I know are actually familiar with Hotwire and friends but to them those stacks would add DX complexity. I think sometimes people say "complexity" when they just mean "unfamiliar". Both FE and BE can be way overly complex, but neither needs to be.
- pier25 3y ago
  > I think sometimes people say "complexity" when they just mean "unfamiliar". I do mean actual complexity. With something like Hotwire/Livewire you don't need APIs anymore. You also can scrap client-side fetch() code and state management. There are some features that will still need some client JS but these will be a minority of use cases (if at all).
candiddevmike 3y ago
You either write HTML in JavaScript or write JavaScript in HTML. Personally, I would rather write everything in JavaScript/TypeScript than sprinkle syntactic sugar over HTML.
- pier25 3y ago
  No offense, but you're thinking from the JS bubble. Yes, ultimately you need JS to interact with the DOM but if you look at eg Livewire the orchestration is in the server. I'd be happy to use a similar fullstack solution in JS/TS but afaik it doesn't exist. And it doesn't exist because the JS world is still hung up on full on fat reactive clients which are overkill for the immense majority of use cases.
  - tomjakubowski 3y ago
    Liveview and similar frameworks are cool but not great for everything. It's not easy to build an 'offline first' application with it, for example
    - pier25 3y ago
      I agree. These solution are not meant to solve all the front end needs. But they can solve the majority of it (forms, modals with dynamic content, filtered lists, etc).
    - 0xblinq 3y ago
      Nothing is great for everything.
  - pixelsort 3y ago
    > I'd be happy to use a similar fullstack solution in JS/TS but afaik it doesn't exist. If you mean, a fully TypeScript full stack solution then you might be correct. I wouldn't know because I tried Deno earlier this year and it wasn't great. If you mean, a full stack solution that utilizes TS to for both the API and for the frontend then that is a much easier find. Vercel's Next.js provides this out-of-the-box and various other full stack starters and boilderplates exist. I recently built one using PgTyped and typescript-rest.

by pier25 3y ago

TheCapeGreek 3y ago

Preach! I'm still keen to learn more on the Inertia side of Laravel, but Livewire (and especially with Filament in the mix) just feels insanely productive as a Laravel dev.

metadaemon 3y ago

Complexity has to exist somewhere, either in the engineer's hands, or swept under the rug for the framework to perform its magic on (really thinking about the Rails ecosystem here). When things go wrong, it's nicer, in my opinion, to have more control, especially in this fast paced clients-want-it-now environment.

bob1029 3y ago
In my experience, the complexity with most frontend development is accidental by way of splitting state between client & server. If you manage to consolidate nearly all state to the server, complexity reduces by an entire dimension. There is nothing to synchronize anymore. You don't need these universes of delta-detection tools, frameworks, protocols, etc. In most of our modern SSR apps, the only state the client needs to hold onto is a session token. If we find the client has a wrong session token, correcting this is quite simple. Everything else happens on the server. Certainly there are holes with SSR (latency), but we haven't run into a real-world scenario where this actually matters enough to introduce entire new universes of hell into our lives.
worthless-trash 3y ago
> Complexity has to exist somewhere, What is the complexity you are talking about here, is this the human (programmers) understanding of the system or the design of a complex system itself ?
toddmorey 3y ago
Yes. Definitely been bit here with ORMs and custom query languages.
pier25 3y ago
> especially in this fast paced clients-want-it-now environment But wouldn't a solution that makes you more productive allow you to deliver faster? That's what Livewire/Hotwire/etc are trying to achieve. Make developers more productive. When going full on SPA there's so much complexity you need to solve. Crossing the client/server barrier with APIs, managing state in the client, etc.

deleted 3y ago

[deleted]

ng12 3y ago

Why do people keep hiring front-end specialists, in that case?

dboreham 3y ago
Because a) they're available and b) people think it's a black art.
- evilduck 3y ago
  c) backend devs often proudly hold contempt for front end work and do the job poorly
  - esafak 3y ago
    They don't want to get involved with tech that goes out of date every year.
    - evilduck 3y ago
      I love that trope honestly. It's a great way to discover bad developers without having to test them first.
    - mikebelanger 3y ago
      As a primarily frontend-developer, I can attest to this sentiment. I should add that most backend devs I know understand the basics of HTML, CSS and Javascript, but they're less interested in learning new framework/library/template system constantly. I have to admit, I share that attitude. It's funny how webcomponents alone are touted as an "alternative" to a framework, despite only being one component (no pun intended) of something that solves the problem of UI state-synchronization on the browser. A better comparison would be comparing a combination of custom elements, server-side rendered HTML, and proxy objects to some SSR framework like NextJS, Remix, etc.
pier25 3y ago
Because front end specialists only think about the front end. The tide is slowly turning though with Next, SvelteKit, Remix, etc. But still these frameworks are basically just rendering HTML and going full on fat client which is overkill for 80% of interactivity in web app but adds a lot of unnecessary complexity.

klysm 3y ago

Is it not just the same tradeoff space we've been exploring since the beginning of UIs about how thin the UI is? It's not like putting stuff on the server side via livewire doesn't have strong disadvantages around latency etc.

pier25 3y ago
> It's not like putting stuff on the server side via livewire doesn't have strong disadvantages around latency etc. It's exactly the same latency that a request to an API will have. Obviously Livewire is not a good option for interactivity that happens exclusively in the client.
- klysm 3y ago
  > It's exactly the same latency that a request to an API will have. Every interaction in a livewire type system requires a round trip - that's not true for SPAs. Let's say I'm developing a node based editing UI with drag and drop that lets me connect things. How on earth are you going to make that work with livewire?
  - pier25 3y ago
    Obviously Livewire wouldn't be a good fit for that (extremely rare) use case.
    - 0xblinq 3y ago
      In those cases you use alpine, and do the interactivity on the client side.
  - 0xblinq 3y ago
    > Every interaction in a livewire type system requires a round trip You’re wrong on this. You’d use Alpine and do the interactivity client side. If you don’t miss use the tool, Livewire is supposed to reach to the server in the same situations an SPA would reach to the server (updating or refreshing server state)

toddmorey 3y ago

Isn't it possible that both the frontend and backend are maturing & more capable? Isn't that what we want? I've built some feature-rich FE apps that read and write to dbs & object stores with no servers needed! Very portable, the only install step is to upload a few files. They can be run right from a simple CDN. And they are super fast. Most FE devs I know are actually familiar with Hotwire and friends but to them those stacks would add DX complexity. I think sometimes people say "complexity" when they just mean "unfamiliar". Both FE and BE can be way overly complex, but neither needs to be.

pier25 3y ago
> I think sometimes people say "complexity" when they just mean "unfamiliar". I do mean actual complexity. With something like Hotwire/Livewire you don't need APIs anymore. You also can scrap client-side fetch() code and state management. There are some features that will still need some client JS but these will be a minority of use cases (if at all).

candiddevmike 3y ago

You either write HTML in JavaScript or write JavaScript in HTML. Personally, I would rather write everything in JavaScript/TypeScript than sprinkle syntactic sugar over HTML.

pier25 3y ago
No offense, but you're thinking from the JS bubble. Yes, ultimately you need JS to interact with the DOM but if you look at eg Livewire the orchestration is in the server. I'd be happy to use a similar fullstack solution in JS/TS but afaik it doesn't exist. And it doesn't exist because the JS world is still hung up on full on fat reactive clients which are overkill for the immense majority of use cases.
- tomjakubowski 3y ago
  Liveview and similar frameworks are cool but not great for everything. It's not easy to build an 'offline first' application with it, for example
  - pier25 3y ago
    I agree. These solution are not meant to solve all the front end needs. But they can solve the majority of it (forms, modals with dynamic content, filtered lists, etc).
  - 0xblinq 3y ago
    Nothing is great for everything.
- pixelsort 3y ago
  > I'd be happy to use a similar fullstack solution in JS/TS but afaik it doesn't exist. If you mean, a fully TypeScript full stack solution then you might be correct. I wouldn't know because I tried Deno earlier this year and it wasn't great. If you mean, a full stack solution that utilizes TS to for both the API and for the frontend then that is a much easier find. Vercel's Next.js provides this out-of-the-box and various other full stack starters and boilderplates exist. I recently built one using PgTyped and typescript-rest.