7 ms·

> API-only - the only technology we should be using to create web UI is JavaScript. Using native technologies is always the most flexible, scalable, and simple

> API-only - the only technology we should be using to create web UI is JavaScript. Using native technologies is always the most flexible, scalable, and simple solution in the long run. Check out Vite if you don't know where to start. Thanks. I'll pass on that one. Nevertheless, both rage and iodine seem like pretty cool projects FWIW.

KronisLV 3y ago
>> API-only - the only technology we should be using to create web UI is JavaScript. > Thanks. I'll pass on that one. I don't know, there's definitely some merit in separating your front end from your back end - at least that's the impression I got after struggling on JSF/PrimeFaces Java projects for a few years, because at least with a well defined API and no magic behind the scenes everything becomes more observable and easier to reason about, with fewer bugs. Some might prefer TypeScript or something else to JavaScript, but I think the point still stands. In addition, this lets migrate or change everything piece by piece, as long as the interface isn't broken: - different frameworks (let's say from Spring to Spring Boot, or from the old ASP.NET to the new variety that runs on Linux, or Rails to Rage or vice versa) - different languages (if someone decided to take their PHP Laravel solution and migrate to Ruby with Ruby on Rails, or Python, or anything else) - deprecated technologies can also be handled gradually (e.g. supporting an EOL AngularJS solution while developing a new front end in Vue/React/Angular/whatever) As for the reason for those migrations, sometimes code just rots due to neglect, other times you need features that aren't available in your solution of choice (for example, pre-made UI components, like PrimeVue, PrimeReact and PrimeNG have; or maybe needing to have responsive maps in the app). In addition, you can also deploy your front end and back end separately, have different rules for the reverse proxy in front of them, suddenly have a very clear view of where your static assets are, might have all of the benefits of a SPA and PWA (if needed), anyone can integrate with your API if needed/allowed because you've hopefully built it to actually be usable and so on. Plus, your front end can talk to multiple different APIs, so if you have multiple teams working on those, suddenly that is a solved issue for you as well. That said, it's also a lot of work because SPA and adjacent approaches bring a lot of complexity into the mix and something like Vue/React/Angular and its ecosystem will bring its own pain points and things you have to learn. If all you need is a bunch of forms, then pretty much anything will do fine and SSR is a good choice. If you need an "app" on the web, then HTML/JS/CSS isn't a very good choice to begin with (historically not built for that; though I don't think there are actually good choices, same as with desktop software), but those SPA solutions will see you pretty far.
- Draiken 3y ago
  Use HTMX and you'll be surprised how much you don't need JS for (or to be more accurate, very little JS). Rails especially is very good for this with partials. Use ERBs (or Haml, Slim, etc) and it's an absolute bliss with the added benefit of easy caching. Stop duplicating state. Stop duplicating logic. Maybe in the future when your app needs 5 different clients, it makes sense to only have an API. But let's not pretend that should be the default! I still cry every time I see a new application using GraphQL to have literally one client which is simply serving HTML with a bloated JS framework. The whole premise of it was to be flexible for multiple frontends. Come on folks, YAGNI.
  - egeozcan 3y ago
    I used HTMX since the intercooler days [0] but the stuff you can make is rather limited. Also you still need the JS to deal with a11y things like expanded state (or hyperscript, apparently). If you have a lot of components to implement, everything requires thinking. Example: You want to add a repeat field to a form. Easy, get the input from an endpoint, and append. Done? No, how do you remove a field? Add a line of JS, simple! Drag and drop if the order needs to change? Let's add a dependency! [1] I really love it for simple applications though. Resist implementing a complicated menu, live notifications, an editable data-table and such non-web-native things and you can create the fastest CRUD app ever. And you will need another client (don't YAGNI me on this one, burned too many times by people not caring about endpoint design), but that's not really an issue if your view model does not contain non-public data (it shouldn't), as you can convert it to JSON at the same endpoint (respect the accepts header) and call it an API. [0]: https://intercoolerjs.org/ https://intercoolerjs.org/ [1]: https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/
  - ecshafer 3y ago
    Rails with turbo and stimulus is amazing. Very similar to htmx and phoenix liveview. Stimulus lets you make a really minimal web framework for ui elements that are mostly defined as ruby components, and turbo lets you to use erb without whole page reloads. Whole responsive web apps with a dozen lines of js, its great.
Draiken 3y ago
Yeah they lost me there. That's so silly. Absolute takes like that are why we're in this mess we are in today. Don't make me think! Just follow the trend.
jhfgloria 3y ago
Came here just to say your first 2 sentences.
krmbzds 3y ago
I think DHH makes a good argument in Rails World 2023 Opening Keynote; in particular "Fed Pauses Rate Hikes But Stiffens Long-Term Outlook" slide. Check it out: https://youtu.be/iqXjGiQ_D-A?t=665 https://youtu.be/iqXjGiQ_D-A?t=665

KronisLV 3y ago

>> API-only - the only technology we should be using to create web UI is JavaScript. > Thanks. I'll pass on that one. I don't know, there's definitely some merit in separating your front end from your back end - at least that's the impression I got after struggling on JSF/PrimeFaces Java projects for a few years, because at least with a well defined API and no magic behind the scenes everything becomes more observable and easier to reason about, with fewer bugs. Some might prefer TypeScript or something else to JavaScript, but I think the point still stands. In addition, this lets migrate or change everything piece by piece, as long as the interface isn't broken: - different frameworks (let's say from Spring to Spring Boot, or from the old ASP.NET to the new variety that runs on Linux, or Rails to Rage or vice versa) - different languages (if someone decided to take their PHP Laravel solution and migrate to Ruby with Ruby on Rails, or Python, or anything else) - deprecated technologies can also be handled gradually (e.g. supporting an EOL AngularJS solution while developing a new front end in Vue/React/Angular/whatever) As for the reason for those migrations, sometimes code just rots due to neglect, other times you need features that aren't available in your solution of choice (for example, pre-made UI components, like PrimeVue, PrimeReact and PrimeNG have; or maybe needing to have responsive maps in the app). In addition, you can also deploy your front end and back end separately, have different rules for the reverse proxy in front of them, suddenly have a very clear view of where your static assets are, might have all of the benefits of a SPA and PWA (if needed), anyone can integrate with your API if needed/allowed because you've hopefully built it to actually be usable and so on. Plus, your front end can talk to multiple different APIs, so if you have multiple teams working on those, suddenly that is a solved issue for you as well. That said, it's also a lot of work because SPA and adjacent approaches bring a lot of complexity into the mix and something like Vue/React/Angular and its ecosystem will bring its own pain points and things you have to learn. If all you need is a bunch of forms, then pretty much anything will do fine and SSR is a good choice. If you need an "app" on the web, then HTML/JS/CSS isn't a very good choice to begin with (historically not built for that; though I don't think there are actually good choices, same as with desktop software), but those SPA solutions will see you pretty far.

Draiken 3y ago
Use HTMX and you'll be surprised how much you don't need JS for (or to be more accurate, very little JS). Rails especially is very good for this with partials. Use ERBs (or Haml, Slim, etc) and it's an absolute bliss with the added benefit of easy caching. Stop duplicating state. Stop duplicating logic. Maybe in the future when your app needs 5 different clients, it makes sense to only have an API. But let's not pretend that should be the default! I still cry every time I see a new application using GraphQL to have literally one client which is simply serving HTML with a bloated JS framework. The whole premise of it was to be flexible for multiple frontends. Come on folks, YAGNI.
- egeozcan 3y ago
  I used HTMX since the intercooler days [0] but the stuff you can make is rather limited. Also you still need the JS to deal with a11y things like expanded state (or hyperscript, apparently). If you have a lot of components to implement, everything requires thinking. Example: You want to add a repeat field to a form. Easy, get the input from an endpoint, and append. Done? No, how do you remove a field? Add a line of JS, simple! Drag and drop if the order needs to change? Let's add a dependency! [1] I really love it for simple applications though. Resist implementing a complicated menu, live notifications, an editable data-table and such non-web-native things and you can create the fastest CRUD app ever. And you will need another client (don't YAGNI me on this one, burned too many times by people not caring about endpoint design), but that's not really an issue if your view model does not contain non-public data (it shouldn't), as you can convert it to JSON at the same endpoint (respect the accepts header) and call it an API. [0]: https://intercoolerjs.org/ https://intercoolerjs.org/ [1]: https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/
- ecshafer 3y ago
  Rails with turbo and stimulus is amazing. Very similar to htmx and phoenix liveview. Stimulus lets you make a really minimal web framework for ui elements that are mostly defined as ruby components, and turbo lets you to use erb without whole page reloads. Whole responsive web apps with a dozen lines of js, its great.

Draiken 3y ago

Yeah they lost me there. That's so silly. Absolute takes like that are why we're in this mess we are in today. Don't make me think! Just follow the trend.

jhfgloria 3y ago

Came here just to say your first 2 sentences.

krmbzds 3y ago

I think DHH makes a good argument in Rails World 2023 Opening Keynote; in particular "Fed Pauses Rate Hikes But Stiffens Long-Term Outlook" slide. Check it out: https://youtu.be/iqXjGiQ_D-A?t=665 https://youtu.be/iqXjGiQ_D-A?t=665