4 ms·

> he thing that changed to make frontend development improve dramatically was hash based routing with ajax... I think that what's changed is simply that people

by Udik 7y ago

> he thing that changed to make frontend development improve dramatically was hash based routing with ajax... I think that what's changed is simply that people realized that it's way less messy to use the backend only as a data source (with ajax calls), and leave everything else to the frontend. The cognitive overhead of having the server producing html with some implicit state, then updating that state interactively, and then losing everything again by posting the whole page to the server, was simply unbearable. When I started building web applications in 2004 I had some experience in writing desktop apps: I simply created a js library to create and destroy UI elements, and wrote "desktop" apps running in the browser.

mercer 7y ago
While I agree in theory, in practice I find that the frontend still has all sorts of warts that don't quite make it a great solution (yet). I mean, it's better than having to maintain both server- and client-side logic and state (and having to sync all that), and definitely better than the days where we also had to manage DOM diffing manually. But I still get headaches from the NPM/node ecosystem, the build steps, having to decide whether logic goes on the client, server, or both, and to some extent javascript itself. And you can never fully let go of the server-side of things. I'm very intrigued by the alternative idea of moving (almost) everything to the backend, and maintaining the dynamic bits by sending all events to the server and sending back diffs based on that which update the page. Phoenix'/Elixir's LiveView made some great progress in this area, and from what I hear other ecosystems are experimenting with the same thing. It's not a panacea: if you need offline functionality you're gonna have to deal with js and everything that comes with it. But in many projects that's not a deal-breaker, and in practice the approach actually leads to smaller payloads sent between client and server, and significantly simpler codebases.
- imtringued 7y ago
  Keeping the view state in the server is what Java Server Faces did and trust me you don't want to repeat that same mistake.
  - mercer 7y ago
    Here's an interesting response from Elixir's creator (and contributor to LiveView) specifically about JSF: https://elixirforum.com/t/phoenix-liveview-is-now-live/20889/73 https://elixirforum.com/t/phoenix-liveview-is-now-live/20889... I don't know JSF so I can't really argue this point, but I'd really love to hear what you think about the argument Jose put forward and where you might disagree!
  - chessturk 7y ago
    I kept a real nasty implementation of this alive for the last two years while building a REST api and React frontend to replace it. I learned a good lesson, though: no logic in template files! Ever!
LandR 7y ago
I've recentlt started working on a project where they store data / state in the ids of dom objects. Sometimes even something like dash separated strings that need to then be parsed. I come from having done pretty much no Web development and this seems like a hateful way to do development.
- gedy 7y ago
  It is, and basically the selling point of modern front end practices like APIs, state managed only in JS, SPAs, etc. Maybe this tech is overused in some cases, but it's vastly better than the "JavaScript Sauce" type development you describe.

by Udik 7y ago

mercer 7y ago

While I agree in theory, in practice I find that the frontend still has all sorts of warts that don't quite make it a great solution (yet). I mean, it's better than having to maintain both server- and client-side logic and state (and having to sync all that), and definitely better than the days where we also had to manage DOM diffing manually. But I still get headaches from the NPM/node ecosystem, the build steps, having to decide whether logic goes on the client, server, or both, and to some extent javascript itself. And you can never fully let go of the server-side of things. I'm very intrigued by the alternative idea of moving (almost) everything to the backend, and maintaining the dynamic bits by sending all events to the server and sending back diffs based on that which update the page. Phoenix'/Elixir's LiveView made some great progress in this area, and from what I hear other ecosystems are experimenting with the same thing. It's not a panacea: if you need offline functionality you're gonna have to deal with js and everything that comes with it. But in many projects that's not a deal-breaker, and in practice the approach actually leads to smaller payloads sent between client and server, and significantly simpler codebases.

imtringued 7y ago
Keeping the view state in the server is what Java Server Faces did and trust me you don't want to repeat that same mistake.
- mercer 7y ago
  Here's an interesting response from Elixir's creator (and contributor to LiveView) specifically about JSF: https://elixirforum.com/t/phoenix-liveview-is-now-live/20889/73 https://elixirforum.com/t/phoenix-liveview-is-now-live/20889... I don't know JSF so I can't really argue this point, but I'd really love to hear what you think about the argument Jose put forward and where you might disagree!
- chessturk 7y ago
  I kept a real nasty implementation of this alive for the last two years while building a REST api and React frontend to replace it. I learned a good lesson, though: no logic in template files! Ever!

LandR 7y ago

I've recentlt started working on a project where they store data / state in the ids of dom objects. Sometimes even something like dash separated strings that need to then be parsed. I come from having done pretty much no Web development and this seems like a hateful way to do development.

gedy 7y ago
It is, and basically the selling point of modern front end practices like APIs, state managed only in JS, SPAs, etc. Maybe this tech is overused in some cases, but it's vastly better than the "JavaScript Sauce" type development you describe.