Live data from Hacker News

Vanilla-todo: A case study on viable techniques for vanilla web development

github.com

11–20 of 154 posts

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#11
post #5

I 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…

Can I claim I don't violate the "No general-purpose utility functions related to the DOM/UI" if I use only one such function? O:) https://github.com/stefanhaustein/notemplate (the demo is just TodoMVC, though)

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#13
post #10
post #7

The trick is to stop thinking XML/HTML and instead use functions which returns elements/components. First write the app in spaghetti code, then turn it into pure functions. var app = todoList(data); document.documentElement.appendChild(app);

In other words, the good old MVC pattern. (M) Model is your `data`. (V) View is what your function returns. (C) Controller is the functions your elements may use to mutate the data.

MVC doesn't mean "has data, logic, and UI". MVC is a model for how the UI communicates with the data store.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#14

> There's no custom framework invented here. Proceeds to literally invent a custom framework. It’s interesting, but I’ll stick with Vue/React.

Original author here. During the study, I explicitly forbid myself from writing general-purpose helpers which would make up a framework. Would you mind elaborating what in your view makes up the "custom framework"? Thanks!

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#15

> There's no custom framework invented here. Proceeds to literally invent a custom framework. It’s interesting, but I’ll stick with Vue/React.

> Proceeds to literally invent a custom framework.

What definition do you have of “framework” if you say that? I just see a bunch of procedures that create and manipulate DOM, coordinating through regular events and selectors. There are patterns and loose organizing principles, but no framework code that I can see.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#16
post #14

> There's no custom framework invented here. Proceeds to literally invent a custom framework. It’s interesting, but I’ll stick with Vue/React.

Original author here. During the study, I explicitly forbid myself from writing general-purpose helpers which would make up a framework. Would you mind elaborating what in your view makes up the "custom framework"? Thanks!

If general-purpose helpers make up a framework, then what is the difference between a library and a framework? I'm pretty sure jQuery is not a framework.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#17
post #5

I 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…

Thanks for reading - original author here. For the precise quote you mentioned I came up with somewhat format rules which prevented building a framework (code-wise) for this case study. The "caveat" you mention is just an explanation for the chosen ruleset; I believe I haven't introduced any general-purpose DOM/UI code in the case study and instead only describe patterns (correct me if I'm wrong!). I agree with your view of framework value as I professionally use React on a daily basis and will continue to do so, for similar reasons :)

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#18
post #11
post #5

I 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…

Can I claim I don't violate the "No general-purpose utility functions related to the DOM/UI" if I use only one such function? O:) https://github.com/stefanhaustein/notemplate (the demo is just TodoMVC, though)

:D just to be clear, the rules were made just for the case study. I'd never recommend following these rules in a professional project. They are part of the method of the case study, not its outcome; the outcome is a couple of (hopefully) interesting patterns and insights, without trying to prescribe anything.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#19
post #5

I 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…

Of the three you listed Vue is the most 'opinionated' in that it ships with official router, official store (vuex) etc and that is a huge deal.

With React and particulary svelte (for now) it's a mishmash of possible choices.

Where that bites is when you have 3 choices to make with 4 options.

4^3 === 64 - so any project you pick up/come onto has a 1/64 chance of using a stack you've seen before.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#20
post #5

I 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…

Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are constantly re-writing completely valid and working code to keep up with the latest version of the framework. The JS language itself, on the other hand, seems to be very stable with long deprecation cycles and steady improvements. So, it is much easier to build on.
Post reply on HN