Our great sponsors
-
> 2) If there's a form input at each step, the server needs to store that info and be aware that the user has an incomplete checkout. Now the user is at step=2 and presses the back button, or clicks on the step=1 link. In that case, the server should know the information stored in the point no. 2 above, and return an HTML form with the data pre-filled based on the last state.
The problem is that when you press back button in the browser, it doesn't make another request to the server. It reloads the page from browser memory. A link back can be made to work, but that's not what I was speaking to.
I tested the most trivial case, when you return a response, and push navigate to next step, then press browser back button, form state is not retained. Both chrome and firefox do not restore the form state on navigation back after a url push navigation.
I don't think that without some client side JS that saves/reloads prior form state this is a solvable problem because of browser behavior. Either that, or perhaps use different divs for each step then have js hide/show them which is what I will try next but involves writing js to do so.
It's pretty clear that htmx hasn't considered back button much at all, it also clobbers the page titles in history as well (https://github.com/bigskysoftware/htmx/issues/746), but that's a fixable problem.
-
SonarQube
Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.
-
I was going to mention that I was surprised htmx wasn't mentioned in the article. It's backend-agnostic an extremely easy to use. Drop in Alpine.js and I think you have a really powerful setup without writing any JS. I've been using this with Go[0] and enjoying it.
-
The article actually left out one of the oldest frameworks for doing this:
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.
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.
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.
-
You can try Django Unicorn (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.
-
-
-
Scout APM
Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.
-
I do not usually write front-end but when I do I use https://www.scala-js.org/
-
> I feel like this would enable a more sensible choice:
I'm working in something like this
https://github.com/mumba-org/mumba
The applications developers publish native, Swift applications, where Swift have the full access to the Webkit/Blink api the same way Javascript does and even more with the patterns from the Chromium renderer (for instance, access to lifetime events).
The offline first comes from the fact that every application runs first as a daemon which provide a gRPC api to the world of the services it offers, where the web-UI application process might also consume this same api from its daemon -process manager or from other applications.
-
-
-
-
I do use a virtual DOM but I only use it to patch the HTML in the browser (no synthetic events or anything like that). The meat of it starts here: https://github.com/cheatcode/joystick/blob/development/ui/sr....
My focus for v1 is on developer ergonomics and solidifying an API (this will be frozen after v1 with the only changes being additions if absolutely necessary—a component you write today will look identical to one you write in 10 years).
All future major versions will be solely focused on performance and security (my way of saying: I haven't stress-tested renders, but for the time being it will work well for the majority of use cases).
-
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, and a port of Hotwire: https://github.com/hotwire-django but both of these don't seem to have much adoption (yet!).
-
> No offence, but have you written any compilers or interpreters?
I have, but nothing sophisticated.
> The points that you discuss [...] may be performance concerns for application developers [...] but they have very little to do with the optimisations you can make as a compiler/interpreter writer. [...] The only one that's somewhat relevant is 'global scope by default'
I didn't mean to imply that these where the three common traits that make both Javascript and Lua particularly hard to optimize, I just picked them as examples for how Javascript and Lua are closer to each other than most other dynamic languages.
But let's dig in a bit on your claim that things like all numbers being doubles or having a array cum map cum record type has very little to do with the optimizations you can make as a compiler/interpreter writer, because it sure seems to me that LuaJIT and V8 do a bunch of optimizations around these things. Both have dual number representations under the hood and will try to avoid representing numbers that remain in the domain of 32 bit integers as double values internally when that gives performance gains. The logic for figuring out if that's the case doesn't seem to be super-straightforward or target architecture independent from looking at the comments in <https://github.com/LuaDist/luajit/blob/master/src/lj_opt_nar...>.
LuaJIT furthermore uses NaN tagging (as do some JS engines, although not V8), which looks less attractive to me as a representation strategy if your numbers are not all/mostly notional doubles (as is indeed the case in newer version of Lua where 64bit integers are the dominant number type)
Also, as far as the super-flexible lua tables are concerned, I'm pretty sure LuaJIT goes through some amount of trouble to specialize various common use cases of tables, e.g. as arrays without holes, and surprise, so does V8 (https://v8.dev/blog/fast-properties#elements-or-array-indexe...). I don't think you'd find something equivalent in a high performance scheme implementation.
> but this doesn't touch the surface of the issues that make JS hard to optimise, such as the fact that your, say, memoisation of an object property or method may be broken by an `eval` call of an arbitrary runtime value somewhere else in the code (which, due to asynchronicity, could take place at more or less any time from the point of view of your given 'peephole').
Eval belongs to a core set of features that basically all popular dynamic languages share that presents headaches for high performance implementations. How is Javascript's eval particularly problematic in this regard, and specifically much more so than Lua's loadstring/load?
More generally what do you think makes (pre-ES6) javascript significantly harder to optimize than lua 5.0?
