4 ms·
If you need any kind of interactivity on the frontend, but are more comfortable with the backend, I would suggest looking at Phoenix LiveView [0] or a similar s
by jonnycat 4y ago
If you need any kind of interactivity on the frontend, but are more comfortable with the backend, I would suggest looking at Phoenix LiveView [0] or a similar server-rendered HTML technology for your language of your choice [1].
In short, these solutions take JavaScript out of the mix entirely and basically let you deal with a single logical "app", rather than a separate frontend & backend.
[0] https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view
[1] https://github.com/dbohdan/liveviews https://github.com/dbohdan/liveviews
- anakaine 4y agoA single logical app sounds great. There is great freedom and power in simplicity for small concerns.
- heeton 4y agoSeconding this. I've been using LiveView in production for ~18 months now, on a couple of projects. Hugely simplifies the overall stack. Combine with TailwindCSS, TailwindUI.com, and you have some very powerful tooling at a low development cost.
- mercer 4y agoYou or your company hiring, by any chance. I've been using that exact stack for a few years now, and Elixir+LV jobs are hard to come by :P. I probably need to focus more on 'vanilla' back- and frontend stuff, but man has it been fun so far! Definitely made me enjoy my work more.
- atonse 4y agoWe are betting big on moving to liveview and are hiring. We run a half dozen elixir apps in the healthcare and research sectors. people@polkadotskysoftware.com
- worker_person 4y agoHow stable is it? I've been screwed over twice by Angular, RXJS, etc. Every month we had to redo most of our work as the community kept deciding on new directions of correctness.
- RhodesianHunter 4y agoCheck the second link above. There are frameworks for this pattern in most languages, many with many years of effort into them. I can personally recommend Vaadin.
- egeozcan 4y agoThe web-components backed vaadin or vaadin flow (JSF-like, all-Java)?
- anonyfox 4y agoAfter having learned & used all the major frontend frameworks (starting from jquery, backbone, ... react, svelte) I am now firmly in the camp of LiveView. No more "REST APIs"/fetch calls, SSR by default, no javascript alltogether, very simple programming model once you "get" it.
- sam0x17 4y agoIt's very cool. I'm actually working on a web framework called Bolts in the Rust ecosystem that will offer LiveView-like functionality, born from my hatred of modern js frameworks.
- bluehatbrit 4y agoI'm in the same camp, I've slowly "regressed" backwards from overcomplicated SPA's back to server side rendering. When LiveView hit and I was already using Phoenix it was just perfect. It's a slight embelishment on top of multi-page server rendered pages which gives all the benefits I need and nothing more. If I _really_ need something to be driven by the frontend like a transition then I'll use Alpine.js. For CSS I tend to use tailwindcss / tailwindui because I know it well and it doens't need npm. If I didn't know tailwind I'd probably look at something like bootstrap or something I can build on top of with vanilla css.
- omniscient_oce 4y agoHow do you deal with more complex/dynamic forms? As someone who learnt frontend mostly in React I've always struggled wrapping my head around how you would do that with server-side rendering. For example: 1) selecting a checkbox alters other fields in the form 2) validation that needs to hit the backend and then present warnings/errors to user 3) field arrays -> sending back a list of fields
- bluehatbrit 4y agoLiveView can handle that pretty well, you can setup a click or validation handler for your live view / component. It then hits the handler function on the backend and you can have the component updated in place. Since it only sends the diffs down it's pretty efficient on the round trip, at least not something to worry about compared to the hundreds of api calls most SPA's will make. So the flow is 1) click the checkbox 2) call sent across the open socket 3) backend does it's logic to figure out what it needs to do 4) backend returns the small diff of changes 5) frontend alters dom.
- mattbrewsbytes 4y agoIts actually recommended with Liveview for pure client side stuff (hiding form elements, etc.) to do that in the client. There are hooks to do such things. Granted I've only built admin-y tools that are pure liveview but did hear/read there are options for client side JS. Just because it can be done 100% server side doesn't mean it should be, especially if its driven out of a "look, no JS!" type of approach.
- graboid 4y agoThis is really cool and makes me want to learn Elixir. Staying in one language for frontend and backend is just so appealing. To my knowledge, the other option to achieve that would be having something like Blazor WASM or Rust Yew that compiles to WebAssembly to have a client-side app a la React/Vue/Svelte. I wonder which of these approaches will end up be more prevalent in the future. To me it seems like compiling something React-like to WASM might be more attractive, because you can stay in your backend language, but ditch the permanent websocket connection.
- kolanos 4y agoI came across something that is somewhere in the middle. Maybe a happy medium? It's a Python library called IDOM [0]. Best way I can explain it is that it is server-side bindings for React, where state and diffs are passed back and forth for you via web sockets. You implement your components in Python with a React-like API and IDOM builds the equivalent React components for you on the client-side and then wires up your server-side state handlers. It is also web framework agnostic, works with all the most popular ASGI web frameworks in Python. Admittedly it is still a bit raw. But seemed like a really interesting concept when I was looking for LV equivalents. [0]: https://idom-docs.herokuapp.com/docs/index.html https://idom-docs.herokuapp.com/docs/index.html
- zem 4y agothere's also justpy, uses vue and is closer to liveview in that it generates all the frontend code for you. https://justpy.io/ https://justpy.io/
- dhucerbin 4y agoI've been involved in two projects that use LiveView and both of them have similar path. First, engineers build application using just LiveView and it works just fine. You click a link you have table with your data, you click button you have filtered table, click another link you see a chart. But then UX concerns are raised from PO/PM/users. Users find it jarring that they need to wait a little to see a loading spinner on clicked button. And we litter our views with some alpine.js DSL in attributes or load stimulus controllers. Some stuff is moved to hooks and kept in ad-hoc global variables. Finally, most of the live views evolve into single html node, with mini-SPA written in some lightweight javascript framework. And everything is wired with phoenix websocket. LiveView is still a fantastic and very productive tool to quickly create applications but I'm not sure if it scales to users expectations.
- lewantmontreal 4y agoThanks for writing up your experience. I’ve been wondering how well liveview works when interacting with the page with variable latency. I tried to search some sites made with liveview in the past, but couldnt find any apart from some official examples.