251–260 of 328 posts
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'm happily using Phoenix+LiveView for a website that works as a PWA. This also includes offline mode with sync-when-internet-is-available functionality (thanks PouchDB!). This covers online/offline/mobile usecases, with no explicit RPC, and no requirements for the end device that the app would run on, other than a _capable_ browser. (Admittedly, browsers on iOS are gimped, but that's part of the Apple tax).
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.
- 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.
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 net…
> 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,…
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.
Earlier quoted context omitted.
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?
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…
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?
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…
Call me a heretic: I love PHP.
Earlier quoted context omitted.
> This is wrong; tests and type systems have different purposes. For decades, companies have prospered without a strong type system and using tests for type assurance ad hoc. Usually when it's worrisome or has been problematic. You can say it's wrong (conceptually, theoretically, etc) and yet it people continue to do it. That's interesting to think about.
don't think it matters since the upthread discussion is more about understanding and refactoring code, not ensuring correctness.
In any case I would refrain from using absolutes like "wrong" for something that clearly works for some people in certain circumstances.
Earlier quoted context omitted.
> 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 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.
Apparently not. A few seconds is a really big deal, but that is just download time while you are also clearly not accounting for execution time. Caching code will not save on execution time.
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=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…