8 ms·

I tried to understand the referenced article "Web Components Are Not the Future" - but found that there weren't many convincing arguments. The current state of

by jeswin 2y ago

I tried to understand the referenced article "Web Components Are Not the Future" - but found that there weren't many convincing arguments. The current state of Front-end frameworks is an absolute mess. Speaking for myself, I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al). Magic in frameworks is often a hack, unlike magic in libraries. The first library I used was Prototype. It felt like magic, and it truly was. And so was jQuery, and Backbone. I never had to guess what "useState" does behind the scenes. There are many things which don't carry over into Web Components from current JS frameworks. But if you start from Web Components (ignoring everything you know about frameworks), it suddenly becomes intuitive. And it brings in abilities which are missing otherwise, such as isolation via Shadow DOM. It grows on you. In my view the only thing we should retain from the React era is JSX (for many reasons, true type-safety, autocomplete etc). I wrote a library last week for using Web Components with JSX. No magic other than JSX. https://webjsx.org https://webjsx.org

wslh 2y ago
> I don't want to learn a complex framework. Completely agree. As a casual programmer, I just want something simple, inspired in VB6.
azangru 2y ago
> In my view the only thing we should retain from the React era is JSX How do you deal with the non-existing difference between attributes and properties in JSX? Is every attribute a property and vice versa? Do properties reflect back as attributes?
- nsonha 2y ago
  jsx is just a syntax to construct elements with attributes. You can still add properties like you do in a web component. In React you mostly never deal with instances (and properties) but that doesn't mean other ways to model components utilizing jsx cannot.
  - azangru 2y ago
    Jsx uses properties, not attributes, while pretending that it uses attributes. Html attributes are strings, whereas jsx allows you to pass different data types to child components. Thus, properties. Which is also why is uses camel-cased names, or insists on className. Because these are the names of HTMLElement's properties.
    - nsonha 2y ago
      that's React's implementation, we are talking what it would be if not React. IMO the semantic is similar to attribute, example: let element = <my-thing my-attribute={value} /> element.property = prop
    - WorldMaker 2y ago
      Those are React optimizations/restrictions, not JSX restrictions. They want to make diff/patch as fast/simple as possible and rely on properties to do that as much as possible. `className` might have been a restriction in early JSX parsers trying to avoid keyword clashes, but every current JSX parser (especially Typescript) has no problems with JS keywords embedded in JSX. (I don't think it actually was a restriction at any point, but early JSX parsers might have been conservative in how they wanted to parse given the fate of E4X.) Snabbdom [1] takes an approach of explicitly separating `props` and `attrs` at the expense of extra verbosity in the JSX `<span props={{ className: 'example' }} attrs={{ 'aria-label': 'Example'>Example</span>`. My Butterfloat [2] uses simple heuristics, starting with the props because you can conditionally type a ton of JS type data (and MDN link comments) out of TS DOM types for a strong autocomplete experience, adding common important-to-HTML copy/paste shortcuts such as `class` and `for` and switching to attributes if an XML namespace seems to be in use or the name includes a `-` and seems to be qebab-cased rather than camel-cased. [1] https://github.com/snabbdom/snabbdom?tab=readme-ov-file#jsx https://github.com/snabbdom/snabbdom?tab=readme-ov-file#jsx [2] https://worldmaker.net/butterfloat/ https://worldmaker.net/butterfloat/
    - rschristian 2y ago
      Every JSX implementation uses a mix of setting props & attributes, depending on the specific label, as the DOM can be a bit weird with how some things reflect. Generally properties are preferable to attributes, however.
- edwinjm 2y ago
  In Lit, a web component framework, you can set properties with, for example, href=... and you can set attributes with .href=... This can be taken over to JSX.
  - azangru 2y ago
    > In Lit, a web component framework, you can set properties with, for example, href=... and you can set attributes with .href=... Only it's the other way around.
coffeefirst 2y ago
Yeah. I know React quite well, there are legitimate use cases where it shines, but... What we've lost is the ability to say "let's make a website today" and just start making UI without build tools or crazy install trees or massive libraries that need maintenance and security updates, and drop it on a server somewhere. I keep thinking I can have that back... ES6 imports are fully supported now, modern CSS is amazing, all we really need is an SSR/a11y-friendly way to do some kind of nestable HTML macro/component, and we can party like it's 2007 (but with grid, and import statements, and all the other new shiny objects).
- lolinder 2y ago
  As I'm thinking about this, the main thing that is left before I could imagine a build-free website/webapp is TypeScript support in the browser. Even just esbuild-style stripping of types would be enough, but I can't imagine bringing myself to write even a small amount of JavaScript without types any more. Even without that, a tiny system that just depends on tsc should be within reach at this point.
  - evilduck 2y ago
    I wouldn’t personally make these tradeoffs but for the sake of argument if you're willing to write substantially more type info into JSDocs (AI tooling may alleviate this nowadays) you can retain most of the coverage and assurances without using anything Typescript adds to the syntax superset while still using it for type checking during development. Even without the type-heavy JSDocs you might be able to alter your coding style to lean into easing and increasing inference (more classes instead of types or interfaces) and get pretty far. Honestly though, I just never really run into use cases where I need to "make a page in a day" and where modern tooling gets in the way. I'm comfortable with create-react-app, NextJS, Gatsby, and a couple other things, I can definitely put a new static asset project from one of those on a VPS by shuffling files over scp in the timespan it takes to make a pot of coffee, and I would strongly prefer having those tools than trying to be "pure" for hand-wavy reasons and unproven benefit.
- codethief 2y ago
  > and we can party You go party but for a large team (or group of teams) I will still prefer the explicitness of data flow and the type safety that Angular/React/Vue/… give me.
jrochkind1 2y ago
You implied but didn't say explicitly, are you doing your front-end development with web components now personally?
- jeswin 2y ago
  Yes.
rty32 2y ago
One aspect of this is how you think about UI. The underlying pattern of jQuery is fully side-effects -- you select an element and make some changes to it. Frameworks like React and Vue.js allows to create UI components whose states are completely determined by data, i.e. what the UI looks like is the value of a pure function, mathematically speaking. It also updates the UI with minimum DOM changes when the data changes. (Although you don't have to make them pure, and arguably you can achieve the same thing with jQuery.) Depending on where you are, it makes UI widgets much more readable and maintainable. These frameworks are innovative in terms of state management compared to "old approaches" (of course, with additional benefits like reusability etc) Bear in mind that today's websites and web based desktop applications are much, much more complicated than two decades ago, and has a much higher requirement for scalability and maintainability. If you just want to create simple UI, indeed they may not be your best choice.
InsideOutSanta 2y ago
I'm building my most recent project with web components + htmx, and it's mind-blowing how much better all of this feels to me than the typical React/Angular stack. I think there's a place for React and Angular and technologies like them, but 90% of the projects that currently use them would be better off with a much simpler stack.
- DimmieMan 2y ago
  I have a growing belief the advantage the advantage you're seeing is more HTML first *culture* rather than HTMX itself, I feel the same way using SvelteKit. For example, you submit a form with a couple extra tags on a stock HTML form, do some processing server side and swap out the form (or redirect or whatever). No overriding the on submit callback, no having to wire up a validation hook, no having to think about where things are running. React and angular have a very "let's solve this in JS" culture that creates ultimately unnecessary complexity demons for that 90%.
  - LegionMammal978 2y ago
    On the other hand, I've recently been helping someone out with their messy SvelteKit website, and I've personally found the framework horrible to learn. The routing and rendering logic is all diced up between +layout.ts, +layout.svelte, +page.svelte, another +page.svelte, and a few other .ts and .svelte files scattered around lib/, to the point where I can hardly understand what data is going where, and which parts are rerendered when that data is modified. Also, prerendering has bitten me with odd discrepancies between localhost and production. While this messy project likely isn't the best showcase of SvelteKit, I just haven't experienced its alleged simplicity: there are too many files with special roles, and too much magic transforming things behind the scenes. I'd take React over this any day, where the components form a simple tree, and the dependencies are (often painfully) explicit instead of being swept under the rug.
    - DimmieMan 2y ago
      You know I almost didn't mention svelte in passing to ward off this type of comment... Replace svelte and react with any framework and you can a thousand arguments of the same damn format and probably a couple in this thread, It was tangental to the point. One possible advantage of something like HTMX + web components I guess is splitting things into a million files all over the place that can fetch data and manage their own state is painful which seems to be how most svelte/react/whatever disasters are made. There's plenty of ways to make a HTMX disaster but the culture and methodologies being pushed are all leading towards simple, HTML first design which I believe might be the 'secret sauce' rather than the technology itself.
crabmusket 2y ago
> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al). I can't really parse this sentence. It seems to have a lot of ideas in it. Do you want to learn a framework at all, or have one that is so magical that it feels like it doesn't need to be learned? Do you want to read documentation or not? Do you think the problem with React is that its primitives are unsuited to the work you do in it? Or to the work anybody needs to do? I've spent most of my professional career in Vue, so I don't have a great perspective on the React ecosystem. But Vue feels like it must be included in your "complex framework" statement. I've definitely felt some pain from overuse of the framework, or poor understanding of various features, libraries, etc. The ecosystem around full-on SPAs is indeed complex. I'm just not sure what other systems would let me personally, and us broadly, manage a complex stateful client-side app. (This is entirely separate to overuse of SPAs for things that shouldn't be SPAs.)
- szundi 2y ago
  I think he was pretty clear that the "magic" in frameworks is not something you can easily understand, therefore have to guess how it really works. He doesn't like that.
  - jemmyw 2y ago
    You don't need to guess. You can actually read the code! Not saying that you should straight away when learning, but later, when you're familiar with your framework, I think reading through the codebase and understanding it is good practice.
    - cj 2y ago
      You can read the code, but it’s complex and convoluted. He referenced Backbone as a comparison point. If you compare Backbone’s source code to React’s source code, you’ll get what he means. Basically, libraries like Backbone are small and simple enough that you can literally read the source code and fully understand how it works. Compare that to React, where the source code is an order of magnitude larger and very difficult to fully grasp the inner workings. The simplicity and ability to easily understand the source code obviously comes with tradeoffs (e.g. with Backbone, to use it to build a reasonably complex app, you basically have to build your own framework on top of it, compared to React which has more abstractions and therefore is more plug and play.
jsyang00 2y ago
You do not need to know how `useState` works to understand how to use it to write a React application, it is fairly intuitive to understand how to apply the pattern. If I look at your library, it seems to me like it requires a much more complex mental model to begin to use. Of course, it is better in theory for a developer to thoroughly understand the details of their framework, but empirically, React has been very successful in allowing people to build relatively sophisticated applications while understanding very little of the underlying model.
- bakugo 2y ago
  You don't need to understand how useState works if you're writing a page with a button that increments a number when pressed, from a beginner's tutorial. As soon as you work on any remotely complex codebase, you will run into problems that require a decent mental model of the underlying "magic" to properly understand and solve. "Building sophisticated applications while understanding very little of the underlying model" is how you end up with gigantic piles of unmaintainable spaghetti code full of awful hacks, which seems to be the standard for React applications.
  - lolinder 2y ago
    Is this less true of Web Components? I've worked with a lot of different tech stacks over my career and every single one of them has required understanding the internals once you start using them seriously. I haven't found React to be substantially worse for that than any other tech stack I've used.
    - peebeebee 2y ago
      With webcomponents you are pretty close to the “metal”. If you know how to write good vanilla JavaScript, you can take most of that knowledge into webcomponents. You only need to learn the custom components lifecycle, and shadowDOM, which is knowledge about web-standards. With other frameworks you need to learn template syntaxing, how state propagates, how the compiler works, etc etc. Lot of that knowledge might be obsolete in 10 years. Which isn’t to say it can’t be worth it. Learning multiple frameworks and libraries is also very helpful to skill up because you are learning about different concepts and implementations.
sandreas 2y ago
Well, there is a project to convert react components to native ones[1]... this way you can write react and use it everywhere. I think this is the way to go, similar to svelte's approach. Write what you want but compile it to native standards. 1: https://github.com/bitovi/react-to-web-component https://github.com/bitovi/react-to-web-component
8n4vidtmkvmk 2y ago
In my admittedly little experience with shadow DOM, it doesn't isolate as much as it claims. CSS variables pierce the boundary, so if your styles are built around that, you can still run into trouble. I just haven't seen any benefit whatsoever once you have CSS modules. And CSS layers help too.
- peebeebee 2y ago
  ShadowDOM, and by extension web components are great for providing an extended set of HTML ‘native’ components. Let’s say your company has multiple frontend SPAs with different technologies (angular, react, svelte,…) they could all use the same set of company custom components, like a custom datepicker, or fancy selectbox.
  - epolanski 2y ago
    This is the promise, but my experience tells me that web components fall short of that goal.
- epolanski 2y ago
  This has been a major concern for me. We went for a web component because we needed the same functionality on different websites using different tools. Issue was that we authored the web component with tailwind and then deployed the web component on different websites, some having different versions of tailwind themselves. Even minor differences in hosts tailwind versions led to quite surprising results. What we did in the end is to write a tool that given the tailwind classes used in the webcomponent it would then rewrite the rules at the :root of the web component's own css. Another reason for unhappiness came from lack of isolation regarding the units that derive from the host's base font which forced us to work in pixels directly. All in all, while I understand some of the decisions that went into web components, I can't lie and say that I too have few reasons to not be fully on the web components train, they fall short of the promise of author once, use everywhere.
EMM_386 2y ago
> The current state of Front-end frameworks is an absolute mess. Speaking for myself, I don't want to learn a complex framework. It's really not that hard. I was able to pick up Angular to a level where I could create complex sites with it, or submit acceptable PRs that involved in, in week or so. Granted, I am an experienced developer (C# since beta, HTML/JS/CSS from the start) but it seemed to just make sense quickly. So when I was asked by a company to replace their aging, complex portal to manage critical infrastructure, I chose Angular for the front end. That was smooth sailing. It was stable, performant, looked good and everyone was happy. People often avoid it because it has a "steep learning curve" but that mainly seems to come from developers who came into the industry knowing only JavaScript and maybe a little React. If you are more experienced, you can pick it up right away. And it helps, a lot, to use such frameworks on large complex sites. For various reasons.
- jeswin 2y ago
  It's a libraries vs frameworks thing. Libraries are relatively safer. Frameworks in C# are slightly better (compared to those on JS), because there are blessed Frameworks and most people are using them. In the JS world, you can see very popular frameworks (with millions of downloads) get abandoned. Not saying that all is well in the .Net world; desktop frameworks are an example. But overall it's a bit different because one company more or less controls it.
- edwinjm 2y ago
  To be productive in Angular, you also have to know RxJS, which comes with twenty or so functions you have to become familiar with and with some peculiarities like hot and cold observables. So, no, Angular is not easy to learn.
blovescoffee 2y ago
How does your library deal with state management and data flow? What primitives does your library offer for optimization?
- wruza 2y ago
  How does a regular program deal with “state management” and “data flow”? We all just programmed things for decades when web guys pop out with this “state management” pseudo-problem and started to invent thousands of pseudo-solutions for it. And why do we need “optimization”? It’s a user interface, not an accounting software core. A user types a character, you update few divs content or way under a thousand of divs’ visibility. Which optimization does that need?
  - papichulo2023 2y ago
    Old way was storing data in sessions or hidden html inputs. Both way worse than modern alternatives. You kinda sound like you have no idea what you are talking about. Having to render thousands of elements is not uncommon.
  - blovescoffee 2y ago
    First "Web guys" is such a demeaning way about talking about real and serious engineers solving real and serious engineering problems. If you don't think frontend engineering solves serious problems, I don't think your opinions about it are serious. All real world programs are stateful. You need some tooling and/or conventions to handle that in a clean way. I recommend this blog post about React Query that talks about some challenges and solutions on the frontend for state management: https://ui.dev/why-react-query https://ui.dev/why-react-query You're questioning the importance of optimization on a website for hackers/tinkerers/engineers? You need optimization for page speed, SEO, animation, elegance, pushing the boundaries... edit to address: "Which optimization does that need?" Optimistic updates, debouncing, handling large responses, cache, etc. etc.
    - wruza 2y ago
      Can you recommend a blog post about “state management” in non-frontend? E.g. some server or maybe a desktop app like e.g. your backup manager. Because my whole premise is that the “problem” is self-imposed, which react is literally the part of. If you don't think frontend engineering solves serious problems, I don't think your opinions about it are serious. I don’t think “frontend” is at all serious, because I have developed user-facing systems since around 2000, and “frontend” (which we called gui controls back in the day) was never a biggest story, when it was worth telling at all. Mostly complex distributed accounting software with various integrations at all levels. I’m not afraid of appeals to serious engineers with serious problems, cause I am one of them and can question it freely. If I appear somewhat toxic, that simply reflects the toxic positivity about the absurd state of things in web dev. It is a collective delusion which suddenly disappears when people get forced out if it, by e.g. going htmx route. Not advocating for htmx specifically, it just happens to be a perfect litmus test. Same for php, people still use it outside of “frontend” bubble and don’t know that “managing” their “state” is a hard problem that requires tens of versions of the best framework of the month.
Narhem 2y ago
If you use web components enough you realize why tools like useState exists then you have to bring in another library like alpine to offer the functionality. The whole point of web components is the ability to offer class encapsulation within the browser without anything other than a file server. JSX has much nicer syntax but I’d rather not have to deal with the overhead of launching a node server. Makes developing time quicker when working with smaller codebases.
jaredklewis 2y ago
> I never had to guess what "useState" does behind the scenes. It's weird to me that React hooks are always dragged out in these arguments as some kind of bogeyman. If you understand the idea of a virtual DOM and a render loop, then it is only a tiny step from there to understand hooks. And you can understand all of these concepts in about 15 minutes: https://www.youtube.com/watch?v=1VVfMVQabx0 https://www.youtube.com/watch?v=1VVfMVQabx0 I just don't get all the hand wringing regarding frontend frameworks. I've been using React since 2014 and in 10 years, there has been exactly one big change to the framework: hooks. When they came out, I spent 15 minutes to understand them. It didn't kill me. And React has been undisputed king the frontend frameworks hill for at least 9 years, but people still act like it's some sort of ever-changing, confusing landscape of options. If you want boring, stable front-end development, choose a super popular, well documented tool like React. Or if you don't like frameworks, use vanilla JS. It's not a crisis.
- edwinjm 2y ago
  "This framework feels very natural to me" says person using the framework for ten years.
  - watwut 2y ago
    I came back to react around a year ago, hooks were completely new to me and pretty instantly understandable. They are just not difficult to comprehend or use.
- ForHackernews 2y ago
  > If you understand the idea of a virtual DOM and a render loop, then it is only a tiny step from there to understand hooks Once you understand the arcana of the magisterium, it becomes obvious why the encyclicals must be unitarian!
mock-possum 2y ago
Have you tried the Lit library? Using lithtml to write web components based on Lit Component is DREAMY imo, if you’re into web components. It really reminds me of using jquery’s helper methods for ajax - like why wasn’t it just this way by default all along.
meiraleal 2y ago
> In my view the only thing we should retain from the React era is JSX honestly lit-html is much better and based on existing browser APIs. We should make it part of the webcomponents spec! Which is a work in progress: https://github.com/WICG/webcomponents/issues/1069 https://github.com/WICG/webcomponents/issues/1069
- troupo 2y ago
  > lit-html is much better and based on existing browser APIs. Ah yes. A new framework with its own custom DSL, its own custom hook, sorry, "directive" rules, it's own incompatible flavor of SSR is definitely the way to go, and whould be a part of the standard unlike Polymer before it which was also touted as the bee's knees. > We should make it part of the webcomponents spec! Which is a work in progress: Whatever the outcome of that discussion, it won't be lit.
jdmg94 2y ago
I work with web components within a FAANG company, it was a huge mistake and everyone hates it. If your argument for web components is that they're "so intuitive you don't have to learn" then you're lying to yourself.
- cy_hauser 2y ago
  How about Lit? I'm just looking at frameworks, components, etc. I was thinking of Lit as simplified web components? Is that valid?
- rty32 2y ago
  The comment could be so much more helpful if it just casually mentioned what people hate web components about. Sigh.
deliriumchn 2y ago
> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al) I'm always suprised reading statements like that. No offence, but maybe you're in wrong career if you don't want to learn how most popular and important tools of today work... Not to mention that its so simple you can learn everything required to be efficient during lunch break
- lelanthran 2y ago
  > I'm always suprised reading statements like that. No offence, but maybe you're in wrong career if you don't want to learn how most popular and important tools of today work... Not to mention that its so simple you can learn everything required to be efficient during lunch break This is such a common comment that I am never surprised to see it pop up whenever the "front-end mess" discussion arises. No, you cannot learn React over a lunch break. You cannot learn Angular and Vue over a lunch break. I am skeptical that even you, personally, can learn just the footguns alone present in the hundreds of thousands of lines of code in a specific $FRAMEWORK over one lunch break, two lunch breaks or even a dozen lunch breaks. All those thousands of lines of code implement something, and I will wager a month of my income against a month of your income that you will not learn more than 3 or 4 concepts over a single lunch break, because they all have multiple concepts, multiple use-cases, multiple exceptions-to-the-general-rule and multiple footguns without even including the edge-cases they solve. You will spend several years of lunch breaks, unless you consider reading the wikipedia overview for each $FRAMEWORK to be "learning the $FRAMEWORK". Web components, OTOH, have less functionality than full-blow $FRAMEWORKS, but each can be individually learned over a lunch break, reused by non-JS-developers and is a knowledge base that is more or less future-proof.
  - watwut 2y ago
    React is particularly easy to learn tho, much easier then angular. What you definitely can not learn over lunch breakis whatever local developers created as a local ad-hoc framework. Those area always more time consuming to work with, because you have no internet, stack overflow or documentation to help you.
dangsux 2y ago
[dead]
kccqzy 2y ago
For the specific point about useState, I agree about it being too magical. These days when I do write frontend code I use Reagent in Clojurescript. (I use Clojurescript partly for other reasons like its elegant syntax that's better than JSX, and built-in immutable data structures.) Its implementation of (r/atom) is a whole lot more intuitive: you can even think of it as a mutable pointer where the dereferences are tracked. On the other hand useState just feels like a hack for people who really want to avoid writing both classes and closures, and it is a roundabout way of doing things that could have been done in a much more standard and familiar way.
qudat 2y ago
JSX is the worst part of react so I find that to be a pretty wild take.
- postalrat 2y ago
  You honestly can't think of anything worse than JSX? JSX bothers you more than all the ways useEffect gets used or the restrictions for hooks.
  - qudat 2y ago
    The use API is very simple; JSX is a bastardized version of html that is atrocious to read and write. Just imagine all the dev time spent dealing with jsx/tsx. From IDE support to babel, typescript, etc. it is a burden on the JS/Ts ecosystem and severely contributes to fatigue. Yes. JSX is extremely complex to support and it is absolutely the worst part of react.
    - postalrat 2y ago
      So what is the alternative that solves all these perceived problems?
- imtringued 2y ago
  Hyperscript was a mistake.
chmod775 2y ago
> I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al). Really now. Most devs who think to themselves "man I wonder how useState works internally" will arrive at the logical and correct answer within seconds. It's not complicated or magic. There are bare-bones implementations of react hooks (-ish) with a couple hundred lines of code. Implementing a basic "useState" and "runFunctionComponent" is easier than most third-semester CS assignments. If that's the bar for magic, I'm surrounded by 20th level Warlocks coming up with new Eldritch Invocations for fun over breakfast.
- zelphirkalt 2y ago
  Hundreds of lines of code?? That sounds like way too much complication for something like that, tbh.
  - chmod775 2y ago
    If you want to be at least sort-of react hooks compatible, there's a bunch of hooks you need to implement.
  - kaba0 2y ago
    Heh? My smallest hobby project that is not a POC but actually is finished and is doing something is like 1000 lines long. There are very few stuff you can do with less than 100 lines. (Just for completeness sake, Haskell and alia sometimes might get away with less lines, because they tend to be “wider”. Word-count is a better metric here)
- imtringued 2y ago
  >Most devs who think to themselves "man I wonder how useState works internally" will arrive at the logical and correct answer within seconds. The answer is shockingly dumb. To be fair, I checked the code years ago, but basically almost every hook calls useReducer internally and useReducer uses an array stored in a global variable that is set before your component code gets called and the order of the hook calls determines which hook gets what useReducer state. It's basically a giant kludge and the React developers and users pat themselves on the back how "functional" their components are, when in reality they are flinging global mutable state like crazy.
gspencley 2y ago
> In my view the only thing we should retain from the React era is JSX (for many reasons, true type-safety, autocomplete etc) Warning: opinion incoming. JSX is one of two reasons that I never liked React at all and wish it would go away. I've been developing "web applications" since the latter half of the 90s. I've worked with everything from an in-house built dynamic template language (very similar to what PHP did in the early days) developed in C++ and served using CGI in Apache, to developing with PHP to Java Spring MVC to Django to modern frontend frameworks including both React and Angular. JSX reminds me of what PHP was like in the 90s and early 00s. People adopted it widely because the barrier to entry was extremely low. We had all of these static HTML websites and "developers" could just go in and start adding control flow to those documents in order to add dynamic functionality. It was easy ... and it quickly turned into a complete mess so big that PHP ended up with a reputation as being a toy language that "serious programmers" wouldn't be caught dead touching. That reputation was a bit unfair but also kind of earned. With the rise of PHP's popularity, the PHP "community" itself came to realize that they had a decent turing-complete programming language that they were working with, but that this idea of mixing business logic within HTML documents was a massive anti-pattern. It's ironic that what began its journey as a template language eventually realized that the best thing for the language was to stop using it as a template language, and to adopt different template languages such as Smarty in order to promote a separation of concerns between view / presentation concerns and business logic. React was never created as a "framework." There are actual frameworks that are starting to come out that use React for its view layer, such as NextJS, but React itself is just a library that allows you to create custom components and then choose your adventure when it comes to what other libraries you want to mix and match. But because people reach for React to start throwing together dynamic frontends quickly, everything is compononent-first. So it actively encourages you to put business and integration concerns in what really ought to be your view / presentation "layer." And JSX magnifies that problem by just being JavaScript. So, again, it's PHP all over again. You've got a very powerful turing-complete programming language that you intersperse with your markup and you get messes. Even in the most well-written, concern-separated React projects I still see a lot of "ugliness" that comes through with JSX. I did mention that it was one of two reasons I'm not a fan of React, the other is that - again because it was only conceived of as a component / view library - there is no inbuilt view encapsulation / scoped styles. This problem is somewhat mitigated by CSS modules these days. But view encapsulation is something that I've always seen as Angular's killer feature - the ability to just style your tags directly and create component markup that is completely devoid of class="" attributes. Angular and VueJS actually trained me to hate 99% of class="" attributes and to think of them as a type of code smell... just because it is possible to create higher-level components that don't have any at all but still styling when needed.

by jeswin 2y ago

wslh 2y ago

> I don't want to learn a complex framework. Completely agree. As a casual programmer, I just want something simple, inspired in VB6.

azangru 2y ago

> In my view the only thing we should retain from the React era is JSX How do you deal with the non-existing difference between attributes and properties in JSX? Is every attribute a property and vice versa? Do properties reflect back as attributes?

nsonha 2y ago
jsx is just a syntax to construct elements with attributes. You can still add properties like you do in a web component. In React you mostly never deal with instances (and properties) but that doesn't mean other ways to model components utilizing jsx cannot.
- azangru 2y ago
  Jsx uses properties, not attributes, while pretending that it uses attributes. Html attributes are strings, whereas jsx allows you to pass different data types to child components. Thus, properties. Which is also why is uses camel-cased names, or insists on className. Because these are the names of HTMLElement's properties.
  - nsonha 2y ago
    that's React's implementation, we are talking what it would be if not React. IMO the semantic is similar to attribute, example: let element = <my-thing my-attribute={value} /> element.property = prop
  - WorldMaker 2y ago
    Those are React optimizations/restrictions, not JSX restrictions. They want to make diff/patch as fast/simple as possible and rely on properties to do that as much as possible. `className` might have been a restriction in early JSX parsers trying to avoid keyword clashes, but every current JSX parser (especially Typescript) has no problems with JS keywords embedded in JSX. (I don't think it actually was a restriction at any point, but early JSX parsers might have been conservative in how they wanted to parse given the fate of E4X.) Snabbdom [1] takes an approach of explicitly separating `props` and `attrs` at the expense of extra verbosity in the JSX `<span props={{ className: 'example' }} attrs={{ 'aria-label': 'Example'>Example</span>`. My Butterfloat [2] uses simple heuristics, starting with the props because you can conditionally type a ton of JS type data (and MDN link comments) out of TS DOM types for a strong autocomplete experience, adding common important-to-HTML copy/paste shortcuts such as `class` and `for` and switching to attributes if an XML namespace seems to be in use or the name includes a `-` and seems to be qebab-cased rather than camel-cased. [1] https://github.com/snabbdom/snabbdom?tab=readme-ov-file#jsx https://github.com/snabbdom/snabbdom?tab=readme-ov-file#jsx [2] https://worldmaker.net/butterfloat/ https://worldmaker.net/butterfloat/
  - rschristian 2y ago
    Every JSX implementation uses a mix of setting props & attributes, depending on the specific label, as the DOM can be a bit weird with how some things reflect. Generally properties are preferable to attributes, however.
edwinjm 2y ago
In Lit, a web component framework, you can set properties with, for example, href=... and you can set attributes with .href=... This can be taken over to JSX.
- azangru 2y ago
  > In Lit, a web component framework, you can set properties with, for example, href=... and you can set attributes with .href=... Only it's the other way around.

coffeefirst 2y ago

Yeah. I know React quite well, there are legitimate use cases where it shines, but... What we've lost is the ability to say "let's make a website today" and just start making UI without build tools or crazy install trees or massive libraries that need maintenance and security updates, and drop it on a server somewhere. I keep thinking I can have that back... ES6 imports are fully supported now, modern CSS is amazing, all we really need is an SSR/a11y-friendly way to do some kind of nestable HTML macro/component, and we can party like it's 2007 (but with grid, and import statements, and all the other new shiny objects).

lolinder 2y ago
As I'm thinking about this, the main thing that is left before I could imagine a build-free website/webapp is TypeScript support in the browser. Even just esbuild-style stripping of types would be enough, but I can't imagine bringing myself to write even a small amount of JavaScript without types any more. Even without that, a tiny system that just depends on tsc should be within reach at this point.
- evilduck 2y ago
  I wouldn’t personally make these tradeoffs but for the sake of argument if you're willing to write substantially more type info into JSDocs (AI tooling may alleviate this nowadays) you can retain most of the coverage and assurances without using anything Typescript adds to the syntax superset while still using it for type checking during development. Even without the type-heavy JSDocs you might be able to alter your coding style to lean into easing and increasing inference (more classes instead of types or interfaces) and get pretty far. Honestly though, I just never really run into use cases where I need to "make a page in a day" and where modern tooling gets in the way. I'm comfortable with create-react-app, NextJS, Gatsby, and a couple other things, I can definitely put a new static asset project from one of those on a VPS by shuffling files over scp in the timespan it takes to make a pot of coffee, and I would strongly prefer having those tools than trying to be "pure" for hand-wavy reasons and unproven benefit.
codethief 2y ago
> and we can party You go party but for a large team (or group of teams) I will still prefer the explicitness of data flow and the type safety that Angular/React/Vue/… give me.

jrochkind1 2y ago

You implied but didn't say explicitly, are you doing your front-end development with web components now personally?

jeswin 2y ago
Yes.

rty32 2y ago

One aspect of this is how you think about UI. The underlying pattern of jQuery is fully side-effects -- you select an element and make some changes to it. Frameworks like React and Vue.js allows to create UI components whose states are completely determined by data, i.e. what the UI looks like is the value of a pure function, mathematically speaking. It also updates the UI with minimum DOM changes when the data changes. (Although you don't have to make them pure, and arguably you can achieve the same thing with jQuery.) Depending on where you are, it makes UI widgets much more readable and maintainable. These frameworks are innovative in terms of state management compared to "old approaches" (of course, with additional benefits like reusability etc) Bear in mind that today's websites and web based desktop applications are much, much more complicated than two decades ago, and has a much higher requirement for scalability and maintainability. If you just want to create simple UI, indeed they may not be your best choice.

InsideOutSanta 2y ago

I'm building my most recent project with web components + htmx, and it's mind-blowing how much better all of this feels to me than the typical React/Angular stack. I think there's a place for React and Angular and technologies like them, but 90% of the projects that currently use them would be better off with a much simpler stack.

DimmieMan 2y ago
I have a growing belief the advantage the advantage you're seeing is more HTML first *culture* rather than HTMX itself, I feel the same way using SvelteKit. For example, you submit a form with a couple extra tags on a stock HTML form, do some processing server side and swap out the form (or redirect or whatever). No overriding the on submit callback, no having to wire up a validation hook, no having to think about where things are running. React and angular have a very "let's solve this in JS" culture that creates ultimately unnecessary complexity demons for that 90%.
- LegionMammal978 2y ago
  On the other hand, I've recently been helping someone out with their messy SvelteKit website, and I've personally found the framework horrible to learn. The routing and rendering logic is all diced up between +layout.ts, +layout.svelte, +page.svelte, another +page.svelte, and a few other .ts and .svelte files scattered around lib/, to the point where I can hardly understand what data is going where, and which parts are rerendered when that data is modified. Also, prerendering has bitten me with odd discrepancies between localhost and production. While this messy project likely isn't the best showcase of SvelteKit, I just haven't experienced its alleged simplicity: there are too many files with special roles, and too much magic transforming things behind the scenes. I'd take React over this any day, where the components form a simple tree, and the dependencies are (often painfully) explicit instead of being swept under the rug.
  - DimmieMan 2y ago
    You know I almost didn't mention svelte in passing to ward off this type of comment... Replace svelte and react with any framework and you can a thousand arguments of the same damn format and probably a couple in this thread, It was tangental to the point. One possible advantage of something like HTMX + web components I guess is splitting things into a million files all over the place that can fetch data and manage their own state is painful which seems to be how most svelte/react/whatever disasters are made. There's plenty of ways to make a HTMX disaster but the culture and methodologies being pushed are all leading towards simple, HTML first design which I believe might be the 'secret sauce' rather than the technology itself.

crabmusket 2y ago

> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al). I can't really parse this sentence. It seems to have a lot of ideas in it. Do you want to learn a framework at all, or have one that is so magical that it feels like it doesn't need to be learned? Do you want to read documentation or not? Do you think the problem with React is that its primitives are unsuited to the work you do in it? Or to the work anybody needs to do? I've spent most of my professional career in Vue, so I don't have a great perspective on the React ecosystem. But Vue feels like it must be included in your "complex framework" statement. I've definitely felt some pain from overuse of the framework, or poor understanding of various features, libraries, etc. The ecosystem around full-on SPAs is indeed complex. I'm just not sure what other systems would let me personally, and us broadly, manage a complex stateful client-side app. (This is entirely separate to overuse of SPAs for things that shouldn't be SPAs.)

szundi 2y ago
I think he was pretty clear that the "magic" in frameworks is not something you can easily understand, therefore have to guess how it really works. He doesn't like that.
- jemmyw 2y ago
  You don't need to guess. You can actually read the code! Not saying that you should straight away when learning, but later, when you're familiar with your framework, I think reading through the codebase and understanding it is good practice.
  - cj 2y ago
    You can read the code, but it’s complex and convoluted. He referenced Backbone as a comparison point. If you compare Backbone’s source code to React’s source code, you’ll get what he means. Basically, libraries like Backbone are small and simple enough that you can literally read the source code and fully understand how it works. Compare that to React, where the source code is an order of magnitude larger and very difficult to fully grasp the inner workings. The simplicity and ability to easily understand the source code obviously comes with tradeoffs (e.g. with Backbone, to use it to build a reasonably complex app, you basically have to build your own framework on top of it, compared to React which has more abstractions and therefore is more plug and play.

jsyang00 2y ago

You do not need to know how `useState` works to understand how to use it to write a React application, it is fairly intuitive to understand how to apply the pattern. If I look at your library, it seems to me like it requires a much more complex mental model to begin to use. Of course, it is better in theory for a developer to thoroughly understand the details of their framework, but empirically, React has been very successful in allowing people to build relatively sophisticated applications while understanding very little of the underlying model.

bakugo 2y ago
You don't need to understand how useState works if you're writing a page with a button that increments a number when pressed, from a beginner's tutorial. As soon as you work on any remotely complex codebase, you will run into problems that require a decent mental model of the underlying "magic" to properly understand and solve. "Building sophisticated applications while understanding very little of the underlying model" is how you end up with gigantic piles of unmaintainable spaghetti code full of awful hacks, which seems to be the standard for React applications.
- lolinder 2y ago
  Is this less true of Web Components? I've worked with a lot of different tech stacks over my career and every single one of them has required understanding the internals once you start using them seriously. I haven't found React to be substantially worse for that than any other tech stack I've used.
  - peebeebee 2y ago
    With webcomponents you are pretty close to the “metal”. If you know how to write good vanilla JavaScript, you can take most of that knowledge into webcomponents. You only need to learn the custom components lifecycle, and shadowDOM, which is knowledge about web-standards. With other frameworks you need to learn template syntaxing, how state propagates, how the compiler works, etc etc. Lot of that knowledge might be obsolete in 10 years. Which isn’t to say it can’t be worth it. Learning multiple frameworks and libraries is also very helpful to skill up because you are learning about different concepts and implementations.

sandreas 2y ago

Well, there is a project to convert react components to native ones[1]... this way you can write react and use it everywhere. I think this is the way to go, similar to svelte's approach. Write what you want but compile it to native standards. 1: https://github.com/bitovi/react-to-web-component https://github.com/bitovi/react-to-web-component

8n4vidtmkvmk 2y ago

In my admittedly little experience with shadow DOM, it doesn't isolate as much as it claims. CSS variables pierce the boundary, so if your styles are built around that, you can still run into trouble. I just haven't seen any benefit whatsoever once you have CSS modules. And CSS layers help too.

peebeebee 2y ago
ShadowDOM, and by extension web components are great for providing an extended set of HTML ‘native’ components. Let’s say your company has multiple frontend SPAs with different technologies (angular, react, svelte,…) they could all use the same set of company custom components, like a custom datepicker, or fancy selectbox.
- epolanski 2y ago
  This is the promise, but my experience tells me that web components fall short of that goal.
epolanski 2y ago
This has been a major concern for me. We went for a web component because we needed the same functionality on different websites using different tools. Issue was that we authored the web component with tailwind and then deployed the web component on different websites, some having different versions of tailwind themselves. Even minor differences in hosts tailwind versions led to quite surprising results. What we did in the end is to write a tool that given the tailwind classes used in the webcomponent it would then rewrite the rules at the :root of the web component's own css. Another reason for unhappiness came from lack of isolation regarding the units that derive from the host's base font which forced us to work in pixels directly. All in all, while I understand some of the decisions that went into web components, I can't lie and say that I too have few reasons to not be fully on the web components train, they fall short of the promise of author once, use everywhere.

EMM_386 2y ago

> The current state of Front-end frameworks is an absolute mess. Speaking for myself, I don't want to learn a complex framework. It's really not that hard. I was able to pick up Angular to a level where I could create complex sites with it, or submit acceptable PRs that involved in, in week or so. Granted, I am an experienced developer (C# since beta, HTML/JS/CSS from the start) but it seemed to just make sense quickly. So when I was asked by a company to replace their aging, complex portal to manage critical infrastructure, I chose Angular for the front end. That was smooth sailing. It was stable, performant, looked good and everyone was happy. People often avoid it because it has a "steep learning curve" but that mainly seems to come from developers who came into the industry knowing only JavaScript and maybe a little React. If you are more experienced, you can pick it up right away. And it helps, a lot, to use such frameworks on large complex sites. For various reasons.

jeswin 2y ago
It's a libraries vs frameworks thing. Libraries are relatively safer. Frameworks in C# are slightly better (compared to those on JS), because there are blessed Frameworks and most people are using them. In the JS world, you can see very popular frameworks (with millions of downloads) get abandoned. Not saying that all is well in the .Net world; desktop frameworks are an example. But overall it's a bit different because one company more or less controls it.
edwinjm 2y ago
To be productive in Angular, you also have to know RxJS, which comes with twenty or so functions you have to become familiar with and with some peculiarities like hot and cold observables. So, no, Angular is not easy to learn.

blovescoffee 2y ago

How does your library deal with state management and data flow? What primitives does your library offer for optimization?

wruza 2y ago
How does a regular program deal with “state management” and “data flow”? We all just programmed things for decades when web guys pop out with this “state management” pseudo-problem and started to invent thousands of pseudo-solutions for it. And why do we need “optimization”? It’s a user interface, not an accounting software core. A user types a character, you update few divs content or way under a thousand of divs’ visibility. Which optimization does that need?
- papichulo2023 2y ago
  Old way was storing data in sessions or hidden html inputs. Both way worse than modern alternatives. You kinda sound like you have no idea what you are talking about. Having to render thousands of elements is not uncommon.
- blovescoffee 2y ago
  First "Web guys" is such a demeaning way about talking about real and serious engineers solving real and serious engineering problems. If you don't think frontend engineering solves serious problems, I don't think your opinions about it are serious. All real world programs are stateful. You need some tooling and/or conventions to handle that in a clean way. I recommend this blog post about React Query that talks about some challenges and solutions on the frontend for state management: https://ui.dev/why-react-query https://ui.dev/why-react-query You're questioning the importance of optimization on a website for hackers/tinkerers/engineers? You need optimization for page speed, SEO, animation, elegance, pushing the boundaries... edit to address: "Which optimization does that need?" Optimistic updates, debouncing, handling large responses, cache, etc. etc.
  - wruza 2y ago
    Can you recommend a blog post about “state management” in non-frontend? E.g. some server or maybe a desktop app like e.g. your backup manager. Because my whole premise is that the “problem” is self-imposed, which react is literally the part of. If you don't think frontend engineering solves serious problems, I don't think your opinions about it are serious. I don’t think “frontend” is at all serious, because I have developed user-facing systems since around 2000, and “frontend” (which we called gui controls back in the day) was never a biggest story, when it was worth telling at all. Mostly complex distributed accounting software with various integrations at all levels. I’m not afraid of appeals to serious engineers with serious problems, cause I am one of them and can question it freely. If I appear somewhat toxic, that simply reflects the toxic positivity about the absurd state of things in web dev. It is a collective delusion which suddenly disappears when people get forced out if it, by e.g. going htmx route. Not advocating for htmx specifically, it just happens to be a perfect litmus test. Same for php, people still use it outside of “frontend” bubble and don’t know that “managing” their “state” is a hard problem that requires tens of versions of the best framework of the month.

Narhem 2y ago

If you use web components enough you realize why tools like useState exists then you have to bring in another library like alpine to offer the functionality. The whole point of web components is the ability to offer class encapsulation within the browser without anything other than a file server. JSX has much nicer syntax but I’d rather not have to deal with the overhead of launching a node server. Makes developing time quicker when working with smaller codebases.

jaredklewis 2y ago

> I never had to guess what "useState" does behind the scenes. It's weird to me that React hooks are always dragged out in these arguments as some kind of bogeyman. If you understand the idea of a virtual DOM and a render loop, then it is only a tiny step from there to understand hooks. And you can understand all of these concepts in about 15 minutes: https://www.youtube.com/watch?v=1VVfMVQabx0 https://www.youtube.com/watch?v=1VVfMVQabx0 I just don't get all the hand wringing regarding frontend frameworks. I've been using React since 2014 and in 10 years, there has been exactly one big change to the framework: hooks. When they came out, I spent 15 minutes to understand them. It didn't kill me. And React has been undisputed king the frontend frameworks hill for at least 9 years, but people still act like it's some sort of ever-changing, confusing landscape of options. If you want boring, stable front-end development, choose a super popular, well documented tool like React. Or if you don't like frameworks, use vanilla JS. It's not a crisis.

edwinjm 2y ago
"This framework feels very natural to me" says person using the framework for ten years.
- watwut 2y ago
  I came back to react around a year ago, hooks were completely new to me and pretty instantly understandable. They are just not difficult to comprehend or use.
ForHackernews 2y ago
> If you understand the idea of a virtual DOM and a render loop, then it is only a tiny step from there to understand hooks Once you understand the arcana of the magisterium, it becomes obvious why the encyclicals must be unitarian!

mock-possum 2y ago

Have you tried the Lit library? Using lithtml to write web components based on Lit Component is DREAMY imo, if you’re into web components. It really reminds me of using jquery’s helper methods for ajax - like why wasn’t it just this way by default all along.

meiraleal 2y ago

> In my view the only thing we should retain from the React era is JSX honestly lit-html is much better and based on existing browser APIs. We should make it part of the webcomponents spec! Which is a work in progress: https://github.com/WICG/webcomponents/issues/1069 https://github.com/WICG/webcomponents/issues/1069

troupo 2y ago
> lit-html is much better and based on existing browser APIs. Ah yes. A new framework with its own custom DSL, its own custom hook, sorry, "directive" rules, it's own incompatible flavor of SSR is definitely the way to go, and whould be a part of the standard unlike Polymer before it which was also touted as the bee's knees. > We should make it part of the webcomponents spec! Which is a work in progress: Whatever the outcome of that discussion, it won't be lit.

jdmg94 2y ago

I work with web components within a FAANG company, it was a huge mistake and everyone hates it. If your argument for web components is that they're "so intuitive you don't have to learn" then you're lying to yourself.

cy_hauser 2y ago
How about Lit? I'm just looking at frameworks, components, etc. I was thinking of Lit as simplified web components? Is that valid?
rty32 2y ago
The comment could be so much more helpful if it just casually mentioned what people hate web components about. Sigh.

deliriumchn 2y ago

> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al) I'm always suprised reading statements like that. No offence, but maybe you're in wrong career if you don't want to learn how most popular and important tools of today work... Not to mention that its so simple you can learn everything required to be efficient during lunch break

lelanthran 2y ago
> I'm always suprised reading statements like that. No offence, but maybe you're in wrong career if you don't want to learn how most popular and important tools of today work... Not to mention that its so simple you can learn everything required to be efficient during lunch break This is such a common comment that I am never surprised to see it pop up whenever the "front-end mess" discussion arises. No, you cannot learn React over a lunch break. You cannot learn Angular and Vue over a lunch break. I am skeptical that even you, personally, can learn just the footguns alone present in the hundreds of thousands of lines of code in a specific $FRAMEWORK over one lunch break, two lunch breaks or even a dozen lunch breaks. All those thousands of lines of code implement something, and I will wager a month of my income against a month of your income that you will not learn more than 3 or 4 concepts over a single lunch break, because they all have multiple concepts, multiple use-cases, multiple exceptions-to-the-general-rule and multiple footguns without even including the edge-cases they solve. You will spend several years of lunch breaks, unless you consider reading the wikipedia overview for each $FRAMEWORK to be "learning the $FRAMEWORK". Web components, OTOH, have less functionality than full-blow $FRAMEWORKS, but each can be individually learned over a lunch break, reused by non-JS-developers and is a knowledge base that is more or less future-proof.
- watwut 2y ago
  React is particularly easy to learn tho, much easier then angular. What you definitely can not learn over lunch breakis whatever local developers created as a local ad-hoc framework. Those area always more time consuming to work with, because you have no internet, stack overflow or documentation to help you.

dangsux 2y ago

[dead]

kccqzy 2y ago

For the specific point about useState, I agree about it being too magical. These days when I do write frontend code I use Reagent in Clojurescript. (I use Clojurescript partly for other reasons like its elegant syntax that's better than JSX, and built-in immutable data structures.) Its implementation of (r/atom) is a whole lot more intuitive: you can even think of it as a mutable pointer where the dereferences are tracked. On the other hand useState just feels like a hack for people who really want to avoid writing both classes and closures, and it is a roundabout way of doing things that could have been done in a much more standard and familiar way.

qudat 2y ago

JSX is the worst part of react so I find that to be a pretty wild take.

postalrat 2y ago
You honestly can't think of anything worse than JSX? JSX bothers you more than all the ways useEffect gets used or the restrictions for hooks.
- qudat 2y ago
  The use API is very simple; JSX is a bastardized version of html that is atrocious to read and write. Just imagine all the dev time spent dealing with jsx/tsx. From IDE support to babel, typescript, etc. it is a burden on the JS/Ts ecosystem and severely contributes to fatigue. Yes. JSX is extremely complex to support and it is absolutely the worst part of react.
  - postalrat 2y ago
    So what is the alternative that solves all these perceived problems?
imtringued 2y ago
Hyperscript was a mistake.

chmod775 2y ago

> I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al). Really now. Most devs who think to themselves "man I wonder how useState works internally" will arrive at the logical and correct answer within seconds. It's not complicated or magic. There are bare-bones implementations of react hooks (-ish) with a couple hundred lines of code. Implementing a basic "useState" and "runFunctionComponent" is easier than most third-semester CS assignments. If that's the bar for magic, I'm surrounded by 20th level Warlocks coming up with new Eldritch Invocations for fun over breakfast.

zelphirkalt 2y ago
Hundreds of lines of code?? That sounds like way too much complication for something like that, tbh.
- chmod775 2y ago
  If you want to be at least sort-of react hooks compatible, there's a bunch of hooks you need to implement.
- kaba0 2y ago
  Heh? My smallest hobby project that is not a POC but actually is finished and is doing something is like 1000 lines long. There are very few stuff you can do with less than 100 lines. (Just for completeness sake, Haskell and alia sometimes might get away with less lines, because they tend to be “wider”. Word-count is a better metric here)
imtringued 2y ago
>Most devs who think to themselves "man I wonder how useState works internally" will arrive at the logical and correct answer within seconds. The answer is shockingly dumb. To be fair, I checked the code years ago, but basically almost every hook calls useReducer internally and useReducer uses an array stored in a global variable that is set before your component code gets called and the order of the hook calls determines which hook gets what useReducer state. It's basically a giant kludge and the React developers and users pat themselves on the back how "functional" their components are, when in reality they are flinging global mutable state like crazy.

gspencley 2y ago

> In my view the only thing we should retain from the React era is JSX (for many reasons, true type-safety, autocomplete etc) Warning: opinion incoming. JSX is one of two reasons that I never liked React at all and wish it would go away. I've been developing "web applications" since the latter half of the 90s. I've worked with everything from an in-house built dynamic template language (very similar to what PHP did in the early days) developed in C++ and served using CGI in Apache, to developing with PHP to Java Spring MVC to Django to modern frontend frameworks including both React and Angular. JSX reminds me of what PHP was like in the 90s and early 00s. People adopted it widely because the barrier to entry was extremely low. We had all of these static HTML websites and "developers" could just go in and start adding control flow to those documents in order to add dynamic functionality. It was easy ... and it quickly turned into a complete mess so big that PHP ended up with a reputation as being a toy language that "serious programmers" wouldn't be caught dead touching. That reputation was a bit unfair but also kind of earned. With the rise of PHP's popularity, the PHP "community" itself came to realize that they had a decent turing-complete programming language that they were working with, but that this idea of mixing business logic within HTML documents was a massive anti-pattern. It's ironic that what began its journey as a template language eventually realized that the best thing for the language was to stop using it as a template language, and to adopt different template languages such as Smarty in order to promote a separation of concerns between view / presentation concerns and business logic. React was never created as a "framework." There are actual frameworks that are starting to come out that use React for its view layer, such as NextJS, but React itself is just a library that allows you to create custom components and then choose your adventure when it comes to what other libraries you want to mix and match. But because people reach for React to start throwing together dynamic frontends quickly, everything is compononent-first. So it actively encourages you to put business and integration concerns in what really ought to be your view / presentation "layer." And JSX magnifies that problem by just being JavaScript. So, again, it's PHP all over again. You've got a very powerful turing-complete programming language that you intersperse with your markup and you get messes. Even in the most well-written, concern-separated React projects I still see a lot of "ugliness" that comes through with JSX. I did mention that it was one of two reasons I'm not a fan of React, the other is that - again because it was only conceived of as a component / view library - there is no inbuilt view encapsulation / scoped styles. This problem is somewhat mitigated by CSS modules these days. But view encapsulation is something that I've always seen as Angular's killer feature - the ability to just style your tags directly and create component markup that is completely devoid of class="" attributes. Angular and VueJS actually trained me to hate 99% of class="" attributes and to think of them as a type of code smell... just because it is possible to create higher-level components that don't have any at all but still styling when needed.