Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Back-end languages are coming to the front-end

github.com

Post reply on HN
Print view View original

231–240 of 328 posts

Re: Back-end languages are coming to the front-end

#231

Post by ledgerdev »

polyrand wrote: post #214
ledgerdev wrote: post #138

Earlier quoted context omitted.

So, I have only been working in htmx for about a week on a multi step checkout app, and while it's been mostly awesome, I think I ran into the Achilles heel of htmx, form state and the back button. In short of you enter data into a form then htmx push navigate away, when you click the browser back button you get the dom as it was originally delivered from the server, without any data the user might have entered into…

The thing about HTMX is that the mental model about state should tend towards "the server is aware of everything". With the added benefit that you can achieve better RESTful URLs that respect the navigation actions. Without having tried this (but having used HTMX quite a lot), I would try the following (let me know if I didn't understand the problem correctly): Checkout has the following URLs, one for each step: * pa…

> 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.

EDIT: tried multiple divs on same page, same behavior so that will not work.

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.

Re: Back-end languages are coming to the front-end

#232

Post by patrec »

ecnahc515 wrote: post #168
patrec wrote: post #145

Earlier quoted context omitted.

> NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. Uhm, has V8 come anywhere near LuaJIT's performance by now? And LuaJIT is basically a one-man effort.

To be fair, there's a bound how much the JIT/interpreter can do for a given language. Lua is a lot simpler, and a lot easier to optimize as a result, compared to JS.

I don't buy that.

If you squint a bit, Lua and Javascript are basically the same language. Lua shares many of javascript's peculiarities and warts (strings you can do arithmetic on, all numbers are doubles (originally), arrays are objects are hashtables of sorts, global scope by default etc). Now it's of course true that Lua is less of a mess than javascript, but a) the complexity explosion of javascript postdates V8 quite a bit b) lua has plenty of optimization challenges of its own that javascript lacks (e.g. metatables) c) the relative amount of resources poured into both projects differ by orders of magnitude (3?). I'm pretty doubtful anyone tasked to build the fastest JIT in the world from scratch upon being offered a choice between targetting lua (with luajit's total budget) and javascript (with v8's total budget) would pick lua.

Re: Back-end languages are coming to the front-end

#233

Post by mavelikara »

rglover wrote: post #223

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. HT…

> 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.

Re: Back-end languages are coming to the front-end

#234

Post by erik_seaberg »

samhw wrote: post #167
jvanderbot wrote: post #155

Earlier quoted context omitted.

My CS advisor in undergrad stirred a love of safety in me with Ada. I've always wanted to get back into it. Recent headlines have made me think that Rust will move in that domain. In 10 years, probably a lot of safety-critical systems will use a lot of Rust. Ada was (to my knowledge) never particularly well accepted by "the masses", whereas Rust is. It was just too early.

Oh, nice! No, Ada doesn't seem ever to have achieved the same mainstream adoption, or at least awareness, that Rust has. Which is startling to me, because it's comparable to Rust in performance while being far far greater in safety, including inbuilt support for design-by-contract (honestly I feel like I'm shouting at a brick wall trying to get people to understand the benefits of DbC; Rust's type system is only a fi…

Back when I learned Ada it didn’t have a solution for use-after-free, does DbC fix that by expressing ownership and sharing?

Re: Back-end languages are coming to the front-end

#235

Post by YEwSdObPQT »

Trasmatta wrote: post #227
YEwSdObPQT wrote: post #197

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.

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.

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.

Re: Back-end languages are coming to the front-end

#236

Post by oscargrouch »

lucasyvas wrote: post #25

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…

> I feel like this would enable a more sensible choice:

I have a working solution for something like this that is based on Chrome

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, OnDocumentLoaded, OnVisible, OnFirstPaint, etc..).

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.

Note that the daemon process who is always running give access to "push messages", so even if no UI app are running things can still work, like syncing into the DB, or even launching a new UI application given some event.. This service process also is pinged back by the web-UI process for every event, so the daemon process can also act when theres a need (when everything is loaded on the UI, do this..)

Also about the article, note that with this solution you will code in pure Swift (not WASM) just like the article is pointing out the web applications that can be built without any javascript.

Other languages like Rust, C++, Python can be added giving the Swift applications are talking to the runtime through a C api. (And i could use some help from other developers who also want this in other languages)

If you want to ship your applications with this, you will get a much better environment than Electron, using much less resources, as things are being shared to every application, and the cool part is the applications can consume one another services (for instance a Mailer application) forming a network, and depending one-another (the magic here is that they are all centrally managed by a core process that is always running)

Re: Back-end languages are coming to the front-end

#237

Post by delbronski »

ledgerdev wrote: post #138
girvo wrote: post #5

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 tool…

So, I have only been working in htmx for about a week on a multi step checkout app, and while it's been mostly awesome, I think I ran into the Achilles heel of htmx, form state and the back button. In short of you enter data into a form then htmx push navigate away, when you click the browser back button you get the dom as it was originally delivered from the server, without any data the user might have entered into…

One approach you can try is using the localStoeage API to temporarily store the form data of the user. I have done something similar in the past. You can use a light library like Alpine JS to make this work nicely. When the form renders, check if there is any temporary form data in localStorage, if so initialize the form with that. When the user saves the form remember to clear localStorage. This works nicely because even if the user closes the browser or something by mistake it is all there, and you don't need to keep temporary data around in your database.

Re: Back-end languages are coming to the front-end

#238

Post by the_sleaze9 »

skydhash wrote: post #228
rglover wrote: post #223

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. HT…

Most languages are quite tough to get into. And they require some real learning if you want to do anything trivial. JS is easy to get started (only the browser you already have) and you can do quite a lot without understanding anything about computer science. But it catches to you anyway. I've seen on Twitter someone repelled by the MDN documentation, describing it as not intuitive. I realized that the documentation…

What do bootcamps have to do with anything?

Re: Back-end languages are coming to the front-end

#239

Post by mostertoaster »

skydhash wrote: post #228
rglover wrote: post #223

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. HT…

Most languages are quite tough to get into. And they require some real learning if you want to do anything trivial. JS is easy to get started (only the browser you already have) and you can do quite a lot without understanding anything about computer science. But it catches to you anyway. I've seen on Twitter someone repelled by the MDN documentation, describing it as not intuitive. I realized that the documentation…

That seems crazy. I feel like MDN documentation is done so well. It balances well between giving good examples, and yet still remaining exhaustive in what it describes. Most extensive documentation ends up being less than useful and I have to fall back to just search results.

Re: Back-end languages are coming to the front-end

#240

Post by anthonybsd »

chrismccord wrote: post #222
anthonybsd wrote: post #216

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 Ech…

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…

>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 :)

Post reply on HN