diff --git a/README.md b/README.md index ce16ec4..e262f93 100644 --- a/README.md +++ b/README.md @@ -74,7 +74,8 @@ We're missing thorough examples of complex web applications built only with standard web technologies, covering as many aspects of the development process as possible. -This case study is an attempt to fill this gap, at least a little bit. +This case study is an attempt to fill this gap, at least a little bit, +and inspire further research in the area. ## 2. Method @@ -347,7 +348,7 @@ and may instead only set event listeners to enable some behavior. Also note that an element can be mounted with multiple mount functions. For example, to-do items are mounted with `VT.TodoItem` and `VT.AppDraggable`. -Compared to React components, mount functions provide superior flexibility as +Compared to React components, mount functions provide interesting flexibility as components and behaviors can be implemented using the same idiom. Reference: @@ -366,14 +367,14 @@ I found it effective to implement one-way data flow similar to React's approach. usually resulting in some parent component state change which is in turn propagated downwards through `update` functions. -The data store is factored into a separate mount function (`VT.TodoStore`). -It only receives and dispatches events, and encapsulates any data manipulation. +The data store is factored into a separate behavior (`VT.TodoStore`). +It only receives and dispatches events, and encapsulates all of the data logic. Listening to and dispatching events is slightly verbose with standard APIs and certainly justifies introducing helpers. I didn't need event delegation à la jQuery for this study but I believe it's a useful concept that is difficult to do -properly with standard APIs. +concisely with standard APIs. Reference: @@ -487,7 +488,7 @@ VT.TodoList = function (el) { ``` It's very verbose and has lots of opportunity to introduce bugs. -Compared with a simple loop in JSX, this seems insane. +Compared to a simple loop in JSX, this seems insane. It is quite performant as it does minimal work but is otherwise messy; definitely a candidate for a utility function or library. @@ -608,7 +609,7 @@ and some opinionated statements based on my experience in the industry. - Standard DOM APIs - Very few concepts introduced: - Mount functions (loosely mapped by CSS class names) - - State separate from DOM + - State separated from the DOM - Idempotent updates - Data flow using custom events - Compare the proposed architecture to the API/conceptual surface of Angular or React... @@ -663,8 +664,10 @@ would reduce the comparably low code size (see above) even further. - No type safety. I've always been a proponent of dynamic languages but since TypeScripts' type system provides the best of both worlds, I cannot recommend using it enough. +- We're effectively locked out of using NPM dependencies that don't provide + browser builds as we cannot use CommonJS or ES6 modules. - Most frameworks handle a lot of browser inconsistencies **for free** and - continuously test for regressions with extensive test suites. + continuously monitor regressions with extensive test suites. The cost of browser testing is surely a lot higher when using a vanilla approach. @@ -695,8 +698,8 @@ after all: The result of this study is a working todo application with decent UI/UX and most of the functionality of the original TeuxDeux app, built using only standard web technologies. -Some extra features were introduced to demonstrate the implementation of -cross-cutting concerns in the study's codebase. +It comes with better overall performance +at a fraction of the code size and bandwidth. The codebase seems manageable through a handful of simple concepts, although it is quite verbose and even messy in some areas. @@ -705,15 +708,19 @@ simple build steps (e.g. SCSS and TypeScript). The study's method helped discovering patterns and techniques that are at least on par with a framework-based approach for the given subject, -without diverging into building a custom framework. except for +without diverging into building a custom framework—except for rendering variable numbers of elements efficiently. Further research is needed in this area, but for now this appears to be a valid candidate for a (possibly external) general-purpose utility. -When looking at the downsides, remember that all of the individual parts are +When looking at the downsides remember that all of the individual parts are self-contained, highly decoupled, portable, and congruent to the web platform. The resulting implementation cannot "rust", by definition. +Another thought be taken with a grain of salt: I believe frameworks +make simple tasks even simpler but hard tasks (e.g. implementing cross-cutting +concerns or performance optimizations) often more difficult. + --- Setting some constraints up-front forced me to challenge @@ -726,8 +733,8 @@ the study would likely be more convincing if build steps were allowed. Modern JavaScript and SCSS could reduce most of the unnecessarily verbose parts to a minimum. -Finally, this case study does not question -using dependencies or frameworks in general. +Finally, this case study does not question using dependencies or frameworks +in general—they do provide lots of value in many areas. It was a constrained experiment designed to discover novel methods for vanilla web development and, hopefully, inspire innovation and further research in the area. @@ -752,9 +759,9 @@ Here are a few ideas I'd like to see explored in the future: General resources I've used extensively: -- [MDN Web Docs](https://developer.mozilla.org) -- [Can I use...](https://caniuse.com) -- [React](https://reactjs.org) +- [MDN Web Docs](https://developer.mozilla.org) as a reference for DOM APIs +- [Can I use...](https://caniuse.com) as a reference for browser support +- [React](https://reactjs.org) as inspiration for the architecture Useful articles regarding FLIP animations: