211–220 of 328 posts
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 g…
Did you read the article or just the headline?
Earlier quoted context omitted.
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...
Compared to the Blazor tooling, the Typescript tooling is miles ahead imo. We did a Blazor app during a hackathon and I was pretty frustrated with how inconsistent the build errors were with blazor components. What makes me most skeptical about Blazor though, is that it's shifting a huge burden to the client just to make developers happy. Even if the runtime is stripped down and compiled to wasm, it seems kinda wild…
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…
Checkout has the following URLs, one for each step:
* page.com/checkout (optionally with ?step=0)
* page.com/checkout?step=1
* page.com/checkout?step=2
* page.com/checkout?step=3
1) Making sure the server knows how to render all those pages independently (like if the user does a hard-refresh or if they open that URL directly, without navigating to it through a link). Note: I believe this should be the default in any website if you respect the concept of a URL (whether client or server-side rendered).
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. E.g:
1. You need different URLs for each step. 2. Each URL should work both with HTMX (maybe using hx-push-url or the HX-Push header) and *without*. That is, any navigation to that page should also render the same HTML. 3. The server needs to be aware of the state. When a user requests page.com/checkout?step=2, the server should know if the HTML form requires pre-filled values.
This increases a bit the complexity on the server, but I believe it reduces the client-side complexity a lot more.
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 Jav…
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.
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 hav…
Earlier quoted context omitted.
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.)
> 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
Groovy was never really in the building and is just awful.
Scala is like a reimagining of the building that happened to find the old foundation useful.
Clojure is like a skybridge from the Lisp skyscraper across the way.
Kotlin is the only JVM language that's gained traction while aiming to be Java but better, the rest just happen to use the JVM, but calling them "evolutions" of Java would be deeply misleading.
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.
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...