This is what you can end up with, managing all possible state changes manually. I've done this myself with jQuery, show/hide, enable/disable elements. Turns into a game of Whac-A-Mole and full-time job for testers. Now imagine adding/removing elements and having to update this monster. No thank you.<p><a href="https://github.com/bradwoods/7guis-html-css-js/blob/19279899799c45d381715ad725179818488e1e04/docs/flight-booker/index.js#L40-L94" rel="nofollow">https://github.com/bradwoods/7guis-html-css-js/blob/19279899...</a>
I like it, and it's also a good example of why a framework will start to be useful if you get more complex code.<p>When we arrive at the CRUD widget,a simple <script> dep on petite-vue (6ko: <a href="https://github.com/vuejs/petite-vue" rel="nofollow">https://github.com/vuejs/petite-vue</a>) would half the implementation by half.<p>Of course it would still count as more lines of code in total, but not sure that matters.<p>Anyway, when I teach react/vue, I always start with the vanilla example because just like with ORM, people need to know the benefit and cost of the abstraction.
A few years back I stumbled into something a bit more complex, still done in pure js, just for the hell of it: <a href="https://github.com/morris/vanilla-todo" rel="nofollow">https://github.com/morris/vanilla-todo</a><p>And then wrote my own version, with code a lot closer to modern react, with undo/redo and other niceties - <a href="https://github.com/ivank/vanilla-teuxdeux" rel="nofollow">https://github.com/ivank/vanilla-teuxdeux</a><p>And what I leaned is that is astonishingly easy to write code that would be understandable to people coming from the redux crowd. Maybe that’s because redux is just such a simple concept in and off itself - a glorified switch on a big object. And it’s also quite easy to hack a simple version of vdom to make it all work.<p>What’s missing from all those vanilla js efforts though turned out to be testability. There is a ton of code in the modern js world just to allow you to mock/test your components, and thats for me the real tragedy of vanilla js.<p>I have no idea why W3C crowd have not invested into standardizing js tests in all these years…
The Cells example is super interesting to me, because I've longed for an open source, liberally licensed, spreadsheet component for the web, similar to what exists for rich editing (ProseMirror, Slate, Quill). Some UI frameworks like Material UI have a neat table component, but the pro version gets the fancy data grid, and it isn't designed to be able to function as a spreadsheet anyway.<p>Besides lacking an open source version, spreadsheets and data grids haven't been studied as well as they should be.<p>It is also difficult to build one using just the DOM. For instance, you can't have a table be horizontally scrollable with the scrollbar fixed at the bottom and also have a fixed header.<p>Here's something I played around with a while back that has keyboard navigation between cells. Going between pages isn't great. The default focus scrolling in Chrome skips a few rows, and it doesn't respect the fixed header when scrolling up to the top after scrolling down. <a href="https://table-edit-20210409.vercel.app/" rel="nofollow">https://table-edit-20210409.vercel.app/</a> <a href="https://gitlab.com/ResourcesCo/table-edit-20210409" rel="nofollow">https://gitlab.com/ResourcesCo/table-edit-20210409</a> I tried making it with CSS Grid just to see if it could be done, and it turns out, only with Firefox. <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout/Subgrid" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...</a> I'm thinking of drawing it with JavaScript, perhaps with a combination of canvas and DOM elements.<p>Back to the 7 GUIs - what's great about it is trying to build stuff from scratch. So much of web development is just putting components together and customizing them, but there is a lot of lower level work to do, and the more developers that attempt it, the more progress will be made.<p>Edit: found this, pretty interesting: <a href="https://github.com/TonyGermaneri/canvas-datagrid" rel="nofollow">https://github.com/TonyGermaneri/canvas-datagrid</a>
These examples are very reassuring to me. Sometimes, after a long day of fighting whatever trendy JS framework my current project uses, I may be tempted to advocate for a "back to the basics" approach with vanilla JS or even jQuery.<p>Anything after the temperature converter example makes it painfully obvious that it would <i>not</i> be a pleasant experience.
The trick to write vanilla HTML is to make it <i>static</i> (no dynamic changes except layout/mobile responsiveness)
Meanwhile the trick to writing a statefull app in vanilla JS is to <i>not use HTML</i> instead create the DOM tree using JS functions which gives you the ability to use higher abstractions, local/private state management and automatic UX tests.
Now get that list of different implementations going.<p>I’ve been thinking of something similar, and this is a good list, but is it “exhaustive”? What would such a list look like? Is there an objective way to explore all the various challenges of building UI?<p>Here’s one example: Very large forms. This is not covered, and can be quite challenging, especially when different parts of the form show up at different times. Even vanilla React fits this poorly (this is where Flux came into being, which ultimately spurred Redux, Recoil etc).<p>But also a CLI. A flow chart. Notebooks (Jupyter). So many types of UI to cover.
The cells example would be improved by keeping the top left corner clear by making that cell stick in place and on top:<p><pre><code> #colHeadings .rowHeading {
z-index: 3;
top: 0;
}
</code></pre>
I also believe keyboard navigability is essential for the cells example, although the task specification neglected to mention it. (But then, the spec doesn’t specify anything about the formulas either—though it does include a picture depicting something like =SUM(B1:C4).) Tab and Shift+Tab work to shift cell focus, but that’s <i>all</i>; at the very least, Up/Down/Left/Right should work for cell navigation, and some way of entering edit mode without needing the mouse (start with F2, which is standard across spreadsheet apps that I know; perhaps Enter too, though they don’t).
Regarding the author's content online - great work! Nice minimal design with clean and bold lines, right alongside a fantasy and whimsical design from the early days. Love the education background - keep up the good work and output!
Very cool. I had to code a Cells app in Java back in university, too.<p>One thing though: add undo/redo to the Cell task as a requirement. After all, "a good paradigm should give you this functionality for free" :)
Imagine if a GUI programming benchmark had GUI specifications with reasonable UX? The 7GUIs designs are criminally bad, especially CRUD and Circle drawer.
The Cells example doesn't seem to work properly on my Mac in Safari:<p><a href="https://7guis.bradwoods.io/cells/" rel="nofollow">https://7guis.bradwoods.io/cells/</a>
Fun Fact: 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999°C = 32.00°F