re: Todo-MVP: Or 'Why You Shouldn't Use A Web Framework' - The Revenge VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I think the "Vanilla JS" approach shouldn't even use any backend. The way you've set up the projects with the backends feel very reminiscent of 90s...
 

Yes. That's exactly right. You will be redirected after an action and will see a new page.

So what? What does it miss in terms of the requirements of a todo-style application?

Having a global array storing the files, or even manipulating localStorage would be a 100x better way to compare this code to other frameworks.

Sounds like you're after a frontend only implementation - this project is explicitly avoiding frontend JS. Can I direct you towards the very worthy vanilla implementations on TodoMVC.

very reminiscent of 90s stuff

You make it sound like a bad thing...

 

Oh, I'm sorry, I misunderstood the scope of the project then.

You make it sound like a bad thing...

Well as a pure UX standpoint it's very bad as doing anything will prevent use interaction until the state is synced with the server. It's like the AJAX "spinner apps", although those already used client side JS... So admittedly more modern than this 😜

But as a To-do MVP example it is an area where the was none before - and maybe I can contribute with a Django or a Flask app some time!

I'd love to see a Django / Flask / Python pull request from you into Todo-MVP (I'm not very experienced with Python). Please let me know if I can help in any way!

 

Yes, it is. Networking eats time. Worse, the user experience is quite annoying on bad and unstable connections. Any smooth UX is doomed for people who is acessing the page from another half of the planet.

But not every site strive for smooth UI experiences for their users, which is ok.

Why are you asserting that you cannot have a "smooth UX" with this approach. What is not smooth about how it works now?

I'll tell you what isn't smooth, downloading megs of javascript and executing it on a low power device.

Because I was using 90xx web.

Page refresh doesn't happen fast enough as background interactions and rendering result as it arrives. This implies SOME logic on a client.

This is specifically true for remote sites. You will have at best speed of light delay before retrieving content. In worst case network fluctuations might give very annoying delay just to get new content. Yes, and you customer will be staring at WHITE page, because browser viewport have nothing to render.

This is why I am so assertive.
If you don't like it, fine - learn your way ;)

Modern browsers smart enough to cache your megs once and then transmit pure json back and forth, reducing overall need for bandwidth. Plus it happens behind the scene, so customer might enjoy that spinner animation or enjoy previously loaded content.

You can definitely (and should totally) not bundle and serve megs of Javascripts with each page but cherry pick for each necessity; and we also did invent SSR so you can for sure not show a white page on first load. You can do animations with CSS and handle DOM changes with a library like Preact which is like a handful of kilobytes, and still use plenty of vanilla JavaScript so you keep it fast and lean; even adopt stuff like Tachyons or FontAwesome if you want to ship something professional looking. All of this doesn't require megs and megs, just common sense and some tools made by awesome people you can find around.

Sure you could do it backwards and do it the good old fashioned way of "I click, it reloads", but then when the server will be slow or even go 504 users will complain it's slow and unreliable, while you could've used AJAX (which we've been doing for a looooong while now) and provided helpful, human readable status messages without sending your users out or even losing their work because your API aren't reliable.

You can also do both, use server side templating and use JS to augment the website and cache.

Basically what dev.to is doing and being pretty fast at it too.

There's no single way to build a website anymore and that's great for everyone, yeah the complexity of frontend programming is escalating, but there is a lot of innovation going on at the same time

 

I checked the vanilla js TodoMVC... and I don't like it. Too much code for problems solved hundreds of times. Take for example the template:

    function Template() {
        this.defaultTemplate
        =   '<li data-id="{{id}}" class="{{completed}}">'
        +       '<div class="view">'
        +           '<input class="toggle" type="checkbox" {{checked}}>'
        +           '<label>{{title}}</label>'
        +           '<button class="destroy"></button>'
        +       '</div>'
        +   '</li>';
    }

And then using string operations the app is replacing values:

            template = template.replace('{{id}}', data[i].id);
            template = template.replace('{{title}}', escape(data[i].title));

So much code... and the more you write the more bugs you may have... this is exactly what we all are trying to avoid - reinventing the wheel again and again.

code of conduct - report abuse