Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

131–140 of 154 posts

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

#131

Post by morrvs »

Thanks to everyone who took the time to read it, and thank you all so much for all the feedback! I'm quite overwhelmed by the response :) looking to address as much of the feedback as possible by the end of the week.

A major weakness seems to be my choice of ES5. I wanted an almost absolute minimum, which ES5 seemed to be at the time. I was lead by the fact that most bundlers produce ES5 by default, which may very well have been a mistake.

Interestingly, if ES5 is really dead (which it might be, I'm not sure) and ES6 is the minimum target, the study's results would actually improve drastically (less verbosity, actual modules, etc.) and further support the claim that vanilla can be maintainable (even without build steps). For anyone interested, let's continue the discussion here: https://github.com/morris/vanilla-todo/issues/6

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

#132

Post by falcolas »

morrvs wrote: post #128
falcolas wrote: post #76

Earlier quoted context omitted.

> if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side I'm not sure I personally agree with this blanket statement. Connection times can be, for a vast majority of users, measured in tens of milliseconds, giving us a pretty good budget for processing and rendering while still appearing to be "instantaneous" (100ms) or "…

I'm not an expert but I'm certain we aren't even close to providing this level of connectivity. Throttled data, sucky hotel wi-fi, underground tunnels, bad service in rural areas of e.g. Germany etc. are real, unfortunately. You cannot hope to get enough uptime and guaranteed response time ranges for an app's interactions from any server; you will always get inferior UX to client-side rendering (which, in a way, has…

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, the performance bar for SPAs has been set so low by top-100 sites (like Medium and other SPA blogs) that a server powered forms would have to work very hard to be worse.

As a side note, we can’t forget that even these “100% uptime” SPAs in the real world largely still rely on requests and responses from a server backend; still rely on prompt responses to their ‘XMLHttpRequest’ calls (hello, animated spinners!).

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

#133

Post by morrvs »

dreamcompiler wrote: post #129
falcolas wrote: post #76

Earlier quoted context omitted.

> if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side I'm not sure I personally agree with this blanket statement. Connection times can be, for a vast majority of users, measured in tens of milliseconds, giving us a pretty good budget for processing and rendering while still appearing to be "instantaneous" (100ms) or "…

Completely agree. I still build websites with server-side rendering and just enough JS for Ajax, which changes innerHTML and occasionally adds an element. They are astonishingly fast, and they still function if the client has JS turned off. I remain convinced that for 90% of websites, using React is shooting a sparrow with a cannon.

For what it's worth, the study was not targeting SPAs specifically. The patterns I found can very well be used to add some minimal behaviour to some HTML generated completely on the server side. I'm by no means advocating SPAs or client-side rendering for each and every use case.

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

#134

Post by morrvs »

falcolas wrote: post #132
morrvs wrote: post #128

Earlier quoted context omitted.

I'm not an expert but I'm certain we aren't even close to providing this level of connectivity. Throttled data, sucky hotel wi-fi, underground tunnels, bad service in rural areas of e.g. Germany etc. are real, unfortunately. You cannot hope to get enough uptime and guaranteed response time ranges for an app's interactions from any server; you will always get inferior UX to client-side rendering (which, in a way, has…

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 server-rendered HTML as well (write a function that enable some behavior on an element, mount by class name, done). I agree that many use cases (e.g. blogs) should mostly be server-rendered and only progressively enhanced with JS for some UX improvements.

But highly interactive apps (drag & drop just being one example) will not have comparable UX without client-side rendering. I do not want a 100-1000ms delay (or an error message) after dropping an item in some list because of a server-roundtrip. This is not good UX.

Also, when filling out a form, I do not want to lose data or context when clicking submit while I'm in a tunnel. I'd rather have a client-side rendered UI that keeps my context and tells me "Sorry, try again when you're connected again".

Even better if it works fully offline and syncs the transactions I've done with a backend once I'm connected again.

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

#135

Post by morrvs »

_the_inflator wrote: post #96
sfrinlan wrote: 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…

> adopting an established valid opinion to guide the team's development Different requirements allow for different settings. Coming from an Enterprise Application background, I found this being more often the case or the only case. Working with different teams, developer fluctuation, different time zones, different skill sets, a framework guides the development process far better. Vanilla JS is something that should…

I've heard the Assembly vs. C analogy a couple times now, and find it hard to apply:

Assembly languages come in many flavors whereas C is a single, standard abstraction over these.

DOM is a single, standard API whereas frameworks/libraries come in many, ever-changing flavors and provide different abstractions over the DOM.

It's a very different situation. Also, the level of abstraction that C provides over assembly is amazing. The level of abstraction that React provides over the DOM is comparably low (they are based on the same programming language).

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

#136

Post by dreamcompiler »

morrvs wrote: post #133
dreamcompiler wrote: post #129

Earlier quoted context omitted.

Completely agree. I still build websites with server-side rendering and just enough JS for Ajax, which changes innerHTML and occasionally adds an element. They are astonishingly fast, and they still function if the client has JS turned off. I remain convinced that for 90% of websites, using React is shooting a sparrow with a cannon.

For what it's worth, the study was not targeting SPAs specifically. The patterns I found can very well be used to add some minimal behaviour to some HTML generated completely on the server side. I'm by no means advocating SPAs or client-side rendering for each and every use case.

Understood. I do appreciate the effort you put into this and the fact that you built it from scratch. FWIW your example has convinced me to explore client-side rendering now that I know it doesn't require a monster library.

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

#137

Post by mcjkrw »

sfrinlan wrote: 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…

I have experimented with something like this for a new side project. The plan was to have a TypeScript class for each component, and a render function to render them on dom. Then the listeners would be handled directly via addEventListener. Eventually I started having thoughts like - "maybe I could have the render function parse attributes and auto-attach dom events".

It became obvious it would become a side project of its own and not a smart use of my time. I settled down for Svelte and I love it.

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

#138

Post by ehnto »

treespace89 wrote: post #86
ehnto wrote: post #33

Earlier quoted context omitted.

Using frameworks is far more about hiring and human resources than technology I feel. However, if your "micro framework" follows language idioms and is thin enough you get the best of both worlds, whilst releasing yourself from some of the downsides that come with using a general purpose framework.

Frameworks make hiring a bit easier it's true. I'm amazed at the number of developers who can't seem to cope with working with custom in house frameworks. I'm talking about fully working systems, with full source code and being walked through the code by the author / maintainer. They fall apart, constantly complaining that the approach is non standard, deprecated, dangerous, unprofessional, untestable. So we are tryi…

Definitely agree, developers can get away with a lot of missing knowledge and not realise it, if they're using frameworks from the start of their career.

Ideally you could hire senior developers with the skills to work inside boutique software, but I have found "legacy" code turns a lot of people off a project, and most boutique software eventually gets called "legacy" even if it's well architected and running perfectly fine.

The skill which I think new devs could differentiate themselves with, is debugging. Familiarising yourself with software patterns definitely puts you ahead, but being able to use debuggers to understand code that has no pattern, that's when you become the kind of bug-squasher/problem-solver that projects like that require. If you have good debugging skills, you can work on any project, because you can find out all the information you need by stepping through the code.

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

#139

Post by SahAssar »

ericmcer wrote: post #102
eliseumds wrote: post #94

Earlier quoted context omitted.

That's what OP means: https://codesandbox.io/s/elastic-rubin-hxpcw?file=/src/index... And that's why reconciliation algorithms became so popular. You can't be serious when you say that losing input focus and text selection have never been relevant to you. Basically, dealing with the internal state of components down the tree becomes a nightmare.

it is possible to track and set cursor location after updating innerHTML... it is definitely no longer simple and clean though haha. https://codesandbox.io/s/zealous-vaughan-qd3gg?file=/src/ind...

IIRC it will also lead to weird behavior for people using screenreaders, they usually restart saying whatever they where reading when the element was replaced even if the contents are the same.
Post reply on HN