JavaScript Views, the Hard Way – A Pattern for Writing UI
1–10 of 141 posts
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#2The read me says this approach is extremely maintainable, but I’m not sure I agree.
The design pattern is based on convention only. This means that a developer is free to stray from the convention whenever they want. In a complex app that many developers work on concurrently, it is very likely that at least one of them will stray from the convention at some point.
In comparison, a class based UI framework like UIKit on iOS forces all developers to stick to using a standard set of APIs to customize views. IMO this makes code way more predictable and this also makes it much more maintainable.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#3The read me says this approach is extremely maintainable, but I’m not sure I agree. The design pattern is based on convention only. This means that a developer is free to stray from the convention whenever they want. In a complex app that many developers work on concurrently, it is very likely that at least one of them will stray from the convention at some point. In comparison, a class based UI framework like UIKit…
Convention works when the culture is there, but I think you're right a dash of typescript and a class or interface definition could go a long ways.
I think the maintainability comes from easy debugging. Stack traces are sensible and the code is straightforward. Look at a React stack trace and nothing in the trace will tell you much about _your_ code.
I'd also point out that this looks like it's about seven years old. We've shifted a lot of norms in that time.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#4On my first official job after college I was working on making a web version of a Delphi software. The team was already on their third rewrite of the front end cause they had to change frameworks. I made the cass that we should write our own framework, so I prototyped FOS (the components I use on my website) to prove my point. The team (a bunch of mostly Delphi programmers) did not like my suggestion. Anyways, soon after that another company made me a better offer so I left. Years went by an I finally take a shot at another framework: tiny.js [1]. I've been using it in all my personal projects so far. I'm particular proud of the ColorPicker [2] component I wrote that I've used in two projects so far. As you can see, one can argue that tiny.js it's not a framework at all, just some wrapper functions that helps you create Functional components.
1 - https://github.com/victorqribeiro/TinyJS
2 - https://github.com/victorqribeiro/Chip8js/blob/master/js/Col...
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#5I came up with something similar recently, except it doesn't use template elements. It just uses functions and template literals. The function returns a string, which gets dumped into an existing element's innerHTML. Or, a new div element is created to dump it into. Re-rendering is pretty quick that way.
A significant issue I have with writing code this way is that the functions nest and it becomes very difficult to make them compose in a sane way.
function printPosts(posts) {
let content = ""
posts.forEach((post, i) => {
content += printPost(post)
})
window.posts.innerHTML = content
}
function printPost(post) {
return `
${post.parsed_text}
${post?.image_urls?.length > 0 ? printImage(`https://imghost.com${post.image_urls[0].original}`) : ''}
${post?.url_preview ? `${printPreview(post.url_preview)}` : ''}
${post?.quote_data ? `${printQuote(post.quote_data)}` : ''}
${post?.filtered ? `filtered by: ${post.filtered}` : ''}
`
}Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#6I came up with something similar recently, except it doesn't use template elements. It just uses functions and template literals. The function returns a string, which gets dumped into an existing element's innerHTML. Or, a new div element is created to dump it into. Re-rendering is pretty quick that way. A significant issue I have with writing code this way is that the functions nest and it becomes very difficult to…
I like it. Not only does it move the UI into JavaScript, but it moves the scripting into the HTML!
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#7It appears to be exactly the kind of manual-update code that reactive view libraries exist to replace.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#8It appears to be exactly the kind of manual-update code that reactive view libraries exist to replace.
It’s probably about time for that to become fashionable again
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#9I came up with something similar recently, except it doesn't use template elements. It just uses functions and template literals. The function returns a string, which gets dumped into an existing element's innerHTML. Or, a new div element is created to dump it into. Re-rendering is pretty quick that way. A significant issue I have with writing code this way is that the functions nest and it becomes very difficult to…
How do you update the html when something changes? For me, that's the most interesting question for these sorts of micro-frameworks - templating HTML or DOM nodes is super easy, but managing state and updates is hard.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#10I came up with something similar recently, except it doesn't use template elements. It just uses functions and template literals. The function returns a string, which gets dumped into an existing element's innerHTML. Or, a new div element is created to dump it into. Re-rendering is pretty quick that way. A significant issue I have with writing code this way is that the functions nest and it becomes very difficult to…
I like it. Not only does it move the UI into JavaScript, but it moves the scripting into the HTML!
Have a feeling this will lead to XSS vulnerabilities though.