Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

Post reply on HN
Print view View original

61–70 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#61

Post by djrenren »

dbingham wrote: post #6

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…

As someone who just had to answer this for my startup, the value of React is that it's robust and immensely hire-able. If you're looking for frontend developers, the one thing you can always expect is at least passable React knowledge.

Everything else, even if it has a better technical fit for your project, is likely riskier for your organization.

Re: Web Components Eliminate JavaScript Framework Lock-In

#62

Post by nostrademons »

wayfinder wrote: post #14
dbingham wrote: post #6

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…

As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do t…

I liked the templates-as-JSON approach much more than JSX. HTML is terribly verbose, doesn't fit well with the rest of Javascript, doesn't let you use JS language features like destructuring or iteration on the component tree, and doesn't let you factor out common properties into their own data structure. Would much rather see:

    { tag: 'div', padding: '2px', position: 'absolute', content: [myText] }
than

    ${myText}
The main reason I ended up settling for JSX was just convention: I don't want to be the one with my own unique format for UI trees unless I can convince everybody else to use my format.

Note that Jetpack Compose has a very similar declarative reactive paradigm as React, but represents components with Kotlin language mechanisms. IMHO I like it much better, because it's much more composeable.

Re: Web Components Eliminate JavaScript Framework Lock-In

#63

Post by marcosdumay »

breadwinner wrote: post #44
menssen wrote: post #39

Earlier quoted context omitted.

"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the applic…

> It is about enabling a design pattern where the user interface is a pure functional transformation of the application state. This is only true for read-only components. There is no "pure functional" when you introduce state and interactivity. See here: https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

The idea of a reactive framework is that every interface component is either an event creator with no representation and that can update your application state, or an state viewer that has no inputs but can represent your state.

It's decoupling those two that brings all the power.

But the idea doesn't represent at all the web. So react is a mess of complex code trying to make the things you can create on the web behave like stateless pure components. Yet, it mostly works, and the react does indeed implement the idea that the interface is a pure functional transformation of the application state. (But I do disagree on claiming this the "entire idea", it's half of it at most.)

Re: Web Components Eliminate JavaScript Framework Lock-In

#64

Post by jitl »

breadwinner wrote: post #51
menssen wrote: post #39

Earlier quoted context omitted.

"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the applic…

> Make a convincing argument that a different design pattern is better. Simple Model-View-Controller pattern works well for JavaScript, just as it does for ASP.NET Core, JSP and JSF, Ruby on Rails, Django and so on. Want proof? Browse this code: https://github.com/wisercoder/eureka/tree/master/webapp/Clie... This is the application: https://github.com/wisercoder/eureka

The server side style of MVC you describe is a far stretch from how MVC is practiced in retained-mode UI frameworks like UIKit, Cocoa, or Backbone. It’s possible to make this style work fine with careful design and planning; Apple built web versions of Pages and Keynote using SproutCore (which evolved into Ember?) in 2013-era.

In fact back then, everyone’s big app was MVC - usually Backbone. I worked on Airbnb’s host-side web app called “Manage Listing”, it had probably 30+ models, 150+ views, 100+ controllers in Backbone. There were many bugs in this scale of app around making sure the DOM reflected the latest change to some model. the engineering team regarded the more complicated screens as a nightmare to maintain in our fast paced environment with many teams touching the code.

Engineers at Airbnb started to adopt React as a solution to the problems we all experienced with MVC - not because it was a “hot new thing”. When React came out, it was widely regarded as weird - it was more like “eww, this smells of PHP and needs a weird compiler, but pure function of state is a lot better than fiddling DOM manually…”. Eventually we replaced Manage Listing backbone views with React components one by one until there was no backbone left.

React is still kinda weird but it does solve this problem the best out of the modern frameworks. It’s happy to over-render by default and prefers a correct DOM-for-state over everything else. It’s clear thought that the mental models popularized by React are worth it - now Apple and Google are switching to the React model in their own frameworks.

Re: Web Components Eliminate JavaScript Framework Lock-In

#65

Post by tshaddox »

menssen wrote: post #39
dbingham wrote: post #6

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…

"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the applic…

I too remember building interactive web sites with jQuery. It was never fun creating, for instance, an interactive list view where each item can be modified in client state and new items can be added. This was the problem for which React provided a major "Aha!" moment.

Re: Web Components Eliminate JavaScript Framework Lock-In

#66

Post by dexwiz »

menssen wrote: post #52
breadwinner wrote: post #44

Earlier quoted context omitted.

> It is about enabling a design pattern where the user interface is a pure functional transformation of the application state. This is only true for read-only components. There is no "pure functional" when you introduce state and interactivity. See here: https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

It is possible with React to write an application where components have no internal state, every component is "read only," and all UI changes are state transitions in (something like) a redux store. This is rarely done, because there are pragmatic reasons (e.g., animations) not to, but it is possible. The other mistake alternatives make is to try to make components having internal state "easier." It should not be eas…

If one of the most popular APIs is a violation, then maybe the pattern is broken.

Re: Web Components Eliminate JavaScript Framework Lock-In

#67

Post by nostrademons »

wayfinder wrote: post #40
zelphirkalt wrote: post #34

Earlier quoted context omitted.

Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is because it still encourages people to put JS in their HTML in their JS in their ... And we are almost back to crazy PHP land of "I treat HTML as a string and blend everything together into one big lump.", instead of using a templating engine, that treats HTML in…

Your criticism was the biggest one of React when it came out -- mixing view code with your controller code. Big no no. Everyone loved the MVC pattern (model-viewer-controller where you separate these things in different places) and what React did was a big no no. But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. In other lan…

> But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no.

It's not actually, with HTTP/2. The separate requests are all multiplexed over the same connection, often with prefetching, and compressed together so that there's little to no overhead vs. putting them in the same file.

This illustrates a common failure point for web frameworks though. They encode a lot of folk knowledge about how the web works, but that folk knowledge becomes obsolete as browsers change.

Another prominent React example fits into this category: the virtual DOM. React assumed that DOM manipulations were slow and Javascript manipulations were fast, and so they built up an internal representation of the DOM in Javascript so they could manipulate that one and diff the change to apply it to the real DOM. This was true from approximately 2008 (when V8 introduced JS JITting) to 2013 (when Blink/Webkit/Firefox all moved to a dirty-bit system for DOM manipulations), which not coincidentally is when React was designed. But since then, DOM manipulation has been just pointer swaps and a dirty bit flip, and if you're careful not to invoke any operation that triggers a reflow and repaint you can make your modifications directly in the DOM for roughly the same cost as making them in JS. Since React is declarative it could easily have enforced the no-reflow rules without the virtual DOM, but because DOM manipulations were expensive when its designers learned web programming, it introduces an unnecessary concept.

Re: Web Components Eliminate JavaScript Framework Lock-In

#68

Post by marcosdumay »

wayfinder wrote: post #14
dbingham wrote: post #6

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…

As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do t…

> template

It's new and has no significance for the history. But I think it's relevant to point out that isn't horrible.

And that those articles about web components are doing a really bad job of using constant strings instead of this.shaddow.innerHTML = getElementById("myhtml").innerHTML.

Re: Web Components Eliminate JavaScript Framework Lock-In

#69

Post by switchbak »

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff.

I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore.

For some reason I thought we'd have made it beyond that by 2023, and we could talk declaratively at a high level about the kinds of interfaces we want to render and where the data lives. Hopefully I'm wrong and the magic is buried under some Elm tree or a React library or something.

Something something get off my lawn...

Re: Web Components Eliminate JavaScript Framework Lock-In

#70

Post by davetron5000 »

Web Components are not a replacement for React. They are a thing you would use to build React if you were to do so today. To use only Web Components, you will be writing a lot of low-level code using the browser's API, or you will have to use a framework built on Web Components
Post reply on HN