3 ms·

How did you go about establishing structure and patterns that are typically enforced by frameworks? Was Web Components a big piece of that or were there also ot

How did you go about establishing structure and patterns that are typically enforced by frameworks? Was Web Components a big piece of that or were there also other major patterns you incorporated?

ericsilly 5y ago
Great question. WC doesn’t provide any architectural structure beyond code encapsulation for your UI widgets. But this alone gets you per-feature sandboxing, even more strictly if you use the shadowdom to get runtime isolation as well (I typically don’t, but it’s a good fit for many solutions). This allows you to move ahead pretty quickly, knowing you can tear out and replace these elements easily if you got it wrong or the needs change, without core changes to the app. Yes, you still need foundational services like data access & caching, personalization, etc, which sit outside of WC, but the “best way” for those things is typically very tied to what you’re trying to build. So for those, I typically just start with a functional “sketch” of each service with a lot of code separation, and let the architecture emerge through iterations of refactoring as I start to understand what I need. The biggest refactor problems tend to have to do with precedence of rules and order of code execution, with the biggest issues at initial load as arrival scenarios get more complicated. But no framework is going to solve those problems optimally for your app, and more likely, the frameworks create more obstacles to doing it well. And then there’s always the problem that your devs need to be really knowledgeable in the framework to not apply it badly.
tmh88j 5y ago
>How did you go about establishing structure and patterns that are typically enforced by frameworks? I know PHP gets a lot of flak, but I think this is an excellent example of how that can be accomplished from a backend perspective using proven libraries. https://github.com/PatrickLouys/no-framework-tutorial https://github.com/PatrickLouys/no-framework-tutorial
- jonwinstanley 5y ago
  In the example, the developer uses a library for most of the main features e.g. flip/whoops and FastRoute. By pulling together these libraries, in effect, they have created their own framework have they not?
jimmont 5y ago
here are a few resources: video survey with a lot of nuance, especially relative to React: https://youtu.be/9FB0GSOAESo?list=PLNM_ABHoF7B0qDu0GI09eCXimoL2AyMMq https://youtu.be/9FB0GSOAESo?list=PLNM_ABHoF7B0qDu0GI09eCXim... https://developers.google.com/web/fundamentals/web-components/best-practices https://developers.google.com/web/fundamentals/web-component... https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components https://lit.dev/docs/#next-steps https://lit.dev/docs/#next-steps https://lit.dev/docs/composition/overview/ https://lit.dev/docs/composition/overview/ https://lit.dev/docs/components/overview/ https://lit.dev/docs/components/overview/ generally I do this: * make components that take responsibility for a bucket of concerns: like the app (track the app state--user, etc); then views (generic pages, more complex main-section things, etc); then more granular composable stuff like a highly specialized button (arbitrary example); * communicate state changes up via events, for global or highly generalized coordination between anything just handle that on the window/self (setup/undo on the component lifecycle methods); send/intercept/capture these messages on the event.detail (use composition and bubbling); * stick to first-principles: KISS, YAGNI; don't over-engineer your stuff, use encapsulation, if you don't need a shadowRoot it's not required, or use slotting..., use global styles where that's appropriate, use shadow encapsulation of styles where that's separately appropriate--keep those concerns separate and use common sense about appropriate separation of concerns; * don't automate or use external libraries or anything fancy unless it has a clear self-apparent business case (for my work or the customer or the business); forget all the assumptions of the frontend community--it's mostly noise an example, it's very rough and I'm working through a starting point for myself: https://github.com/sourdough/starter https://github.com/sourdough/starter

How did you go about establishing structure and patterns that are typically enforced by frameworks? Was Web Components a big piece of that or were there also other major patterns you incorporated?

ericsilly 5y ago

Great question. WC doesn’t provide any architectural structure beyond code encapsulation for your UI widgets. But this alone gets you per-feature sandboxing, even more strictly if you use the shadowdom to get runtime isolation as well (I typically don’t, but it’s a good fit for many solutions). This allows you to move ahead pretty quickly, knowing you can tear out and replace these elements easily if you got it wrong or the needs change, without core changes to the app. Yes, you still need foundational services like data access & caching, personalization, etc, which sit outside of WC, but the “best way” for those things is typically very tied to what you’re trying to build. So for those, I typically just start with a functional “sketch” of each service with a lot of code separation, and let the architecture emerge through iterations of refactoring as I start to understand what I need. The biggest refactor problems tend to have to do with precedence of rules and order of code execution, with the biggest issues at initial load as arrival scenarios get more complicated. But no framework is going to solve those problems optimally for your app, and more likely, the frameworks create more obstacles to doing it well. And then there’s always the problem that your devs need to be really knowledgeable in the framework to not apply it badly.

tmh88j 5y ago

>How did you go about establishing structure and patterns that are typically enforced by frameworks? I know PHP gets a lot of flak, but I think this is an excellent example of how that can be accomplished from a backend perspective using proven libraries. https://github.com/PatrickLouys/no-framework-tutorial https://github.com/PatrickLouys/no-framework-tutorial

jonwinstanley 5y ago
In the example, the developer uses a library for most of the main features e.g. flip/whoops and FastRoute. By pulling together these libraries, in effect, they have created their own framework have they not?

jimmont 5y ago

here are a few resources: video survey with a lot of nuance, especially relative to React: https://youtu.be/9FB0GSOAESo?list=PLNM_ABHoF7B0qDu0GI09eCXimoL2AyMMq https://youtu.be/9FB0GSOAESo?list=PLNM_ABHoF7B0qDu0GI09eCXim... https://developers.google.com/web/fundamentals/web-components/best-practices https://developers.google.com/web/fundamentals/web-component... https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components https://lit.dev/docs/#next-steps https://lit.dev/docs/#next-steps https://lit.dev/docs/composition/overview/ https://lit.dev/docs/composition/overview/ https://lit.dev/docs/components/overview/ https://lit.dev/docs/components/overview/ generally I do this: * make components that take responsibility for a bucket of concerns: like the app (track the app state--user, etc); then views (generic pages, more complex main-section things, etc); then more granular composable stuff like a highly specialized button (arbitrary example); * communicate state changes up via events, for global or highly generalized coordination between anything just handle that on the window/self (setup/undo on the component lifecycle methods); send/intercept/capture these messages on the event.detail (use composition and bubbling); * stick to first-principles: KISS, YAGNI; don't over-engineer your stuff, use encapsulation, if you don't need a shadowRoot it's not required, or use slotting..., use global styles where that's appropriate, use shadow encapsulation of styles where that's separately appropriate--keep those concerns separate and use common sense about appropriate separation of concerns; * don't automate or use external libraries or anything fancy unless it has a clear self-apparent business case (for my work or the customer or the business); forget all the assumptions of the frontend community--it's mostly noise an example, it's very rough and I'm working through a starting point for myself: https://github.com/sourdough/starter https://github.com/sourdough/starter