Hacker News Reader

Comment by ericsilly | Hacker News Reader

I’ve been working on an SPA built with no frameworks, a lot of WebComponents, and almost zero 3rd party code, and it’s fantastic. Package managers and frameworks have a lot of holdover momentum from an era when they were far more necessary, and I think a lot of teams and individuals have unacknowledged PTSD that prevents them from stripping out these legacy comfort & safety nets. Plus, it’s likely also a comfort for managers to believe a team is working within some sort of opinionated 3rd party-supplied guardrails.

View on HN

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?

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.

>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

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?

here are a few resources: video survey with a lot of nuance, especially relative to React: https://youtu.be/9FB0GSOAESo?list=PLNM_ABHoF7B0qDu0GI09eCXim...

https://developers.google.com/web/fundamentals/web-component...

https://developer.mozilla.org/en-US/docs/Web/Web_Components

https://lit.dev/docs/#next-steps https://lit.dev/docs/composition/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

The biggest crimes of web frameworks is they take you away into abstraction land away from the actual standards and they complexify simplicity, all of that under the guise of being more "standard" and more "simple". It is one of the greatest lies ever sold.

I remember how .NET WebForms and lots of Java boilerplate frameworks did that early on, or browsers breaking standards, they wanted developer lock-in just like web frameworks of today. They wanted to keep developers dumb by being "simple" as long as you stay in their walled garden where they handle the standards. No thanks...

I have been developing javascript for decades and I actually liked the original less Java like boilerplate of the previous iterations, and you can still do that. The people that push frameworks aren't always trying to make things more simple, they want control, lock-in and domain ownership. The last tool to really simplify in javascript was jquery and most of that is browser level now including selection the killer feature of jquery across all those document.all/document.layer days of pain. Those days are over, simplicity is being complexified now.

Tools like jquery and even Flash or other plugins were platform pushers that got the web to the place we have now which is better than ever for web standards, yet we have all these bloated frameworks on top now. In a way it is a bit like the xkcd comic with so many standards, just to not do javascript people built thousands of frameworks on top to "simplify" the standards that are simple now.

While web frameworks may have been needed for a time, and in certain team based scenarios, they are a crutch, a maintenance problem long term, they take actual standards out of experience and the worst is they make the simple complex. Web frameworks have become the DLL hell or dependency deepend that used to be used to attack other platforms. .NET and Java have less bloat now and are moving more standard, while javascript web frameworks only pretend to.

The web standards of today are amazing and take away the nee for frameworks today: from templating to html templates [1], vanilla javascript with classes [2] and async [3] and better api access like fetch [4] and browser support for vdom with shadow dom [5], components with WebComponents [6][7], css now with lots of additions like variables [8] transitions[9]/animations[10], flex and media queries, canvas/svg/etc for interactivity, and so much more. There is little need to use frameworks except to sell books and conferences and keep developers locked in.

As developers/engineers, the job is taking complexity and simplifying, ask yourself if your framework abstraction is doing that above actual standards that is a pain long term to maintain. Web frameworks were supposed to work together, they are now behemoth monoliths that limit dynamic and fluid systems that scripting are supposed to bring. People went out and made a scripting language for glue into Java boilerplate...

In areas like targeting a certain javascript ECMA version or polyfills, those are still worthy, the other pile of verbose bloat abstraction that is there is just that, a pile of "verbloat". "Verbloat" is a new word to define frameworks of today sold in as small helpers to replace jquery, that have grown to the size of dev lock-in tar pits. No developer in their right mind would use this for products/projects they control unless they have to at this point.

Basically this video summarizes the absolute unnecessary adventure of web frameworks and provides some comic relief to the absurdity of it all. [11]

[1] https://caniuse.com/template

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[4] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

[5] https://caniuse.com/shadowdomv1

[6] https://caniuse.com/custom-elementsv1

[7] https://developer.mozilla.org/en-US/docs/Web/Web_Components

[8] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...

[9] https://developer.mozilla.org/en-US/docs/Web/CSS/transition

[10] https://developer.mozilla.org/en-US/docs/Web/CSS/animation

[11] https://www.youtube.com/watch?v=Uo3cL4nrGOk

I wish this comment was pinned to the top of every Javascript discussion thread!

Great write up!

Reply on news.ycombinator.com