DEV Community

Discussion on: Todo-MVP: Or 'Why You Shouldn't Use A Web Framework' - The Revenge

Collapse
 
gypsydave5 profile image
David Wickes • Edited

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

Collapse
 
solarliner profile image
🇨🇵️ Nathan Graule

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!

Thread Thread
 
gypsydave5 profile image
David Wickes

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!

Collapse
 
nssimeonov profile image
Templar++

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.

Thread Thread
 
codiiv profile image
Jay

Tadaaaa !!

Collapse
 
exbe profile image
exbe

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.

Thread Thread
 
quii profile image
Chris James

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.

Thread Thread
 
exbe profile image
exbe

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.