11 ms·

Back-end languages are coming to the front-end

394 points by deznu 5y ago

sfvisser 5y ago
I don't think this is really about programming languages. The world of software (and specifically everything network based) is oscillating between fat servers and fat client every few years or so. To me the innovation seems to be orthogonal to this cycle and may actually be accelerated by this continuous change in perspective. Which is good!
- streamofdigits 5y ago
  if the hardware landscape settles for a while (in terms of the capabilities of devices and networks - which is not a crazy precondition given Moore's law has run its course) then it may be that these server/client pendulum oscillations get damped around an "optimum" of sorts. An optimum defined both in terms of what it enables users to do with software but also how easy it is for developers to deliver it. Since simple is better than complex it feels that any architecture that does not require two distinct ecosystems might have an advantage (all else being equal).
- dnautics 5y ago
  for liveview, it's not at all about "fat servers"; the overhead of maintaining a socket over erlang is not that much (maybe a few K -- the base erlang process overhead is ~400 words), so you're going to almost certainly be doing better than, say ruby (via hotwire) which isn't really designed from the ground up to hold onto the websocket. By persisting the connection with a stateful system, you're going to be avoiding a whole ton of computation that just gets thrown away with stateless HTTP requests. So it's probably in the end a lighter server than most web backends. This is the irony, Erlang/Elixir, despite being functional language with less and highly restricted access to stateful side effects, is really FANTASTIC at safely holding onto state and persisting it for the user, and making that model digestible for the developer.
istjohn 5y ago
Anyone have good experiences with a LiveView-style Python framework?
- awesomeweb 5y ago
  You can try Django Unicorn (https://www.django-unicorn.com https://www.django-unicorn.com) if Django is your cup of tea. Have used it in production and it works great. Author is also very responsive to bugfixes / feature requests.
phoe-krk 5y ago
See CLOG, the Common Lisp Omnificent GUI - a recent project which is an implementation of this paradigm. https://www.reddit.com/r/lisp/comments/s1itqi/the_common_lisp_omnificent_gui_online_lisp/ https://www.reddit.com/r/lisp/comments/s1itqi/the_common_lis... https://www.reddit.com/r/lisp/comments/sd9wf1/clog_builder_cl_web_3_awesome_lang_awesome_tool/ https://www.reddit.com/r/lisp/comments/sd9wf1/clog_builder_c...
- oschvr 5y ago
  Unfortunate naming.. "I CLOGed my frontend"
  - capableweb 5y ago
    When would you use the name of a project like that? "I Reacted my frontend"? "I AngularJSed my frontend"? "I VueJSed my frontend"? I just don't see it.
    - fayedev 5y ago
      I'd say I Vued my frontend.
  - tasha0663 5y ago
    CLOG / GUI interplay makes me think it has to be intentional. It's just too bad in the best way.
  - dbotton 5y ago
    I think it is catchy and saying "I tapped danced my frontend" seems to work for me and reflects the speed of development that CLOG and Common Lisp offer. https://en.wikipedia.org/wiki/Clog_dancing https://en.wikipedia.org/wiki/Clog_dancing
matt7340 5y ago
Funny to see these new incarnations of the old ASP.NET UpdatePanel. I despised WebForms back in the day, but always had a soft spot for the UpdatePanel, seemed like a great idea. Especially when the alternative was manually building and managing UI on the client using ASP.NET AJAX.
sleepycatgirl 5y ago
Not seeing ClojureScript in there... feels a bit weird... One would think, CLJS is more or less, back-end lang brought to front-end
- DerArzt 5y ago
  After reading the article, Clojure would probably be better suited to be mentioned than ClojureScript. The point of it all looked to be speaking to the new paradigm that Phoenix LiveView brings which is server side rendering of subsections of a page. ClojureScript, while being Clojure in a Javascript uniform, doesn't look to be used in that manor.
  - sleepycatgirl 5y ago
    Hm.. Good point, My bad.
    - DerArzt 5y ago
      It's all good. Everything being said, I appreciate efforts like ClojureScript. There is just so much power in being able to use the same language and share the same models on the front and back end, but not all of us want to use JavaScript/Typescript.
rashkov 5y ago
Can anyone clarify what this quote refers to: "what really sets Erlang apart, for McCord, is its ability to preschedule processes so that the CPU doesn't get hung up on any single thread." What's this concept called? Is it simply a matter of setting a priority level on a certain task, that way the scheduler can make sure it doesn't block?
- riwsky 5y ago
  Preemptive scheduling, as opposed to cooperative scheduling. Basically: the scheduler can interrupt an erlang thread at any time, instead of a depending on threads to cooperate with the scheduler to see if they should stop. In go, for example, goroutines will only check with the scheduler at function calls, selects, and a few other things like that.
  - sb8244 5y ago
    I believe the BEAM only interrupts after "reduction" limit is reached, and is after function calls end. The big difference is that everything is a function call, so there's frequent opportunity to be interrupted. There's no functionless for-loop iteration, for example. I think having that would be a big sticking point for scheduling
- ramchip 5y ago
  Preemptive scheduling. "Preschedule" sounds like a mistake / misunderstanding in the article.
- randito 5y ago
  If you want to see a really nice demo of this, check out https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE -- The Soul of Erlang and Elixir by Saša Jurić. There's a really neat demo of a machine at 100 CPU% but that's still responsive because of Erlang's preemptive scheduling. There's a ton of other goodies in that video if you're interested. It really shows off the Erlang BEAM VM.
fbn79 5y ago
Have I interpret well? It's like a kind of virtual dom put on server-side? What a bad idea, please don't do it!
- chrismccord 5y ago
  In an abstract sense, yes, but we don't actually keep a vdom in Phoenix LiveView. You might want to reconsider this hot take. We actually send less data on the wire than the best hand-written JSON payload you could come up with in many cases. If you're curious how that works, I have a pretty detailed write up on it that may change your mind: https://fly.io/blog/how-we-got-to-liveview/ https://fly.io/blog/how-we-got-to-liveview/
robotburrito 5y ago
I remember GWT.
dham 5y ago
Not one mention of Java server faces (JSF) ?
YEwSdObPQT 5y ago
I am not a fan of these things. Much like big JavaScript frameworks whenever you need to do something outside of the mechanisms they provide things become very difficult very quickly and you still need to use JavaScript, HTML and CSS anyway as others have pointed out.
- Trasmatta 5y ago
  That's why I like StimulusReflex (and Hotwire). Stimulus offers a very nice pattern for adding the small bits of additional JS you need without ad-hoc JS spaghetti, while letting you push the vast majority of the rest to the backend.
  - YEwSdObPQT 5y ago
    Small bit of additional JS defeats the point of doing it at all. The moment you end up having to go outside one of these things you end up with one problem or another. The fact of the matter is that you will always have to deal with HTML, CSS and JS somewhere and you can try abstract it out and it always breaks down near the edges. Also as a bit of an aside and it is a bit of a moan. Coming from someone that can write everything from scratch and doesn't need framework. All of these things are horrible to work with (I've had to work with a bit of Blazor) and they just make it incredibly difficult to actually find out what is going on (especially when stuff doesn't work as advertised) as they just obfuscate what is going on. Every job requires you to know some horrendous framework these that has about 10 layers of Rube Goldberg madness in there for one reason or another. People will be surprised what can be achieved with `document.createElement()` a few classes and a pub / sub class.
The_rationalist 5y ago
Kotlin js (ts in fact) allow us to seamlessly share our business logic between the web frontend (offline mode) and the backend
Hjfrf 5y ago
This is a neat result of scope creep. The race between web C#/python and local javascript could make becoming a "full stack" dev easier at least.
sgwealti 5y ago
Not mentioning ClojureScript in an article like this is an odd omission.
girvo 5y ago
Funnily enough, PHP (like, old school PHP) is a surprisingly neat fit for this style of programming when combined with htmx[0] Tiny amount of glue HTML attributes, a heap of partials that are your PHP files and you’re good to go. What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course. I’ve been working on some personal tools with nothing more than Deno and htmx. Works quite well for my needs! [0] https://htmx.org/ https://htmx.org/
- piva00 5y ago
  > What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course. I used to do the same with PHP + Prototype.js back in 2006-2007 before jQuery existed, including pretty weird hacks for non-AJAX supported browsers (using JS to append <script></script> from server-side to the DOM). Surely what is old is new again...
  - girvo 5y ago
    I was the weirdo using Dojo back then, but once jQuery hit the scene and gained traction we jumped ship as soon as possible haha
- stavros 5y ago
  PHP, Django, Rails, whatever generates HTML, basically. I also slightly prefer Unpoly.com, because it takes whole pages instead of fragments. This means that if JS is disabled the site just keeps working, though with reloads.
  - mstef9 5y ago
    You can achieve full support with JS disabled using HTMX as well. It takes a little more work but HTMX provides headers[0] which you can evaluate on the backend to determine if you should return a partial or not. If JS is disabled, the HTMX headers will be missing and you know it's not an HTMX request. [0] https://htmx.org/reference/#request_headers https://htmx.org/reference/#request_headers
marcos100 5y ago
I love Blazor and I think this concept of using one language to write the front and back-end will be the standard way of doing SPA.
- thrower123 5y ago
  I do dearly hope Blazor works out - I would be so happy to never have to deal with the Javascript/Typescript tooling hell ever again - but I'm not holding my breath. Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow...
  - jorgeleo 5y ago
    "Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow" Assumption or knowledge? How do you know this?
    - thrower123 5y ago
      I've seen the cycle too many times over the past decade or so. It's really bad with the various desktop UI frameworks, but it happens with most everything they put out. If something doesn't get immediate traction, and doesn't have strong champions inside of Microsoft, things all too often wither on the vine and go by the board. Big bang initial rollout coinciding with Build, showing off some fancy capabilities that never quite actually are realized in the version released to general availability.
      - pjmlp 5y ago
        Even when they have strong champions, if they get distracted, the opposition is quite quick to move in.
    - pjmlp 5y ago
      Experience, many of us have been on the PC platform since the MS-DOS, and have seen how Microsoft politics play out, killing cool technologies because politics. Hence the famous xckd comic.
throwaway984393 5y ago
When is the world of software going to wake up? All programming languages suck, in one way or another. All frontend/backend paradigms suck, in one way or another. This constant churn of new, new, new is a waste. It gets replaced every few years, meaning all the time, effort and money sucked into it is gone. And engineers re-learn the same lessons over, and over, and over again. All so software engineers can be happy, because they just like doing new things in newly complicated ways. It's like changing how we build houses every few years just for fun, with no benefit to the people eventually living in that home. We're definitely not saving them money or building them any faster.
- devoutsalsa 5y ago
  The churn keeps me employed :)
  - deleted 5y ago
    [deleted]
- Bancakes 5y ago
  At this point learning C++ standards is like learning new frameworks. There is no escape other than reclusing to C (maybe not so bad!)
- chrisweekly 5y ago
  If you can only see the churn and froth, that doesn't mean there aren't great waves to surf; you might just need to paddle out to a better spot. https://remix.run https://remix.run is a prime example. It's new, and better, and simpler.
  - captaincaveman 5y ago
    It's better for new people joining, each cycle brings some improvement over the last typically. It also equalizes the playing field every few years, you become an expert in the latest new thing as there isn't an old guard. Some new web framework comes along, you can invest in that and become leet, where its very difficult to start new in react today and achieve that. This isn't to say past experience isn't valuable or helps you adopt things more quickly, can make you cynical about the new shiny and sometimes miss out on the actual improvements, even if small. I
bovermyer 5y ago
Initially, I thought this was going to be about WASM, based on the title. // The thing about rendering and processing things server-side and relying on very little, if any, JavaScript is that it makes it possible to send very small amounts of data to the client but still handle demanding tasks. There's something to be said for making a website usable for even the most anemic of client hardware.
fenk85 5y ago
Would love to see Kotlin (more) on the frontend Its a nice language all around on backend (and i suppose mobile, but i wouldnt know) thats a pleasure to code in
bronlund 5y ago
lucasyvas 5y ago
I'm surprised this wasn't about WASM. Either way, I'm receptive to the "LiveView" model, but until such a time a server can deliver both HTML and server driven native UI for mobile interchangeably, I prefer the RPC approach. I don't want to develop: 1. Both an API for mobile and LiveView for web. OR 2. Create my own server driven UI paradigm for mobile. I find maintaining one architectural pattern simpler. I do want to support users with the best technology fit, but I don't see why I have to make this tradeoff. The platform holders are (and always have been) jerking us around. I want to see a LiveView that can deliver both HTML and equivalent native UI markup. This is needed to sell the vision end to end - the world is not just web. I feel like this would enable a more sensible choice: Offline (first)? Use RPC with sync. Online-only? Use the LiveView paradigm and it'll work with native or web.
- funcDropShadow 5y ago
  As always, this depends on the use case. For in-house applications it is often far simpler to keep a lightweight frontend and mobile app is often of no concern. For these kinds of web application a server-heavy architecture was always a good choice.
  - lucasyvas 5y ago
    Of course, this is true. But I prefer architectural patterns that are flexible for future use cases, especially when there's no logical reason why it shouldn't be supported. You can start this way, but if you have a new requirement, you might reach a technological crossroad and ask yourself "why do I have to add a new paradigm? If the thing I'm already using could just do X, I'd save a shit load of time and/or money." You can always add, yes. But why do I have to? The world has treated web and native as separate for far too long. We're really just squabbling over UI toolkits, so why can't we come up with something that just says "Fuck it, we're supporting both native and web as first class in every server framework because that's how it should be. And we're also going to let you use any language in the browser because that's how it should be"
    - girvo 5y ago
jasfi 5y ago
I'm working on something like this: https://nexusdev.tools/ https://nexusdev.tools/ Designed to support multiple back-ends and front-ends. The first back-end will be Nim and the first front-end will be Flutter.
ojr 5y ago
Javascript on the server-side has gone from something that was advised to never be used in production. Now it is so ubiquitous that people are trying to replace it with something new and more strict and less freedom... I am fan of modern javascript, I don’t complain or mad about the fast rate of change and improvement in the language. I kept up with all the latest javascript tools and now can build full-stack applications on mobile and web with very similar codebases faster than ever.
tifadg1 5y ago
What does that bring to the table though? You'll still need to write html, css and javascript (or some dsl). As a hobbyist Python dev who doesn't want to deal with frontend bs more than absolutely needed, I found my perfect stack - fastapi, svelte and tailwindcss.
- hoistbypetard 5y ago
  With a similar outlook to yours, I landed on django, htmx and tailwindcss. I had started down the path of fastapi, svelte and tailwindcss, but when I figured out that htmx let me use server-rendered templates, getting rid of the api and the packaging toolchain felt more ergonomic. And if you're doing server-rendered things instead of APIs, django has a few more batteries included. (But I really like fastapi for APIs.)
- lawik 5y ago
  LiveView? It lets you not write JavaScript. Or depending on your needs, very little Javascript. Less need for an API-layer and related contracts. You can still use Tailwind CSS. Works quite nicely.
- threeseed 5y ago
  I use Scala.js and since my entire stack is all Scala I don't need: - 2x developers - 2x CI/CD stacks - 2x build tools - 2x model classes - 2x instrumentation code I could keep going but it's a pretty significant improvement especially for small teams or solo developers.
gumby 5y ago
Why not just deploy X windows and run the browser on the server as well? (Pun semi-intended)
- floatboth 5y ago
  Heh, GTK has a "Broadway" backend for running in a browser, though I don't think WebKitGTK will work on it…
- pklausler 5y ago
  Because the "server" and "client" names would be reversed.
  - gumby 5y ago
    In this case it would be a server at each end so you could claim that all computation and rendering was "done on the server"
- funcDropShadow 5y ago
  Let's take this question serious for a moment. Modern X applications render bitmaps which get shipped over the compositor and the X server to the graphics card driver. That is not a good model for the web, because it would mean the web server has to produce rendered bitmaps, specific for the fonts, window size, and display panel led configuration over the web. The browser cannot even select text or provide a search dialog. That is almost VNC. But originally, X applications didn't render bitmaps but submitted drawing calls. Sun used to use Postscript for that. So using that approach, it would be possible for the browser to select text, to scroll, to copy text, to search text etc. A clear improvement. But resizing the browser window would still need a complete re-transmission from the server. But if the web server sends static html, css, and a fixed JS library, which is used to replace parts of the dom, the browser can do a lot more locally. And still the whole application logic resides on the server.
  - skocznymroczny 5y ago
    > because it would mean the web server has to produce rendered bitmaps, specific for the fonts, window size, and display panel led configuration over the web. The browser cannot even select text or provide a search dialog. That is almost VNC. So not much different than "modern" <canvas> based apps.
Tarucho 5y ago
How do these tools work? Are they like ASP.NET Webforms?
- DerArzt 5y ago
  The gist I was able to glean, specifically about Pheonix Liveview, is that all updates on the Frontend and Backend are pushed to the other side via websockets. For the Frontend, this means sending some json payload to the Backend. For the Backend this means either responding to a request or sending out a new update both of which involve sending out a snippet of pre-rendered HTML to replace/update an existing element that was already on page. The benefit here is that we can get to a place that is almost a SPA without needing to do a whole lot of JavaScript for the Frontend. It also helps that Elixir is built on top of Erlang which gives it a boon to be able to handle a lot of users on one server.
  - lawik 5y ago
    There is also a bundle of clever implementation which means the templates are aware of what parts are static and what parts are dynamic. So they can send optimized changes, essentially small diffs, for the dynamic parts as they change. Often this means only sending the values for your text input field, not any of the markup for the field.
jacky2wong 5y ago
Not to mention streamlit, gradio, plotly for Python :)
ivanmontillam 5y ago
I've been looking for this for a long while. I am surprised that there are no browsers that can support other languages. My ideal architecture is to have a browser where you can select your front-end language interpreter, as in a Chromium + V8 + CPython + Whatever front-end processor you might want (Brython[0] achieves this, but transpiling to JavaScript). What doesn't make sense to me is that JavaScript has genuinely been the only language for the front-end, and it has been a monopoly for many years. Of course, there are other great languages like TypeScript, but these end up anyway transpiled to JavaScript, which to me feels like mounting your skyscraper over dunes. Not to hate on JavaScript, but JavaScript has grown too quirky for my tastes and that's why I've been away a lot from front-end development. There are efforts to fix it, with the new ECMA standards, but I don't feel it's going anywhere unless breaking changes are introduced to modernize the language. The fact that you have to "patch" your scripts with 'strict mode' on the top of the file speaks a lot of being defensive with programming. WASM is a solution to this, except you're not supposed to write WASM yourself. I want web development to be more straightforward, like the old days, where you didn't have to "compile" or "package" anything, and you just did your thing, and that worked. -- [0]: https://brython.info/ https://brython.info/
- ihateolives 5y ago
  I'm really sad that Dart didn't make it as Javascript replacement. It's much better designed language, but didn't get traction.
  - BoorishBears 5y ago
    Dart is not fhat much better. In a period where most languages are experiencing a "rebirth" as a well thought out modern language, Dart feels like the "before" waiting for an "after". I'd be deeply disappointed if we had progressed from Js to Dart, and it's why I'm not a fan of Flutter (Java => Kotlin, Obj C => Swift, Js => Ts, Erlang => Elixr, etc.)
    - pjmlp 5y ago
      > Java => Kotlin, If you are speaking of Android, yes. On the JVM is it just one more guest on the building. https://madnight.github.io/githut/#/pull_requests/2021/4 https://madnight.github.io/githut/#/pull_requests/2021/4
cestith 5y ago
It's almost like what some of us did 15 years ago, use just enough JS to load things into the DOM fetched from the backend via XMLHttpRequest, is news now. Having a Websocket open to the backend and using a front end that's aware of that instead of using HTTPS seems to be the major difference here. That difference is more about WebSockets existing now than about the choice of backend language or the server-rendered, frontend-refreshed display model.
- tluyben2 5y ago
  We wrote a framework 15 years ago (almost exactly) that took rendered snippets from the servers and plugged them into the DOM; https://flexlists.com https://flexlists.com is 15 years old and uses that. It's really fast and was far easier to build with than all the manual jquery stuff. Fun times :) I should rewrite it in Liveview, seems a good fit.
- chrismccord 5y ago
  The biggest difference (at least for Phoenix LiveView) is having a stateful backend represent the UI and we do away entirely with HTTP APIs/serializers/resolvers. So you get both interaction and push updates from the server at any time, without HTTP glue layers. And it actually scales. So think React's functional-reactive-templates on the server, pushing minimal diffs over the wire better than if you'd carefully written an efficient JSON API or GraphQL endpoint. Elixir is also a distributed programming language so you also get things for free like sending an update to everyone's UI across the entire cluster.
  - cestith 5y ago
    I think you're the only one to mention JSON or serialization at all. I do believe I already said websockets were the innovation, but they really literally did not exist 15 years ago for us to use. Elixir being distributed is nice. You still need the logic to get the change into everyone's session. You're just not using an external DB, cache layer, or work queue to do it. It's amazing, really, how people feel comfortable condescending to others who explain how we did things before the current technologies existed as if we could never grasp how the new technologies improve things. Yes, this is nice, but it's evolutionary, not revolutionary.
dnautics 5y ago
Chris McCord, quoted in the article, explains extremely well the absurd state of stateless http requests, from a perspective that is not appreciated in the article (queued to 40m50s): https://www.youtube.com/watch?v=XhNv1ikZNLs&list=PLqj39LCvnOWYTNs1n3ZNMSNO3Svv_XweT&t=40m50s https://www.youtube.com/watch?v=XhNv1ikZNLs&list=PLqj39LCvnO... The programming model (in liveview, don't know about blazor or hotwire or livewire) really lets you get better performance by doing less. A part of me sarcastically thinks wow, damn, deleting data is irreversible data transformation and therefore increases entropy, every stateless http request is inching us closer to the heat death of the universe.
- lxe 5y ago
  He just glosses over the "you can use a websocket API", which would solve most of the issues he's describing. There are a ton of websocket libraries that are easy to use. Do all the auth and session establishment once, and then communicate over websocket if you hate sending cookies and session data back and forth.
  - fshr 5y ago
    No, you missed the point. Liveview works because there’s a stateful Elixir process on the backend for each open ws connection. This model doesn’t work in nearly any other backend option in any other language. If he glossed over the web socket option you’re glossing over the uselessness of the ws if the backend has the memory of a goldfish.
jbandela1 5y ago
The article actually left out one of the oldest frameworks for doing this: Wt https://www.webtoolkit.eu/wt https://www.webtoolkit.eu/wt It uses C++ to program a back-end application kind of like you would with with Qt, and then it does all the required Javascript/HTML to render your app in the browser. It is kind of like Qt for the web (painting with a very, very broad brush). I have also tried wasm with various Rust frameworks (Seed and Yew). However, for my latest project (triviarex.com) I ended up abandoning those in favor of React Javascript, however with a non-traditional architecture. The downside of these frameworks for me was tooling and turn around time and integration. React has great tooling, and it is easy to do live coding. In addition, there are a lot of pre-built components for Javascript frameworks and a ton of documentation. While there can be live coding with the backend, I guess because of my background, I like to use strongly typed languages in the backend to help catch logical errors earlier, and that requires a compilation step. So this is the architecture pattern that I am using. My backend is written in Rust in Actix, and each session is represented by an Actor. The React front-end establishes a web sockets connection to the actor, and sends commands to the actor, which are then parsed by the backend using Serde JSON, and handled using pattern matching. All the state and state transitions are handled on the backend which then sends the frontend a Javascript serialization of a Rust enum that describes what the state is, and what data is needed to render. The front-end basically has a series a if-else statements that match against the state and renders it. Most logical processing lives on the backend, and most of the buttons simply just send a web socket message to the backend. For me, this is the best of both worlds. I get the strong typing and correctness of Rust in the backend to manage the complexities of state management, and I get the flexibility and live coding of Javascript and React on the front-end to quickly and interactively develop the UI. Many times, I will be testing and see that the formatting or placement looks off, and I just quickly change the html/css/javascript and have it instantly appear.
deleted 5y ago
[deleted]
deepsun 5y ago
I remember JSF (Java Server Faces) and GWT (Google Web Toolkit). Both burned in flames. JSF: main idea is to abstract away boundary between server and client. Turns out -- you really want to know where that thing is running -- on the server or on the client. So it turned into a fight against that main idea of JSF. GWT: main idea is to forget JavaScript/DOM and write pure Java. Turns out -- you really need to know JavaScript and your DOM to write GWT. So it turned into a fight against that main idea of GWT.
- culturedsystems 5y ago
  JSF and GWT were rightly abandoned, but the new frameworks are different in ways that might be relevant. One of the main problems with JSF is the mismatch between it's stateful programming model, and HTTP's statelessness; as I understand it, LiveView uses a persistent websocket connection to a stateful server process, so that mismatch doesn't apply. Another JSF problem is it involves a component-based templating system that abstracts quite a long way from HTML, making it hard to figure out what's actually going on. LiveView, Hotwire, and htmx all seem to be much closer to HTML, which might make them easier to work with. I admit I'm still to scarred by JSF to be keen to try out these new frameworks and find out if they've actually solved these problems, but I'd love to read an evaluation of the new server-side frameworks from someone who experienced the problems with the old ones.
- floatboth 5y ago
  There was also https://liftweb.net https://liftweb.net in Scala…
- taeric 5y ago
  I am frequently surprised by folks that are active fans of both. So, I don't think they are dead dead. But GWT, in particular, really helped cement a ton of distrust for any framework coming out of Google. JSF was trying to make handy components for JSPs. And made them unusable in the process.
- crnkofe 5y ago
  I've worked quite a bit with JSF and although I was never a fan it does have some points. It allows for focusing more on contents than visuals also assuming the visuals won't be that fancy. There's plenty of apps that don't really require going all-out on eye candy. Note that it was always a problem when people do want eye candy. I also rarely had issues with performance but perf. is always an issue regardless of working with server- or client-side rendering. I pray for WASM to eventually replace JS. NodeJS ecosystem with all the experimental features, job ads in update notes, shitload of dependencies, one-function packages, legacy JS is a special kind of pain that I avoid whenever I can.
cies 5y ago
There is not BE or FE lang. The browser (the universal VM) just only takes JS and WASM at the moment. So they can be considered browser NATIVE. TypeScript is not native. Is it then also a BE lang? What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". And the second group has managed to compile more-and-more of it's langs to JS and WASM.
- jayd16 5y ago
  It seems like a silly point to make considering the actual content of the article. It's talking about server-side rendering. While the title might be a little provocative, its certainly talking about rendering UI (the front end) using whatever language you used on the back end, even if it was JS.
- Zababa 5y ago
  > What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". I think the opposite, the rift has been healing. It seemed that it was pretty big in the 2010's (Python/Ruby/Perl vs Java/C#/C++) but these days we have TypeScript, Rust, Kotlin; Java and C# are getting better too (type inference), Python and Ruby are getting typechecking.
  - cies 5y ago
    > healing > these days we have TypeScript, Rust, Kotlin; Java and C# are getting better too (type inference), Python and Ruby are getting typechecking everyone caves to the types. i think the strongest holdout is probably the LISP/Clojure corner. they have optional typing for along time, but it is not used that much afaik many have voiced their reasons for liking dynamic typing. i only have one: faster reload cycles while developing. the other pros of dynamic typing are all over shadowed by their inherent downsides.
    - smasher164 5y ago
kuon 5y ago
I just shipped my fourth large project based on Phoenix LiveView and I think it is the best thing that happened to web dev since forever. The javascript is minimal (like to manage selection in text field or to handle copy/paste). Everything else is in elixir. Tailwind is used for CSS. Having the full client state available on the backend is really incredible. It is so much easier, no more ajax/graphql... You just have all your backend data "under your fingers". I can only recommend giving it a try. Also, if your app is offline first, phoenix channels are great for sync. It is not live view, but it is easier to use than ajax calls.
- jon1628492 5y ago
  A question from a newcomer to the ecosystem: do you have any recommendations for an admin system like Django's? On a related note, how do you usually determine whether a package is abandoned vs stable?
  - dnautics 5y ago
    The crazy thing is that most elixir packages that are abandoned still basically work. This is both a blessing and a curse all around
- _xnmw 5y ago
  > Having the full client state available on the backend is really incredible. Got the exact same feeling writing my latest app with Laravel Livewire. The ability to use backend state seamlessly on the frontend without explicitly passing state back and forth reduces complexity so much it's like writing 1 application instead of 2. I was able to build rich, fully interactive apps with minimal JS -- I'll never go back to React again.
- vasergen 5y ago
  out of curiousity, how difficult to support large project in elixir, especially refactoring, giving there is no static typing. I know about pattern matching, which helps, but interesting to hear practical experiance
airocker 5y ago
How does this approach compare/differ from using something like mighty app where you stream a video to the ui and take gestures to the server?
- bo0tzz 5y ago
  This is a lot lighter than a video stream, and probably somewhat less latency sensitive as well.
Khelavaster 5y ago
Backend languages came to the frontend with Unity and Silverlight..
wallscratch 5y ago
Any thoughts on anvil? It’s a full-stack python framework. I think it features a python to js transpiler: https://anvil.works/blog/client-side-python https://anvil.works/blog/client-side-python
g42gregory 5y ago
I would love to see Python running natively in the browser and to be able to use Python instead of JavaScript.
- mlboss 5y ago
  You can try wasm based approaches. Some related frameworks: https://github.com/pyodide/pyodide https://github.com/pyodide/pyodide https://github.com/wasmerio/wasmer-python https://github.com/wasmerio/wasmer-python
rr808 5y ago
I keep waiting for something better than js/ts to do frontends so I dont have to learn it. I'm still waiting... I thought wasm would have gotten further along by now.
- ironmagma 5y ago
  Pretty much any wasm language will require a JS runtime somewhere if you’re going to do substantial things with it, so might as well learn it either way.
  - rr808 5y ago
    Really though? I think wasm app will be able to write to DOM so no JS required, it can't yet but seems inevitable.
    - ironmagma 5y ago
      I’m not an expert, but DOM APIs seem particularly suited to JavaScript. There is probably a way to handle it via Wasm, but this is a bit like avoiding learning C when writing native code.
sergiotapia 5y ago
We use Liveview exclusively for our app (https://www.grilla.gg/ https://www.grilla.gg/) and I'm happy every day we can build stuff like this with very minimal javascript. Happy to answer any questions about what it's like to run a startup using liveview.
brtkdotse 5y ago
I couldn’t care less about the actual language. What I do care about is not having to maintain two separate tool chains and package managers, one for backend and one for front end.
- Toine 5y ago
  Doesn't NextJS solve this ?
metadat 5y ago
What is this GitHub.com/readme special alias? I hate it. Very annoying presentation format and it breaks the GH URL structure consistency.
2ion 5y ago
Ha. WASM with QtCreator and Qt w/ C++ would have put a decade of web developers out of a job had it launched in 2010. Most amusing about front end is that stuff like flexbox, nice animations and GPU-accelerated graphics based on web tech get praised and hailed as innovation yet we had that stuff on the desktop for years and years already way before the web bros rediscovered everything 2010-2020.
- deleted 5y ago
  [deleted]
- lpghatguy 5y ago
  C++ is not nearly as productive a language for most programmers in the world as JavaScript. Qt is not a panacea, even for desktop apps. The condescending tone to web developers is very strange and not very nice.
  - 2ion 5y ago
    > Qt is not a panacea, even for desktop apps My point is: all achievements in web dev modularity and features have been present in Visual Basic, Delphi, TurboC++, Java and Qt since the early 2000s. Fully hardware accelerated UIs to boot. Well, we decided to move it all into the browser sandbox and start from scratch. Tools like QtCreator or the VisualBasic form editor got replaced by an expensive toolchain ranging from Adobe products to 1000 npm packages.
dorianmariefr 5y ago
or you could use ruby on the backend and javascript on the client
deleted 5y ago
[deleted]
derekzhouzhen 5y ago
There are 3 different kinds of web applications: * smart front end, dumb back end. This is the SPA model * dumb front end, smart back end. This is the old school model * smart front end, smart back end. This is the new school model If you can get away with the SPA model, by all means do it. Liveview is not going to challenge that. What it is doing, is to give new live to the old school model so you can avoid the complexity of having both a smart front end and a smart back end for a large percentage of applications. A smart/smart system is an asymmetric distributed system, a beast to handle for gurus and novices and everyone in between.
softwarebeware 5y ago
I don't really get the terminology of "backend" and "frontend" languages. To me, JavaScript is just a dialect of C anyway and the browser is just an OS. It doesn't make any sense to specify any particular usage except to acknowledge that for frontend development, JavaScript is the most popular choice. And so what? Most frameworks (like Angular) are heavily-based in patterns that came from other languages.
anthonybsd 5y ago
Around 15 years ago I needed to build an internal app for my company that would aggregate and display a lot of data. Our backends were all in Java and I had sour taste for JavaScript from a previous project so I looked around for an AJAX framework that would allow me to avoid writing any JavaScript. Lo and Behold there were actually 2 viable ones on the market: Google GWT and Echo2. I played with both of them and Echo2 blew me away. It looked and acted better than anything else on the market at the time. Rich widgets, translucency, works in (almost) any browser, etc. I rolled an app with it. The mechanism of operation was pretty similar to LiveView except WebSockets didn't exist at the time so it worked by having a super thin JavaScript client that polled the web server on the regular basis. So yeah, a bit chatty but for intranet app I didn't care much. Everything worked and felt like it was a Java Swing app but in a browser. The app became popular and we started writing extensions to it and adding modules. Then inevitable customization came. "Can we create a widget that does X?" "Ughh let me take a look.". This is when my nightmare began. Writing a new widget for this thing required putting together some utterly nightmarish JavaScript code and then compiling it together with equally nightmarish piece of Java code. If you had any custom stylesheet you basically were screwed. So roughly 2 years down the road from starting the project I started rewriting it in pure JavaScript and ExtJS (now called Sencha), which was one of the first few juggernaut frameworks for writing SPAs circa 2007-2008. That's why when things like Blazor and LiveView roll around I get flashbacks akin to post traumatic stress disorder.
- chrismccord 5y ago
  I remember when Sencha came on the scene :) WebSocket's help for more efficient bidirectional comms and guarantee load-balanced process placement, but LiveView can also be used with long polling if folks have a hard requirement. We also have much better DOM apis for things like efficient diffing/patching that I'm sure you lacked back then. Were you keeping stateful "widgets" on the Java side or hydrating from client state for interactions?
  - anthonybsd 5y ago
    >We also have much better DOM apis for things like efficient diffing/patching >that I'm sure you lacked back then Oh I hope so. I marvel at React virtual DOM magic on daily basis so I'm sure it can be all done a lot more efficiently these days. >Were you keeping stateful "widgets" on the Java side or hydrating from client >state for interactions? IIRC it was 90% on the Java side. The default polling rate was something along the lines of 200 ms. So if you clicked a checkbox on the front end, it would perform the animation for clicking it on the front end but it wasn't considered checked until the backend was informed of it and signed off on it. In Java code if you had a listener for onClick you would write a normal Java method and it would get invoked normally with access to all your server stuff. As you can imagine, Echo2 server session objects could get pretty heavy. Reminded me a bit of mainframes and terminal clients lol :)
AzzieElbab 5y ago
I do not usually write front-end but when I do I use https://www.scala-js.org/ https://www.scala-js.org/
- threeseed 5y ago
  Best used with any of the following. Slinky React: https://slinky.dev https://slinky.dev Laminar: https://laminar.dev https://laminar.dev Diode: https://github.com/suzaku-io/diode https://github.com/suzaku-io/diode ZIO: https://zio.dev https://zio.dev
rglover 5y ago
What's incredibly frustrating about the knocks on JavaScript is that it's not a shortcoming of the language that creates the problems hinted here, but the poorly-considered engineering choices of the popular frameworks. After building my own framework [1] last year, I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HTTP distilled down to its absolute essence is brilliant, but for some reason gets absolutely ignored in the JS world. When you couple that with websockets for incremental updates (similar to what Chris McCord is doing in Phoenix), it's insanely powerful. It can be reasonably lightweight, too, if you're only shipping the JS you need to render the page. That rendering some HTML, CSS, and interactive JS in a browser has been turned into what it has is staggering. Though, not surprising, when you realize a lot of the momentum in JavaScript the last decade or so was perpetuated by venture capital (and the inevitable fast and cheap nature of that world) being pumped into inexperienced teams. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
- mavelikara 5y ago
  > I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HTTP distilled down to its absolute essence is brilliant, but for some reason gets absolutely ignored in the JS world. Can you please elaborate what these areas of disconnect are? I looked at Joystick documentation hoping to find more of your thoughts this topic, but could not.
  - rglover 5y ago
    I've tried writing a response to you a few times but realizing how complex it is—the real answer to your question is worthy of a long blog post. The core problem is the blurring of the lines between a framework and the underlying technologies of the web (HTML, CSS, and JavaScript). To me, it seemed like a lot of unnecessary complexity was being added just to achieve the common goal of rendering some HTML, styling it with CSS, and making it interactive with JavaScript (what I refer to in conversation as a "need to look smart" or "justify having a CS degree"). For example, introducing a new syntax/language like JSX (and the compiler/interpretation code) when plain HTML is simple and obvious. The drive to make everything happen on the client leading to vendor lock-in by third-party providers to fill the gaps of having a database (e.g., Firebase/Supabase). Making routing seem like some complex thing instead of a URL being typed into a browser, a server mapping it to some HTML, and then returning that HTML. Where this really became clear to me was in the resulting developer experience. I've been teaching devs 1-on-1 since ~2015 and had a bird's eye view of what it was like using these tools across the spectrum of competency (beginner, intermediate, advanced). The one consistent theme was confusion about how X framework mapped back to HTML in the browser. That confusion was handled in one of two ways: making messes in the codebase to solve a simple problem (e.g., lord help me with the nested routing in React) or giving up entirely. As an educator, the latter was especially bothersome because the transition from basic web dev to these JS frameworks was so jarring for some, they just didn't want to bother. That shouldn't happen. --- I'd like to elaborate on these things a bit more. Can you send an email to ryan.glover@cheatcode.co so I can remember to follow up once I've organized the post I've hinted at above?
zekrioca 5y ago
Why no words about WebAssembly/WASM?
throw10920 5y ago
I would like something explained to me. When webapp logic happens on the client side, that results in slow applications (n.b. for normal users on low-end hardware, not developers on high-end hardware) due to CPU costs. When webapp logic happens on the server side, that results in slow applications (n.b. for users on unreliable residential, mobile cellular, or rural connections, not those living with fiber) due to network latency. Doesn't Liveview (and related techs) simply make the slowness a stronger function of internet quality (as opposed to available processing power), instead of actually making the application less dependent on either of those factors for performance?
- di4na 5y ago
  No because network latency is not that big on unreliable connections if the exchange are "small" and relatively "rare". Which is most applications on the web, particularly with these techniques.
- austincheney 5y ago
  > When webapp logic happens on the client side, that results in slow applications (n.b. for normal users on low-end hardware, not developers on high-end hardware) due to CPU costs. Its not CPU. Its bad software written by people who are poorly trained and have no leadership. Do you really need 10mb of JavaScript and 10 seconds of load time to dynamically put a few lines of text on the screen? Yes, absolutely you do, because people don't know how to do it efficiently. This is a people problem, and not a technology problem. Hardware does not solve that problem. The actual technology is actually insane fast. As a counterpoint my personal app loads an OS GUI with state restoration using 2mb of JS code (unminified) in about 150ms.
  - threeseed 5y ago
    > because people don't know how to do it efficiently Of course we do. We just choose not to bother because delivering features efficiently is often more valuable than shaving off a few seconds of download time. Especially when it's typically once off and then cached.
collaborative 5y ago
From a costing perspective, - hosting a web sockets server is expensive - bandwith is cheap - client cpu is free So a lightweight, modern SPA wins in this case
princevegeta89 5y ago
Yes please; everyone who hates Javascript needs this so bad.
girafffe_i 5y ago
No JSP love for Java.
theptip 5y ago
I'd love to see this approach make more headway in the Django community. Based on the last DjangoCon it seems like the community is coalescing around HTMX. This tool does play very nicely with Django's templating engine; you can just have HTMX re-render a particular template block on the server, and send down that updated block. The migration path is quite clean; you just wrap your "HTMX-updated" template block in a `hx-post` div. Having not gone too deep on HTMX, I'm interested in folks' thoughts on where it's lacking vs. LiveView and Hotwire. One area I can see is performance; Elixir is going to be faster than Django, and so if you're trying to handle high session counts over websockets. But the impression I get is that HTMX is a bit more light-weight, so I'm wondering if there's usecases that can't be met with it vs. LiveView. Other Django libraries that haven't quite seen as much uptake: We have https://github.com/edelvalle/reactor https://github.com/edelvalle/reactor, and a port of Hotwire: https://github.com/hotwire-django https://github.com/hotwire-django but both of these don't seem to have much adoption (yet!).

394 points by deznu 5y ago

I don't think this is really about programming languages. The world of software (and specifically everything network based) is oscillating between fat servers and fat client every few years or so. To me the innovation seems to be orthogonal to this cycle and may actually be accelerated by this continuous change in perspective. Which is good!

streamofdigits 5y ago
if the hardware landscape settles for a while (in terms of the capabilities of devices and networks - which is not a crazy precondition given Moore's law has run its course) then it may be that these server/client pendulum oscillations get damped around an "optimum" of sorts. An optimum defined both in terms of what it enables users to do with software but also how easy it is for developers to deliver it. Since simple is better than complex it feels that any architecture that does not require two distinct ecosystems might have an advantage (all else being equal).
dnautics 5y ago
for liveview, it's not at all about "fat servers"; the overhead of maintaining a socket over erlang is not that much (maybe a few K -- the base erlang process overhead is ~400 words), so you're going to almost certainly be doing better than, say ruby (via hotwire) which isn't really designed from the ground up to hold onto the websocket. By persisting the connection with a stateful system, you're going to be avoiding a whole ton of computation that just gets thrown away with stateless HTTP requests. So it's probably in the end a lighter server than most web backends. This is the irony, Erlang/Elixir, despite being functional language with less and highly restricted access to stateful side effects, is really FANTASTIC at safely holding onto state and persisting it for the user, and making that model digestible for the developer.

istjohn 5y ago

Anyone have good experiences with a LiveView-style Python framework?

awesomeweb 5y ago
You can try Django Unicorn (https://www.django-unicorn.com https://www.django-unicorn.com) if Django is your cup of tea. Have used it in production and it works great. Author is also very responsive to bugfixes / feature requests.

phoe-krk 5y ago

See CLOG, the Common Lisp Omnificent GUI - a recent project which is an implementation of this paradigm. https://www.reddit.com/r/lisp/comments/s1itqi/the_common_lisp_omnificent_gui_online_lisp/ https://www.reddit.com/r/lisp/comments/s1itqi/the_common_lis... https://www.reddit.com/r/lisp/comments/sd9wf1/clog_builder_cl_web_3_awesome_lang_awesome_tool/ https://www.reddit.com/r/lisp/comments/sd9wf1/clog_builder_c...

oschvr 5y ago
Unfortunate naming.. "I CLOGed my frontend"
- capableweb 5y ago
  When would you use the name of a project like that? "I Reacted my frontend"? "I AngularJSed my frontend"? "I VueJSed my frontend"? I just don't see it.
  - fayedev 5y ago
    I'd say I Vued my frontend.
- tasha0663 5y ago
  CLOG / GUI interplay makes me think it has to be intentional. It's just too bad in the best way.
- dbotton 5y ago
  I think it is catchy and saying "I tapped danced my frontend" seems to work for me and reflects the speed of development that CLOG and Common Lisp offer. https://en.wikipedia.org/wiki/Clog_dancing https://en.wikipedia.org/wiki/Clog_dancing

matt7340 5y ago

Funny to see these new incarnations of the old ASP.NET UpdatePanel. I despised WebForms back in the day, but always had a soft spot for the UpdatePanel, seemed like a great idea. Especially when the alternative was manually building and managing UI on the client using ASP.NET AJAX.

sleepycatgirl 5y ago

Not seeing ClojureScript in there... feels a bit weird... One would think, CLJS is more or less, back-end lang brought to front-end

DerArzt 5y ago
After reading the article, Clojure would probably be better suited to be mentioned than ClojureScript. The point of it all looked to be speaking to the new paradigm that Phoenix LiveView brings which is server side rendering of subsections of a page. ClojureScript, while being Clojure in a Javascript uniform, doesn't look to be used in that manor.
- sleepycatgirl 5y ago
  Hm.. Good point, My bad.
  - DerArzt 5y ago
    It's all good. Everything being said, I appreciate efforts like ClojureScript. There is just so much power in being able to use the same language and share the same models on the front and back end, but not all of us want to use JavaScript/Typescript.

rashkov 5y ago

Can anyone clarify what this quote refers to: "what really sets Erlang apart, for McCord, is its ability to preschedule processes so that the CPU doesn't get hung up on any single thread." What's this concept called? Is it simply a matter of setting a priority level on a certain task, that way the scheduler can make sure it doesn't block?

riwsky 5y ago
Preemptive scheduling, as opposed to cooperative scheduling. Basically: the scheduler can interrupt an erlang thread at any time, instead of a depending on threads to cooperate with the scheduler to see if they should stop. In go, for example, goroutines will only check with the scheduler at function calls, selects, and a few other things like that.
- sb8244 5y ago
  I believe the BEAM only interrupts after "reduction" limit is reached, and is after function calls end. The big difference is that everything is a function call, so there's frequent opportunity to be interrupted. There's no functionless for-loop iteration, for example. I think having that would be a big sticking point for scheduling
ramchip 5y ago
Preemptive scheduling. "Preschedule" sounds like a mistake / misunderstanding in the article.
randito 5y ago
If you want to see a really nice demo of this, check out https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE -- The Soul of Erlang and Elixir by Saša Jurić. There's a really neat demo of a machine at 100 CPU% but that's still responsive because of Erlang's preemptive scheduling. There's a ton of other goodies in that video if you're interested. It really shows off the Erlang BEAM VM.

fbn79 5y ago

Have I interpret well? It's like a kind of virtual dom put on server-side? What a bad idea, please don't do it!

chrismccord 5y ago
In an abstract sense, yes, but we don't actually keep a vdom in Phoenix LiveView. You might want to reconsider this hot take. We actually send less data on the wire than the best hand-written JSON payload you could come up with in many cases. If you're curious how that works, I have a pretty detailed write up on it that may change your mind: https://fly.io/blog/how-we-got-to-liveview/ https://fly.io/blog/how-we-got-to-liveview/

robotburrito 5y ago

I remember GWT.

dham 5y ago

Not one mention of Java server faces (JSF) ?

YEwSdObPQT 5y ago

I am not a fan of these things. Much like big JavaScript frameworks whenever you need to do something outside of the mechanisms they provide things become very difficult very quickly and you still need to use JavaScript, HTML and CSS anyway as others have pointed out.

Trasmatta 5y ago
That's why I like StimulusReflex (and Hotwire). Stimulus offers a very nice pattern for adding the small bits of additional JS you need without ad-hoc JS spaghetti, while letting you push the vast majority of the rest to the backend.
- YEwSdObPQT 5y ago
  Small bit of additional JS defeats the point of doing it at all. The moment you end up having to go outside one of these things you end up with one problem or another. The fact of the matter is that you will always have to deal with HTML, CSS and JS somewhere and you can try abstract it out and it always breaks down near the edges. Also as a bit of an aside and it is a bit of a moan. Coming from someone that can write everything from scratch and doesn't need framework. All of these things are horrible to work with (I've had to work with a bit of Blazor) and they just make it incredibly difficult to actually find out what is going on (especially when stuff doesn't work as advertised) as they just obfuscate what is going on. Every job requires you to know some horrendous framework these that has about 10 layers of Rube Goldberg madness in there for one reason or another. People will be surprised what can be achieved with `document.createElement()` a few classes and a pub / sub class.

The_rationalist 5y ago

Kotlin js (ts in fact) allow us to seamlessly share our business logic between the web frontend (offline mode) and the backend

Hjfrf 5y ago

This is a neat result of scope creep. The race between web C#/python and local javascript could make becoming a "full stack" dev easier at least.

sgwealti 5y ago

Not mentioning ClojureScript in an article like this is an odd omission.

girvo 5y ago

Funnily enough, PHP (like, old school PHP) is a surprisingly neat fit for this style of programming when combined with htmx[0] Tiny amount of glue HTML attributes, a heap of partials that are your PHP files and you’re good to go. What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course. I’ve been working on some personal tools with nothing more than Deno and htmx. Works quite well for my needs! [0] https://htmx.org/ https://htmx.org/

piva00 5y ago
> What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course. I used to do the same with PHP + Prototype.js back in 2006-2007 before jQuery existed, including pretty weird hacks for non-AJAX supported browsers (using JS to append <script></script> from server-side to the DOM). Surely what is old is new again...
- girvo 5y ago
  I was the weirdo using Dojo back then, but once jQuery hit the scene and gained traction we jumped ship as soon as possible haha
stavros 5y ago
PHP, Django, Rails, whatever generates HTML, basically. I also slightly prefer Unpoly.com, because it takes whole pages instead of fragments. This means that if JS is disabled the site just keeps working, though with reloads.
- mstef9 5y ago
  You can achieve full support with JS disabled using HTMX as well. It takes a little more work but HTMX provides headers[0] which you can evaluate on the backend to determine if you should return a partial or not. If JS is disabled, the HTMX headers will be missing and you know it's not an HTMX request. [0] https://htmx.org/reference/#request_headers https://htmx.org/reference/#request_headers

marcos100 5y ago

I love Blazor and I think this concept of using one language to write the front and back-end will be the standard way of doing SPA.

thrower123 5y ago
I do dearly hope Blazor works out - I would be so happy to never have to deal with the Javascript/Typescript tooling hell ever again - but I'm not holding my breath. Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow...
- jorgeleo 5y ago
  "Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow" Assumption or knowledge? How do you know this?
  - thrower123 5y ago
    I've seen the cycle too many times over the past decade or so. It's really bad with the various desktop UI frameworks, but it happens with most everything they put out. If something doesn't get immediate traction, and doesn't have strong champions inside of Microsoft, things all too often wither on the vine and go by the board. Big bang initial rollout coinciding with Build, showing off some fancy capabilities that never quite actually are realized in the version released to general availability.
    - pjmlp 5y ago
      Even when they have strong champions, if they get distracted, the opposition is quite quick to move in.
  - pjmlp 5y ago
    Experience, many of us have been on the PC platform since the MS-DOS, and have seen how Microsoft politics play out, killing cool technologies because politics. Hence the famous xckd comic.

throwaway984393 5y ago

When is the world of software going to wake up? All programming languages suck, in one way or another. All frontend/backend paradigms suck, in one way or another. This constant churn of new, new, new is a waste. It gets replaced every few years, meaning all the time, effort and money sucked into it is gone. And engineers re-learn the same lessons over, and over, and over again. All so software engineers can be happy, because they just like doing new things in newly complicated ways. It's like changing how we build houses every few years just for fun, with no benefit to the people eventually living in that home. We're definitely not saving them money or building them any faster.

devoutsalsa 5y ago
The churn keeps me employed :)
- deleted 5y ago
  [deleted]
Bancakes 5y ago
At this point learning C++ standards is like learning new frameworks. There is no escape other than reclusing to C (maybe not so bad!)
chrisweekly 5y ago
If you can only see the churn and froth, that doesn't mean there aren't great waves to surf; you might just need to paddle out to a better spot. https://remix.run https://remix.run is a prime example. It's new, and better, and simpler.
- captaincaveman 5y ago
  It's better for new people joining, each cycle brings some improvement over the last typically. It also equalizes the playing field every few years, you become an expert in the latest new thing as there isn't an old guard. Some new web framework comes along, you can invest in that and become leet, where its very difficult to start new in react today and achieve that. This isn't to say past experience isn't valuable or helps you adopt things more quickly, can make you cynical about the new shiny and sometimes miss out on the actual improvements, even if small. I

bovermyer 5y ago

Initially, I thought this was going to be about WASM, based on the title. // The thing about rendering and processing things server-side and relying on very little, if any, JavaScript is that it makes it possible to send very small amounts of data to the client but still handle demanding tasks. There's something to be said for making a website usable for even the most anemic of client hardware.

fenk85 5y ago

Would love to see Kotlin (more) on the frontend Its a nice language all around on backend (and i suppose mobile, but i wouldnt know) thats a pleasure to code in

bronlund 5y ago

lucasyvas 5y ago

I'm surprised this wasn't about WASM. Either way, I'm receptive to the "LiveView" model, but until such a time a server can deliver both HTML and server driven native UI for mobile interchangeably, I prefer the RPC approach. I don't want to develop: 1. Both an API for mobile and LiveView for web. OR 2. Create my own server driven UI paradigm for mobile. I find maintaining one architectural pattern simpler. I do want to support users with the best technology fit, but I don't see why I have to make this tradeoff. The platform holders are (and always have been) jerking us around. I want to see a LiveView that can deliver both HTML and equivalent native UI markup. This is needed to sell the vision end to end - the world is not just web. I feel like this would enable a more sensible choice: Offline (first)? Use RPC with sync. Online-only? Use the LiveView paradigm and it'll work with native or web.

funcDropShadow 5y ago
As always, this depends on the use case. For in-house applications it is often far simpler to keep a lightweight frontend and mobile app is often of no concern. For these kinds of web application a server-heavy architecture was always a good choice.
- lucasyvas 5y ago
  Of course, this is true. But I prefer architectural patterns that are flexible for future use cases, especially when there's no logical reason why it shouldn't be supported. You can start this way, but if you have a new requirement, you might reach a technological crossroad and ask yourself "why do I have to add a new paradigm? If the thing I'm already using could just do X, I'd save a shit load of time and/or money." You can always add, yes. But why do I have to? The world has treated web and native as separate for far too long. We're really just squabbling over UI toolkits, so why can't we come up with something that just says "Fuck it, we're supporting both native and web as first class in every server framework because that's how it should be. And we're also going to let you use any language in the browser because that's how it should be"
  - girvo 5y ago

jasfi 5y ago

I'm working on something like this: https://nexusdev.tools/ https://nexusdev.tools/ Designed to support multiple back-ends and front-ends. The first back-end will be Nim and the first front-end will be Flutter.

ojr 5y ago

Javascript on the server-side has gone from something that was advised to never be used in production. Now it is so ubiquitous that people are trying to replace it with something new and more strict and less freedom... I am fan of modern javascript, I don’t complain or mad about the fast rate of change and improvement in the language. I kept up with all the latest javascript tools and now can build full-stack applications on mobile and web with very similar codebases faster than ever.

tifadg1 5y ago

What does that bring to the table though? You'll still need to write html, css and javascript (or some dsl). As a hobbyist Python dev who doesn't want to deal with frontend bs more than absolutely needed, I found my perfect stack - fastapi, svelte and tailwindcss.

hoistbypetard 5y ago
With a similar outlook to yours, I landed on django, htmx and tailwindcss. I had started down the path of fastapi, svelte and tailwindcss, but when I figured out that htmx let me use server-rendered templates, getting rid of the api and the packaging toolchain felt more ergonomic. And if you're doing server-rendered things instead of APIs, django has a few more batteries included. (But I really like fastapi for APIs.)
lawik 5y ago
LiveView? It lets you not write JavaScript. Or depending on your needs, very little Javascript. Less need for an API-layer and related contracts. You can still use Tailwind CSS. Works quite nicely.
threeseed 5y ago
I use Scala.js and since my entire stack is all Scala I don't need: - 2x developers - 2x CI/CD stacks - 2x build tools - 2x model classes - 2x instrumentation code I could keep going but it's a pretty significant improvement especially for small teams or solo developers.

gumby 5y ago

Why not just deploy X windows and run the browser on the server as well? (Pun semi-intended)

floatboth 5y ago
Heh, GTK has a "Broadway" backend for running in a browser, though I don't think WebKitGTK will work on it…
pklausler 5y ago
Because the "server" and "client" names would be reversed.
- gumby 5y ago
  In this case it would be a server at each end so you could claim that all computation and rendering was "done on the server"
funcDropShadow 5y ago
Let's take this question serious for a moment. Modern X applications render bitmaps which get shipped over the compositor and the X server to the graphics card driver. That is not a good model for the web, because it would mean the web server has to produce rendered bitmaps, specific for the fonts, window size, and display panel led configuration over the web. The browser cannot even select text or provide a search dialog. That is almost VNC. But originally, X applications didn't render bitmaps but submitted drawing calls. Sun used to use Postscript for that. So using that approach, it would be possible for the browser to select text, to scroll, to copy text, to search text etc. A clear improvement. But resizing the browser window would still need a complete re-transmission from the server. But if the web server sends static html, css, and a fixed JS library, which is used to replace parts of the dom, the browser can do a lot more locally. And still the whole application logic resides on the server.
- skocznymroczny 5y ago
  > because it would mean the web server has to produce rendered bitmaps, specific for the fonts, window size, and display panel led configuration over the web. The browser cannot even select text or provide a search dialog. That is almost VNC. So not much different than "modern" <canvas> based apps.

Tarucho 5y ago

How do these tools work? Are they like ASP.NET Webforms?

DerArzt 5y ago
The gist I was able to glean, specifically about Pheonix Liveview, is that all updates on the Frontend and Backend are pushed to the other side via websockets. For the Frontend, this means sending some json payload to the Backend. For the Backend this means either responding to a request or sending out a new update both of which involve sending out a snippet of pre-rendered HTML to replace/update an existing element that was already on page. The benefit here is that we can get to a place that is almost a SPA without needing to do a whole lot of JavaScript for the Frontend. It also helps that Elixir is built on top of Erlang which gives it a boon to be able to handle a lot of users on one server.
- lawik 5y ago
  There is also a bundle of clever implementation which means the templates are aware of what parts are static and what parts are dynamic. So they can send optimized changes, essentially small diffs, for the dynamic parts as they change. Often this means only sending the values for your text input field, not any of the markup for the field.

jacky2wong 5y ago

Not to mention streamlit, gradio, plotly for Python :)

ivanmontillam 5y ago

I've been looking for this for a long while. I am surprised that there are no browsers that can support other languages. My ideal architecture is to have a browser where you can select your front-end language interpreter, as in a Chromium + V8 + CPython + Whatever front-end processor you might want (Brython[0] achieves this, but transpiling to JavaScript). What doesn't make sense to me is that JavaScript has genuinely been the only language for the front-end, and it has been a monopoly for many years. Of course, there are other great languages like TypeScript, but these end up anyway transpiled to JavaScript, which to me feels like mounting your skyscraper over dunes. Not to hate on JavaScript, but JavaScript has grown too quirky for my tastes and that's why I've been away a lot from front-end development. There are efforts to fix it, with the new ECMA standards, but I don't feel it's going anywhere unless breaking changes are introduced to modernize the language. The fact that you have to "patch" your scripts with 'strict mode' on the top of the file speaks a lot of being defensive with programming. WASM is a solution to this, except you're not supposed to write WASM yourself. I want web development to be more straightforward, like the old days, where you didn't have to "compile" or "package" anything, and you just did your thing, and that worked. -- [0]: https://brython.info/ https://brython.info/

ihateolives 5y ago
I'm really sad that Dart didn't make it as Javascript replacement. It's much better designed language, but didn't get traction.
- BoorishBears 5y ago
  Dart is not fhat much better. In a period where most languages are experiencing a "rebirth" as a well thought out modern language, Dart feels like the "before" waiting for an "after". I'd be deeply disappointed if we had progressed from Js to Dart, and it's why I'm not a fan of Flutter (Java => Kotlin, Obj C => Swift, Js => Ts, Erlang => Elixr, etc.)
  - pjmlp 5y ago
    > Java => Kotlin, If you are speaking of Android, yes. On the JVM is it just one more guest on the building. https://madnight.github.io/githut/#/pull_requests/2021/4 https://madnight.github.io/githut/#/pull_requests/2021/4

cestith 5y ago

It's almost like what some of us did 15 years ago, use just enough JS to load things into the DOM fetched from the backend via XMLHttpRequest, is news now. Having a Websocket open to the backend and using a front end that's aware of that instead of using HTTPS seems to be the major difference here. That difference is more about WebSockets existing now than about the choice of backend language or the server-rendered, frontend-refreshed display model.

tluyben2 5y ago
We wrote a framework 15 years ago (almost exactly) that took rendered snippets from the servers and plugged them into the DOM; https://flexlists.com https://flexlists.com is 15 years old and uses that. It's really fast and was far easier to build with than all the manual jquery stuff. Fun times :) I should rewrite it in Liveview, seems a good fit.
chrismccord 5y ago
The biggest difference (at least for Phoenix LiveView) is having a stateful backend represent the UI and we do away entirely with HTTP APIs/serializers/resolvers. So you get both interaction and push updates from the server at any time, without HTTP glue layers. And it actually scales. So think React's functional-reactive-templates on the server, pushing minimal diffs over the wire better than if you'd carefully written an efficient JSON API or GraphQL endpoint. Elixir is also a distributed programming language so you also get things for free like sending an update to everyone's UI across the entire cluster.
- cestith 5y ago
  I think you're the only one to mention JSON or serialization at all. I do believe I already said websockets were the innovation, but they really literally did not exist 15 years ago for us to use. Elixir being distributed is nice. You still need the logic to get the change into everyone's session. You're just not using an external DB, cache layer, or work queue to do it. It's amazing, really, how people feel comfortable condescending to others who explain how we did things before the current technologies existed as if we could never grasp how the new technologies improve things. Yes, this is nice, but it's evolutionary, not revolutionary.

dnautics 5y ago

Chris McCord, quoted in the article, explains extremely well the absurd state of stateless http requests, from a perspective that is not appreciated in the article (queued to 40m50s): https://www.youtube.com/watch?v=XhNv1ikZNLs&list=PLqj39LCvnOWYTNs1n3ZNMSNO3Svv_XweT&t=40m50s https://www.youtube.com/watch?v=XhNv1ikZNLs&list=PLqj39LCvnO... The programming model (in liveview, don't know about blazor or hotwire or livewire) really lets you get better performance by doing less. A part of me sarcastically thinks wow, damn, deleting data is irreversible data transformation and therefore increases entropy, every stateless http request is inching us closer to the heat death of the universe.

lxe 5y ago
He just glosses over the "you can use a websocket API", which would solve most of the issues he's describing. There are a ton of websocket libraries that are easy to use. Do all the auth and session establishment once, and then communicate over websocket if you hate sending cookies and session data back and forth.
- fshr 5y ago
  No, you missed the point. Liveview works because there’s a stateful Elixir process on the backend for each open ws connection. This model doesn’t work in nearly any other backend option in any other language. If he glossed over the web socket option you’re glossing over the uselessness of the ws if the backend has the memory of a goldfish.

jbandela1 5y ago

The article actually left out one of the oldest frameworks for doing this: Wt https://www.webtoolkit.eu/wt https://www.webtoolkit.eu/wt It uses C++ to program a back-end application kind of like you would with with Qt, and then it does all the required Javascript/HTML to render your app in the browser. It is kind of like Qt for the web (painting with a very, very broad brush). I have also tried wasm with various Rust frameworks (Seed and Yew). However, for my latest project (triviarex.com) I ended up abandoning those in favor of React Javascript, however with a non-traditional architecture. The downside of these frameworks for me was tooling and turn around time and integration. React has great tooling, and it is easy to do live coding. In addition, there are a lot of pre-built components for Javascript frameworks and a ton of documentation. While there can be live coding with the backend, I guess because of my background, I like to use strongly typed languages in the backend to help catch logical errors earlier, and that requires a compilation step. So this is the architecture pattern that I am using. My backend is written in Rust in Actix, and each session is represented by an Actor. The React front-end establishes a web sockets connection to the actor, and sends commands to the actor, which are then parsed by the backend using Serde JSON, and handled using pattern matching. All the state and state transitions are handled on the backend which then sends the frontend a Javascript serialization of a Rust enum that describes what the state is, and what data is needed to render. The front-end basically has a series a if-else statements that match against the state and renders it. Most logical processing lives on the backend, and most of the buttons simply just send a web socket message to the backend. For me, this is the best of both worlds. I get the strong typing and correctness of Rust in the backend to manage the complexities of state management, and I get the flexibility and live coding of Javascript and React on the front-end to quickly and interactively develop the UI. Many times, I will be testing and see that the formatting or placement looks off, and I just quickly change the html/css/javascript and have it instantly appear.

deleted 5y ago

[deleted]

deepsun 5y ago

I remember JSF (Java Server Faces) and GWT (Google Web Toolkit). Both burned in flames. JSF: main idea is to abstract away boundary between server and client. Turns out -- you really want to know where that thing is running -- on the server or on the client. So it turned into a fight against that main idea of JSF. GWT: main idea is to forget JavaScript/DOM and write pure Java. Turns out -- you really need to know JavaScript and your DOM to write GWT. So it turned into a fight against that main idea of GWT.

culturedsystems 5y ago
JSF and GWT were rightly abandoned, but the new frameworks are different in ways that might be relevant. One of the main problems with JSF is the mismatch between it's stateful programming model, and HTTP's statelessness; as I understand it, LiveView uses a persistent websocket connection to a stateful server process, so that mismatch doesn't apply. Another JSF problem is it involves a component-based templating system that abstracts quite a long way from HTML, making it hard to figure out what's actually going on. LiveView, Hotwire, and htmx all seem to be much closer to HTML, which might make them easier to work with. I admit I'm still to scarred by JSF to be keen to try out these new frameworks and find out if they've actually solved these problems, but I'd love to read an evaluation of the new server-side frameworks from someone who experienced the problems with the old ones.
floatboth 5y ago
There was also https://liftweb.net https://liftweb.net in Scala…
taeric 5y ago
I am frequently surprised by folks that are active fans of both. So, I don't think they are dead dead. But GWT, in particular, really helped cement a ton of distrust for any framework coming out of Google. JSF was trying to make handy components for JSPs. And made them unusable in the process.
crnkofe 5y ago
I've worked quite a bit with JSF and although I was never a fan it does have some points. It allows for focusing more on contents than visuals also assuming the visuals won't be that fancy. There's plenty of apps that don't really require going all-out on eye candy. Note that it was always a problem when people do want eye candy. I also rarely had issues with performance but perf. is always an issue regardless of working with server- or client-side rendering. I pray for WASM to eventually replace JS. NodeJS ecosystem with all the experimental features, job ads in update notes, shitload of dependencies, one-function packages, legacy JS is a special kind of pain that I avoid whenever I can.

cies 5y ago

There is not BE or FE lang. The browser (the universal VM) just only takes JS and WASM at the moment. So they can be considered browser NATIVE. TypeScript is not native. Is it then also a BE lang? What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". And the second group has managed to compile more-and-more of it's langs to JS and WASM.

jayd16 5y ago
It seems like a silly point to make considering the actual content of the article. It's talking about server-side rendering. While the title might be a little provocative, its certainly talking about rendering UI (the front end) using whatever language you used on the back end, even if it was JS.
Zababa 5y ago
> What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". I think the opposite, the rift has been healing. It seemed that it was pretty big in the 2010's (Python/Ruby/Perl vs Java/C#/C++) but these days we have TypeScript, Rust, Kotlin; Java and C# are getting better too (type inference), Python and Ruby are getting typechecking.
- cies 5y ago
  > healing > these days we have TypeScript, Rust, Kotlin; Java and C# are getting better too (type inference), Python and Ruby are getting typechecking everyone caves to the types. i think the strongest holdout is probably the LISP/Clojure corner. they have optional typing for along time, but it is not used that much afaik many have voiced their reasons for liking dynamic typing. i only have one: faster reload cycles while developing. the other pros of dynamic typing are all over shadowed by their inherent downsides.
  - smasher164 5y ago

kuon 5y ago

I just shipped my fourth large project based on Phoenix LiveView and I think it is the best thing that happened to web dev since forever. The javascript is minimal (like to manage selection in text field or to handle copy/paste). Everything else is in elixir. Tailwind is used for CSS. Having the full client state available on the backend is really incredible. It is so much easier, no more ajax/graphql... You just have all your backend data "under your fingers". I can only recommend giving it a try. Also, if your app is offline first, phoenix channels are great for sync. It is not live view, but it is easier to use than ajax calls.

jon1628492 5y ago
A question from a newcomer to the ecosystem: do you have any recommendations for an admin system like Django's? On a related note, how do you usually determine whether a package is abandoned vs stable?
- dnautics 5y ago
  The crazy thing is that most elixir packages that are abandoned still basically work. This is both a blessing and a curse all around
_xnmw 5y ago
> Having the full client state available on the backend is really incredible. Got the exact same feeling writing my latest app with Laravel Livewire. The ability to use backend state seamlessly on the frontend without explicitly passing state back and forth reduces complexity so much it's like writing 1 application instead of 2. I was able to build rich, fully interactive apps with minimal JS -- I'll never go back to React again.
vasergen 5y ago
out of curiousity, how difficult to support large project in elixir, especially refactoring, giving there is no static typing. I know about pattern matching, which helps, but interesting to hear practical experiance

airocker 5y ago

How does this approach compare/differ from using something like mighty app where you stream a video to the ui and take gestures to the server?

bo0tzz 5y ago
This is a lot lighter than a video stream, and probably somewhat less latency sensitive as well.

Khelavaster 5y ago

Backend languages came to the frontend with Unity and Silverlight..

wallscratch 5y ago

Any thoughts on anvil? It’s a full-stack python framework. I think it features a python to js transpiler: https://anvil.works/blog/client-side-python https://anvil.works/blog/client-side-python

g42gregory 5y ago

I would love to see Python running natively in the browser and to be able to use Python instead of JavaScript.

mlboss 5y ago
You can try wasm based approaches. Some related frameworks: https://github.com/pyodide/pyodide https://github.com/pyodide/pyodide https://github.com/wasmerio/wasmer-python https://github.com/wasmerio/wasmer-python

rr808 5y ago

I keep waiting for something better than js/ts to do frontends so I dont have to learn it. I'm still waiting... I thought wasm would have gotten further along by now.

ironmagma 5y ago
Pretty much any wasm language will require a JS runtime somewhere if you’re going to do substantial things with it, so might as well learn it either way.
- rr808 5y ago
  Really though? I think wasm app will be able to write to DOM so no JS required, it can't yet but seems inevitable.
  - ironmagma 5y ago
    I’m not an expert, but DOM APIs seem particularly suited to JavaScript. There is probably a way to handle it via Wasm, but this is a bit like avoiding learning C when writing native code.

sergiotapia 5y ago

We use Liveview exclusively for our app (https://www.grilla.gg/ https://www.grilla.gg/) and I'm happy every day we can build stuff like this with very minimal javascript. Happy to answer any questions about what it's like to run a startup using liveview.

brtkdotse 5y ago

I couldn’t care less about the actual language. What I do care about is not having to maintain two separate tool chains and package managers, one for backend and one for front end.

Toine 5y ago
Doesn't NextJS solve this ?

metadat 5y ago

What is this GitHub.com/readme special alias? I hate it. Very annoying presentation format and it breaks the GH URL structure consistency.

2ion 5y ago

Ha. WASM with QtCreator and Qt w/ C++ would have put a decade of web developers out of a job had it launched in 2010. Most amusing about front end is that stuff like flexbox, nice animations and GPU-accelerated graphics based on web tech get praised and hailed as innovation yet we had that stuff on the desktop for years and years already way before the web bros rediscovered everything 2010-2020.

deleted 5y ago
[deleted]
lpghatguy 5y ago
C++ is not nearly as productive a language for most programmers in the world as JavaScript. Qt is not a panacea, even for desktop apps. The condescending tone to web developers is very strange and not very nice.
- 2ion 5y ago
  > Qt is not a panacea, even for desktop apps My point is: all achievements in web dev modularity and features have been present in Visual Basic, Delphi, TurboC++, Java and Qt since the early 2000s. Fully hardware accelerated UIs to boot. Well, we decided to move it all into the browser sandbox and start from scratch. Tools like QtCreator or the VisualBasic form editor got replaced by an expensive toolchain ranging from Adobe products to 1000 npm packages.

dorianmariefr 5y ago

or you could use ruby on the backend and javascript on the client

deleted 5y ago

[deleted]

derekzhouzhen 5y ago

There are 3 different kinds of web applications: * smart front end, dumb back end. This is the SPA model * dumb front end, smart back end. This is the old school model * smart front end, smart back end. This is the new school model If you can get away with the SPA model, by all means do it. Liveview is not going to challenge that. What it is doing, is to give new live to the old school model so you can avoid the complexity of having both a smart front end and a smart back end for a large percentage of applications. A smart/smart system is an asymmetric distributed system, a beast to handle for gurus and novices and everyone in between.

softwarebeware 5y ago

I don't really get the terminology of "backend" and "frontend" languages. To me, JavaScript is just a dialect of C anyway and the browser is just an OS. It doesn't make any sense to specify any particular usage except to acknowledge that for frontend development, JavaScript is the most popular choice. And so what? Most frameworks (like Angular) are heavily-based in patterns that came from other languages.

anthonybsd 5y ago

Around 15 years ago I needed to build an internal app for my company that would aggregate and display a lot of data. Our backends were all in Java and I had sour taste for JavaScript from a previous project so I looked around for an AJAX framework that would allow me to avoid writing any JavaScript. Lo and Behold there were actually 2 viable ones on the market: Google GWT and Echo2. I played with both of them and Echo2 blew me away. It looked and acted better than anything else on the market at the time. Rich widgets, translucency, works in (almost) any browser, etc. I rolled an app with it. The mechanism of operation was pretty similar to LiveView except WebSockets didn't exist at the time so it worked by having a super thin JavaScript client that polled the web server on the regular basis. So yeah, a bit chatty but for intranet app I didn't care much. Everything worked and felt like it was a Java Swing app but in a browser. The app became popular and we started writing extensions to it and adding modules. Then inevitable customization came. "Can we create a widget that does X?" "Ughh let me take a look.". This is when my nightmare began. Writing a new widget for this thing required putting together some utterly nightmarish JavaScript code and then compiling it together with equally nightmarish piece of Java code. If you had any custom stylesheet you basically were screwed. So roughly 2 years down the road from starting the project I started rewriting it in pure JavaScript and ExtJS (now called Sencha), which was one of the first few juggernaut frameworks for writing SPAs circa 2007-2008. That's why when things like Blazor and LiveView roll around I get flashbacks akin to post traumatic stress disorder.

chrismccord 5y ago
I remember when Sencha came on the scene :) WebSocket's help for more efficient bidirectional comms and guarantee load-balanced process placement, but LiveView can also be used with long polling if folks have a hard requirement. We also have much better DOM apis for things like efficient diffing/patching that I'm sure you lacked back then. Were you keeping stateful "widgets" on the Java side or hydrating from client state for interactions?
- anthonybsd 5y ago
  >We also have much better DOM apis for things like efficient diffing/patching >that I'm sure you lacked back then Oh I hope so. I marvel at React virtual DOM magic on daily basis so I'm sure it can be all done a lot more efficiently these days. >Were you keeping stateful "widgets" on the Java side or hydrating from client >state for interactions? IIRC it was 90% on the Java side. The default polling rate was something along the lines of 200 ms. So if you clicked a checkbox on the front end, it would perform the animation for clicking it on the front end but it wasn't considered checked until the backend was informed of it and signed off on it. In Java code if you had a listener for onClick you would write a normal Java method and it would get invoked normally with access to all your server stuff. As you can imagine, Echo2 server session objects could get pretty heavy. Reminded me a bit of mainframes and terminal clients lol :)

AzzieElbab 5y ago

I do not usually write front-end but when I do I use https://www.scala-js.org/ https://www.scala-js.org/

threeseed 5y ago
Best used with any of the following. Slinky React: https://slinky.dev https://slinky.dev Laminar: https://laminar.dev https://laminar.dev Diode: https://github.com/suzaku-io/diode https://github.com/suzaku-io/diode ZIO: https://zio.dev https://zio.dev

rglover 5y ago

What's incredibly frustrating about the knocks on JavaScript is that it's not a shortcoming of the language that creates the problems hinted here, but the poorly-considered engineering choices of the popular frameworks. After building my own framework [1] last year, I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HTTP distilled down to its absolute essence is brilliant, but for some reason gets absolutely ignored in the JS world. When you couple that with websockets for incremental updates (similar to what Chris McCord is doing in Phoenix), it's insanely powerful. It can be reasonably lightweight, too, if you're only shipping the JS you need to render the page. That rendering some HTML, CSS, and interactive JS in a browser has been turned into what it has is staggering. Though, not surprising, when you realize a lot of the momentum in JavaScript the last decade or so was perpetuated by venture capital (and the inevitable fast and cheap nature of that world) being pumped into inexperienced teams. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick

mavelikara 5y ago
> I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HTTP distilled down to its absolute essence is brilliant, but for some reason gets absolutely ignored in the JS world. Can you please elaborate what these areas of disconnect are? I looked at Joystick documentation hoping to find more of your thoughts this topic, but could not.
- rglover 5y ago
  I've tried writing a response to you a few times but realizing how complex it is—the real answer to your question is worthy of a long blog post. The core problem is the blurring of the lines between a framework and the underlying technologies of the web (HTML, CSS, and JavaScript). To me, it seemed like a lot of unnecessary complexity was being added just to achieve the common goal of rendering some HTML, styling it with CSS, and making it interactive with JavaScript (what I refer to in conversation as a "need to look smart" or "justify having a CS degree"). For example, introducing a new syntax/language like JSX (and the compiler/interpretation code) when plain HTML is simple and obvious. The drive to make everything happen on the client leading to vendor lock-in by third-party providers to fill the gaps of having a database (e.g., Firebase/Supabase). Making routing seem like some complex thing instead of a URL being typed into a browser, a server mapping it to some HTML, and then returning that HTML. Where this really became clear to me was in the resulting developer experience. I've been teaching devs 1-on-1 since ~2015 and had a bird's eye view of what it was like using these tools across the spectrum of competency (beginner, intermediate, advanced). The one consistent theme was confusion about how X framework mapped back to HTML in the browser. That confusion was handled in one of two ways: making messes in the codebase to solve a simple problem (e.g., lord help me with the nested routing in React) or giving up entirely. As an educator, the latter was especially bothersome because the transition from basic web dev to these JS frameworks was so jarring for some, they just didn't want to bother. That shouldn't happen. --- I'd like to elaborate on these things a bit more. Can you send an email to ryan.glover@cheatcode.co so I can remember to follow up once I've organized the post I've hinted at above?

zekrioca 5y ago

Why no words about WebAssembly/WASM?

throw10920 5y ago

I would like something explained to me. When webapp logic happens on the client side, that results in slow applications (n.b. for normal users on low-end hardware, not developers on high-end hardware) due to CPU costs. When webapp logic happens on the server side, that results in slow applications (n.b. for users on unreliable residential, mobile cellular, or rural connections, not those living with fiber) due to network latency. Doesn't Liveview (and related techs) simply make the slowness a stronger function of internet quality (as opposed to available processing power), instead of actually making the application less dependent on either of those factors for performance?

di4na 5y ago
No because network latency is not that big on unreliable connections if the exchange are "small" and relatively "rare". Which is most applications on the web, particularly with these techniques.
austincheney 5y ago
> When webapp logic happens on the client side, that results in slow applications (n.b. for normal users on low-end hardware, not developers on high-end hardware) due to CPU costs. Its not CPU. Its bad software written by people who are poorly trained and have no leadership. Do you really need 10mb of JavaScript and 10 seconds of load time to dynamically put a few lines of text on the screen? Yes, absolutely you do, because people don't know how to do it efficiently. This is a people problem, and not a technology problem. Hardware does not solve that problem. The actual technology is actually insane fast. As a counterpoint my personal app loads an OS GUI with state restoration using 2mb of JS code (unminified) in about 150ms.
- threeseed 5y ago
  > because people don't know how to do it efficiently Of course we do. We just choose not to bother because delivering features efficiently is often more valuable than shaving off a few seconds of download time. Especially when it's typically once off and then cached.

collaborative 5y ago

From a costing perspective, - hosting a web sockets server is expensive - bandwith is cheap - client cpu is free So a lightweight, modern SPA wins in this case

princevegeta89 5y ago

Yes please; everyone who hates Javascript needs this so bad.

girafffe_i 5y ago

No JSP love for Java.

theptip 5y ago

I'd love to see this approach make more headway in the Django community. Based on the last DjangoCon it seems like the community is coalescing around HTMX. This tool does play very nicely with Django's templating engine; you can just have HTMX re-render a particular template block on the server, and send down that updated block. The migration path is quite clean; you just wrap your "HTMX-updated" template block in a `hx-post` div. Having not gone too deep on HTMX, I'm interested in folks' thoughts on where it's lacking vs. LiveView and Hotwire. One area I can see is performance; Elixir is going to be faster than Django, and so if you're trying to handle high session counts over websockets. But the impression I get is that HTMX is a bit more light-weight, so I'm wondering if there's usecases that can't be met with it vs. LiveView. Other Django libraries that haven't quite seen as much uptake: We have https://github.com/edelvalle/reactor https://github.com/edelvalle/reactor, and a port of Hotwire: https://github.com/hotwire-django https://github.com/hotwire-django but both of these don't seem to have much adoption (yet!).