In your Try it Online demo I could decrease ( ).
Would you mind creating an issue with some details (browser and version, maybe how to reproduce)? Thanks :)!
It works fine today!
Vanilla-todo: A case study on viable techniques for vanilla web development
141–150 of 154 posts
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#142Earlier quoted context omitted.
It’s moderately ironic to talk about poor connections (largely due to cell phone situations) without discussing the lackluster processing, memory, and battery life available on those cell phones. Not to mention the fact that SPAs tend to be significantly more heavyweight in their initial download requirements than server-powered forms, taxing those poor connections before you even see a single line of text. Again, th…
True, we should respect all the resources of a device, at best. Also true for desktop (Slack's memory usage comes to mind). A major result of the study is greatly reduced bandwidth (and consequently, shorter parse time) compared to the original TeuxDeux, so I'm working towards respecting these resources, for what it's worth. To be clear, the study does not care about doing SPAs or not. The results are applicable to s…
A small note: 100ms is effectively imperceptible to a human. Even 1s is acceptable in most cases. There’s a HCI study from the late 60’s that defines this.
WRT losing data by filling out a form, that hasn’t been an issue for years now (except when the “smart client renderer” decides that it is). Most browsers will not lose data in an interrupted form transmission.
Plus, most browsers (especially mobile ones) handle interruptions like a tunnel fairly well, waiting for the connection to return without losing data. And without having to think about that usecase as a web developer.
It’s funny to me that you mentioned slack above; some of my favorite old-school chat experiences were server-side rendered pages. They worked remarkably well for the limitations they faced.
All this said, the proper compromise is probably doing both client and server-side rendering. I’m reflexively against client side rendering, because of how they’re typically implemented: slow to download up front, each SPA creates its own interaction primitives, and finally the interactivity of an SPA is only rarely required and yet they’re used everywhere (read-only SPAs are the worst).
Javascript - and client-side rendering - is the power hammer of the frontend development world.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#143I don't know who originally said it but "If you're not using a framework, you're building a framework". This repo even has the following caveat: (2) These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. That said, I don't hate it. For quite some time, I've taken the stance that a web development team ne…
> These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. Often a custom micro-framework better suits the needs of a particular project. I've written micro-frameworks for specific projects intentionally, because they did a few things that the established frameworks either didn't do, or it was very difficu…
I'm sure there are exceptions (yours might be one) but this:
> I've written micro-frameworks for specific projects intentionally, because they did a few things that the established frameworks either didn't do, or it was very difficult to get them to do.
Is a false statement in most projects. I'd even argue in all projects except those that have a very strict limit on time or memory usage (or a legal one).
Can you share an example?
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#144It's amazing that a repository like this is even a thing. A demonstration that you don't need 3 million dependencies and a giant framework to build a simple application in the environment where a language was created to support.
I don’t see the point really. In the real world applications aren’t “simple”. They are complex.
Some applications are complex, many are simple (just over-engineered).
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#145Earlier quoted context omitted.
It’s moderately ironic to talk about poor connections (largely due to cell phone situations) without discussing the lackluster processing, memory, and battery life available on those cell phones. Not to mention the fact that SPAs tend to be significantly more heavyweight in their initial download requirements than server-powered forms, taxing those poor connections before you even see a single line of text. Again, th…
True, we should respect all the resources of a device, at best. Also true for desktop (Slack's memory usage comes to mind). A major result of the study is greatly reduced bandwidth (and consequently, shorter parse time) compared to the original TeuxDeux, so I'm working towards respecting these resources, for what it's worth. To be clear, the study does not care about doing SPAs or not. The results are applicable to s…
In theory.
In the real world my crusty old-fashioned drag-and-drop works way better than pretty much all "SPA"s (who are only trying to display plain text) on low/spotty connection. SPAs usually fail to display anything but a blank screen when there is a slow connection.
Losing form data hasn't been an issue in forever... The browser saves it when you go back or forward. You don't even need to press "back" - you can even just refresh the error page and as long as you click "yes" to the pop-up telling you you're resubmitting a POST, the form will submit with the original data entered, no problem.... Of course, SPAs like to break this for no reason, stop doing that.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#146Earlier quoted context omitted.
> These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. Often a custom micro-framework better suits the needs of a particular project. I've written micro-frameworks for specific projects intentionally, because they did a few things that the established frameworks either didn't do, or it was very difficu…
> Often a custom micro-framework better suits the needs of a particular project. Fitting the needs of a particular project is frequently a local optimum however. Often, it's much more optimal to focus on the needs of a whole team or even whole company. You can hire people who already know React/Vue/whatever, but there is no one in the world who knows your micro-framework.
It's always "tear it down" or "build it up" at the end of the day. Which one takes more effort is the right one to optimize for with your particular use case.
Rails vs Sinatra is a great example.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#147Earlier quoted context omitted.
True, we should respect all the resources of a device, at best. Also true for desktop (Slack's memory usage comes to mind). A major result of the study is greatly reduced bandwidth (and consequently, shorter parse time) compared to the original TeuxDeux, so I'm working towards respecting these resources, for what it's worth. To be clear, the study does not care about doing SPAs or not. The results are applicable to s…
A small note: 100ms is effectively imperceptible to a human. Even 1s is acceptable in most cases. There’s a HCI study from the late 60’s that defines this. WRT losing data by filling out a form, that hasn’t been an issue for years now (except when the “smart client renderer” decides that it is). Most browsers will not lose data in an interrupted form transmission. Plus, most browsers (especially mobile ones) handle i…
Not sure about the interruption handling, maybe I need to do more research there.
But totally agree with the last parts - currently, typical SPA implementations are often misguided and create more problems than they solve (if any) compared to a server-side approach. That does not mean that pure server-side is always enough to provide good UX, especially with interactive/offline apps.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#148Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#149We use task management apps to save us time and give more visibility over the work. However, the app can become so complicated to use by itself, that we may choose to go for very basic note-taking apps to avoid the complexity.
I was looking for a minimal, simple and user-friendly app for daily task management, so I developed Renoj.
Fast to-do task management in Desktop for ultimate productivity.
Website: https://ribal.dev/renoj
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#150Will uncompleted tasks move over to the next day?
Nope, apparently not.