7 ms·

Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional com

Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation. I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me. I'm happy that other people seem to enjoy them without restraint, but obscuring magical details and making side effects seem like more of a big deal than they really are in programming seems like a design choice intended to infantilize engineers and shelter them from reality. I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years. I think having seen front-end software come and go so many times, I'd rather write some simple utility functions wrapping `Document.createElement()` and use native event handling. Too much fluff in front-end. I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.

motoxpro 4y ago
Picked up react in the last 5-6 years and looking at old class component examples confuse me to no end. I guess it’s just what you learned first.
- andrewmcwatters 4y ago
  :) True. My first web development experiences were on AOL Hometown and reading people's 1337 scripts from dynamicdrive.com. DHTML! Updating PHP scripts over FTP! Shared hosting. Oh right, you meant React wise... yeah...
  - chess_buster 4y ago
    me too
- Aeolun 4y ago
  I worked with class components first. Built a whole app in them. Now we’ve migrated to functional and I look back at the class based ones wondering how I ever dealt with that. I didn’t want to adopt functional, but let everyone make their own decisions on what to use, and now I’m very happy I did.
  - selfmodruntime 4y ago
    Right. I don‘t understand the HN crowd. A Haskell thread every weak, tons of people arguing that <current year> will be the breakthrough of lisp on desktop, but they scream for OO patterns in their frontend frameworks.
    - detaro 4y ago
      So why do you scream for OO patterns in frontend frameworks?
    - tome 4y ago
      Possibly the screaming for different things is being done by different people.
nmjohn 4y ago
> I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though. Asking for an API interface to be stable for decades __across all future versions of the library__ doesn't sound realistic to me. Nothing is forcing you to update to the future new version of react - which has not been released, and is likely years away - that removes support for class components.
- hartator 4y ago
  Basic HTML tags are more than 20 years old now.
  - School-Cotton 4y ago
    There are some you can’t use anymore, like blink.
    - hartator 4y ago
      <blink> was never supported by all “in-fashion” browsers though.
  - selfmodruntime 4y ago
    Yet some are deprecated, Quite a lot don‘t work how specified and even more work differently depending on the browser you‘re using.
- andrewmcwatters 4y ago
  [flagged]
  - nmjohn 4y ago
    I've spent the vast majority of my career outside of front-end development. You're being extremely condescending and presumptuous so I will not engage further.
hartator 4y ago
Yes, I have trouble getting what was wrong with the first stables of React. It seems they are getting bored.
r3trohack3r 4y ago
This is exactly what I'm doing with my personal "framework" I use for client contracts. It's just Web Components with a handy class based wrapper. I call it Template, since it's based off <template> tags. It's a joy to work in, feels "frameworky" but it's just web standards with <100 lines of convenience JS wrapped around it. There is no magic beyond what the browser provides - I like it that way. https://github.com/retrohacker/template/ https://github.com/retrohacker/template/ It's "open source" as a reference. Just using it for myself. There aren't many docs beyond notes to myself. But the actual framework is a 90LoC JavaScript file that is an easy read. You're welcome to kick the tires. If you like it I'd entertain PRs and stuff but it's such a small library forking is probably entirely reasonable to make your own flavor too. The general idea is you extend the Template base class and call "super" with the id of the <template> that will get bound to the ShadowDOM when the class is mounted. Then you call instance.mount and pass a dom node to mount it into the DOM. For child nodes, you use `this.fragment.querySelector` to select them from the <template> you mounted. It supports garbage collection by tracking children, so when you "unmount" it recursively unmounts all child instances as well. Finally it has an event emitter implementation, so changes/actions/events bubble up the DOM while state can push down through the DOM. Keeps things clean. I recently added state methods since I was duplicating state management everywhere. Now the base template class has a `setState` that will emit a single `change` event for all changes in the current "tick" of the browser eval loop. Cheers and happy hacking!
- andrewmcwatters 4y ago
  Cheers, kudos to you for writing long lasting software. Edit: Hey another Arizona hacker! Right on!
  - r3trohack3r 4y ago
    Right on! Just checked out your website. I'm also doing Software consulting in Arizona, would love to grab coffee (digital or otherwise) and compare notes. If you are in the PHX area, checkout https://www.heatsynclabs.org/ https://www.heatsynclabs.org/ - they do Coffee & Code every Wednesday.
bakugo 4y ago
> seems like a design choice intended to infantilize engineers and shelter them from reality. The entire front-end framework landscape is like this. It's all designed to appeal to the kind of "engineer" that just wants to copy paste code and have it work like magic without ever thinking about what's actually going on.
- nailer 4y ago
  This is exactly the “just use react” stereotype. Download a random react component from NPM and 90% chance they just added wrapper divs until they could get the CSS to (kind of) work.
- andrewmcwatters 4y ago
  It's just front-end engineering in general, you don't get this with people who work in other subfields of software engineering. I get it, though. It's OK until you need to learn and grow beyond it, which I think anyone doing this long enough will. It sucks that people learn this the hard way, though, and the only way to grow beyond this for people new to the field is to eventually get burned and learn there are other ways to do all of this. There are whole generations who don't know what session cookies are! And... that's just OK.
  - Aeolun 4y ago
    > There are whole generations who don't know what session cookies are! I really enjoy JWTs, but the idea of sending all my user data on every request hadn’t occurred to me, and still feels mildly wasteful.
    - andrewmcwatters 4y ago
      Generally a session cookie requires that you send over a unique ID. That's usually it. If you use JWTs, you're sending over the same amount of data if not more, but now you have to do things yourself instead of just utilizing features browsers natively have. You could utilize a key system to gain the same advantage as not having to use persistence as one gets using JWTs when implementing session cookies, if you wanted, too.
epolanski 4y ago
I'm slowly trying to get most of my projects and client ones to leverage more and more web components, I'm sick of reimplementing the same things over and over.
timcobb 4y ago
Not seeing where it says that classes aren't going to be supported anymore
mwcampbell 4y ago
> seems like a design choice intended to infantilize engineers and shelter them from reality I think it's more charitable to assume that the designers are designing this for themselves and are just being aware of their own fallibility and limited mental capacity (we're only human after all), not seeking to infantilize or shelter some lesser class of programmers.
- explaininjs 4y ago
  Eh... having worked with a Facebook developer tools team, they quite literally do dismiss the vast majority of the engineers at the company as "those guys who wouldn't be able to understand the stuff us devtools people do".
davnn 4y ago
Your will be surprised how nicely a functional approach with hooks can improve your frontend architecture. Side effects are the source of all evil, it‘s quite useful to take special care.
- andrewmcwatters 4y ago
  I think the thing is that you're focused on this specific implementation detail of React. I just don't care. Not that you're not right, either! It's just a matter of competing interests. I'm running two businesses with a third on the way. I have bigger problems than people reinventing stuff with no benefits compared to what we were doing 20 years ago. I'm writing software every day, so I'm still involved in front-line work, but I'm interested in being the level of productive most people aren't. So the bigger questions on my mind are things like, "What knowledge can I build up that doesn't become obsolete?" "What social effects drive adoption that endanger those goals?" Those are questions that have, at least immediately, very little to do with implementation details, and are questions that help me navigate whether to ignore new technologies all together, or when I identify something new when I decide to adopt it. A part of that is looking for cues from maintainers that say, "Hey, we care that you're shipping, and we're not going to endanger your labor spent learning our intellectual property."
  - Aeolun 4y ago
    Then you should use PHP. It’s the only thing I’ve ever used where I could run decade old websites with a marginal number of changes.
  - selfmodruntime 4y ago
    Backwards compatibility with class components still exists. It will exist in the future.
azangru 4y ago
> I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial This is a great idea. Nothing controversial about it.
- stuff20230314 4y ago
  Decoupling your personal future from Silicon Valley devs' pursuit of promotions is always a great idea.
- andrewmcwatters 4y ago
  You end up having to answer to people in interview processes that have fewer years of experience than you, and have written sometimes orders of magnitude less code than you, and wonder why you make "weird" decisions not knowing that those decisions have been made with a collection of exceptional experiences. Lots of engineers out there today who don't have a simple answer for, "So what happens when one of your dependencies no longer exists on the Internet for one reason or another?"
  - Aeolun 4y ago
    > So what happens when one of your dependencies no longer exists on the Internet for one reason or another? For this to be a problem would require it to disappear from both npm and Github simultaneously, and for none of our devs to still have it on their local machine so we can reupload it under a different name. Like, I didn’t think about that until you wrote it, but coming up with an answer isn’t exactly hard. I’d rather worry about things that are more likely to happen, like someone accidentally dropping the prod database tomorrow.
    - andrewmcwatters 4y ago
      And with Docker containers? And proprietary binaries? My point being, as you've proven in your reply, that most developers are going to only think of the most obvious cases. And when you're a prolific writer and you've experienced more than just npm and GitHub, you're going to run across a scenario that makes you start thinking about how your practices in one ecosystem don't apply everywhere. I own intellectual property composed of dependencies that can't be obtained anymore. Or two people in the world are the only individuals who are known to still have the dependency, but neither of them will supply it. What's your plan for depending on a SaaS who goes out of business? Is everyone experiencing that on a regular basis? No, they aren't. But then you do. Once. And it changes how you do everything later, because you no longer have the privilege of not thinking about it.
nfRfqX5n 4y ago
React has been out for a decade. Why can’t your system could stay on this version forever?
- andrewmcwatters 4y ago
  I won't immediately update, since future feature development will take priority, but eventually I will want to update since the current industrial risk is that surrounding dependencies may have bugs that are a risk to customers. It's a low likelihood, but I'd rather stay up to date when I can.
ojkelly 4y ago
> Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation. The writing has been on the wall for 4 years that hooks are the future. You _can still_ use class components. Function component with hooks is the simplest API you can get to React itself—classes are more of an abstraction. > I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me. We all adopted hooks because it makes things easier to reason about. If you’re still having trouble understanding them, I’d urge you to dig deeper into how they and React works. > I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years. I can’t think of a better way to develop an appreciation of UI frameworks that to go without. > I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though. Barely any software runs untouched for decades (documents don’t count). So it’s not that the sentiment isn’t appreciated, I think most of us would agree—it’s that it’s an impractical expectation.
- andrewmcwatters 4y ago
  When you maintain your own software for periods of time that outlast front-end engineering trends or IC's entire career tracks, your opinions might change. Plenty of software runs untouched for decades. A lot of it powers your interactions with people on HN right now, from drivers, to font rasterization and backing layer UI composition. There are bugs in codebases that have taken 20 years for people to even notice. It happens. When people don't have to worry about trivial details, they can focus greater efforts.
  - lelandfe 4y ago
    At once I sympathize with your viewpoint and also have to say that React is the longest I've ever seen a Javascript thing stay in the notoriously fickle good graces of the frontend world – short of perhaps jQuery. Railing against it is railing against the best-in-class example of what you want... even if it still falls short of what you want. A decade is nothing to sneeze at.
Varqu 4y ago
As a programming newbie, I would love to see a hard fork of React without Hooks (and their magic)
- web3-is-a-scam 4y ago
  check out Preact and Inferno
  - easrng 4y ago
    I love preact but it definitely has hooks.
    - web3-is-a-scam 4y ago
      good to know, it’s been a while since I’ve used it (moved on to htmx for my uses mostly) and a quick look on the homepage still espouses use of setState and class components.
xdennis 4y ago
> obscuring magical details and making side effects seem like more of a big deal than they really are in programming seems like a design choice intended to infantilize engineers and shelter them from reality. You seem to be taking it too personal. There's no need to call others infants for preferring hooks.
groestl 4y ago
> `Document.createElement()` and use native event handling. I'm not a frontend dev by all means, but I must say, I've worked on such projects (100LOC create utils & event handling) and it was a joy. I always wanted to recommend it to people when they complain about the state of js frameworks, but I felt I've no authority to do so, because my experience is limited (only internal projects).
- Aeolun 4y ago
  But have you built whole applications in them? React is one of the few frameworks where I almost never feel like they didn’t consider consider all use cases.
  - deleted 4y ago
    [deleted]
codeptualize 4y ago
And then we have another framework! This is why we have so many :D
deleted 4y ago
[deleted]
brundolf 4y ago
I don't think it's productive to throw out enotionally-charged words like "fanatical" and "infantalize" in these conversations. There are many valid complaints to make about React hooks, but I'm not really seeing those here. And I'm not seeing evidence that you've crossed chesterton's fence with them either. I'll criticize hooks all day, but for all their footguns, they provide a level of abstraction (and a simplicity of implementation for it) that's really hard to argue with. They let you break up reactive stateful code in maybe the most scalable way I've ever seen, and their contract with the outside world allows for some crazy optimizations on the framework's part. I think the team is onto something really special here Of course they're also easy to misuse, and they can be really "magical" until you fully grasp them. Those are problems the ecosystem will have to grapple with (and I know the core team is aware of them). Though the "magic" at least is due more to weirdness and inversion of control than it is to actual complexity. Having a grasp on how they work, I feel like I wouldn't have too much trouble implementing a basic version of the same system myself, because the primitives are ultimately not very complicated I believe hooks are really good bones for building UIs, and I think they'll last because of it, even though the surface developer experience has some warts for now
- andrewmcwatters 4y ago
  I think it's sufficient to say that having been exposed to hundreds of thousands of lines of code across different industries and programming languages, I don't like React Hooks, and I don't even like them repurposing the word "hook" which is otherwise known as a trampoline in other programming language contexts. React Hooks, if anything should have just been called React Callback Queues. As for emotionally charged words, maybe it's not appropriate in the current zeitgeist to post without some degree first of self-censorship, but it's how I feel, so I'm going to say it. React Hooks were fanatically adopted, in my opinion. Side effects are a regular part of programming. I find it, thusly, infantilizing to hide those details. I wish people would stop this sort of thing, but if you want to say your part and that's how you feel, say it too. Edit: You've apparently even been downvoted for expressing this sentiment, which I hate on HN, because it's how you felt. I wish social sites wouldn't do this. No one should be able to invalidate that.
paulryanrogers 4y ago
> Class components remain supported, and are documented in the Legacy API section of the new site. So they're still not breaking backward compatibility. Looks like you don't have to refactor until you need something that's only hooks based.
nagonago 4y ago
> front ends independent of any of the existing frameworks that exist today, which I think is probably controversial Not sure controversial is the right word, in fact I think it is quite a common sentiment among developers, especially those that originally come from back-end. The only problem is finding a company that is willing to forgo the frameworks. They do exist though. Here's a short list of companies that use vanilla JavaScript, most notably GitHub and Netflix: https://gomakethings.com/companies-that-use-vanilla-js/ https://gomakethings.com/companies-that-use-vanilla-js/
fndex 4y ago
> I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though. Clojure and ClojureScript very much appreciate that sentiment. re-frame, a library for creating React apps with ClojureScript is rock solid, many years old, and still on version 1, meaning no breaking changes so far. 5 years old re-frame code still looks the same today.
- koito17 4y ago
  I use re-frame, but you cannot deny that class components being deprecated is going to be pure trouble for re-frame. Re-frame relies on the reagent library's Reaction interface. While re-frame does not depend on anything else in the reagent library, it is natural to use Reagent for your rendering. But reagent itself emits class components by default, since it predated hooks by several years. Now that class components are essentially deprecated in the documentation, and the fact that React 18 support is still an experimental feature in Reagent, people using ClojureScript and React today are in quite some trouble, especially since React is the only JS framework I know of that is compatible with functional programming. While reagent is able to emit function components, there is a performance penalty to this, since it employs some hacks in order to be compatible with both hooks and ratoms. Thankfully there are some projects that are attempting to bring modern React[1] and even bring the whole re-frame API alongside it.[2] Last weekend I decided to try out helix, refx, reitit, and shadow-cljs' lazy-loaded modules and managed to make a pretty nice demo app that uses essentially the re-frame API but it's all modern React and hooks, and the router was capable of lazily loading modules containing code of pages the user wanted to navigate to. [1] https://github.com/lilactown/helix https://github.com/lilactown/helix [2] https://github.com/ferdinand-beyer/refx https://github.com/ferdinand-beyer/refx
  - askonomm 4y ago
    But Reagent supports functional components as well, with hooks and all. I don't see why I'd have to change an entire library because class components are being retired. I also very much like Hiccup, and so do many of us, because code is data and data is code, and Helix has decided not to support that.
Rapzid 4y ago
The docs are kinda poor on them IMHO. They don't approach the hooks from first principles. For example look up the useImperativeHandle hook docs. Use those to explain simple questions: > Why do you need this? > Why can't I just update the ref however I want! Look up forwardRef: > Why can't I just access ref as a prop? Further, everyone is trying to cram all logic into hooks and components. It's to the point of insanity. Look, React is so popular I know most are using it for throw away marketing sites and other low-tier shit (sorry y'all but you know it) but.. This architecture doesn't fly in large apps; ee b2b etc. React Router v6 seems to have no non-hook based APIs that aren't marked private!? They screwed the pooch on useNavigation; it causes unnecessary re-renders. Surprise surprise, but if they can't get it right...
- jholman 4y ago
  > React Router v6 seems to have no non-hook based APIs that aren't marked private!? They screwed the pooch on useNavigation; it causes unnecessary re-renders. Surprise surprise, but if they can't get it right... Whoa, you lost me here. React Router is no shining beacon of good API design. They've never done things well, just "well enough". I'm not saying RR is terrible, I'm not saying the RR devs should feel bad about how bad they are or something, I'm just saying that these guys are not the guys you want to point at for "if they can't get it right...". (Example of RR being not-so-amazing: Initially (v1? v2?) they required you to use attributes for the components that would render in a route, with no way to specify props short of making a custom component that wrapped the one you wanted. Then they added the ability to pass a function as an attribute, which let you specify props, so that was usable but clunky. Then, in yet a third version of the API (I think this is by v4?), we got the ability to use JSX in children to fully specify the components, which obviously was the right choice all along, it's literally the point of JSX. And again, I'm not saying I'm a better software engineer than those guys; I think I'd have got this one right but I'm sure I'd have screwed up a dozen other things.)
  - Rapzid 4y ago
    I'm not going to argue with any of that but: * It is the de facto "official" community router solution * It's made by the same team as Remix..
robertoandred 4y ago
You call other devs “infants” but are unable to understand how hooks work. It’s really not complicated under the hood.
dxchester 4y ago
Agreed that investing in standards is always a good bet. But at the same time, we have so many web frameworks in part because what is spec'd in plain JavaScript/HTML/CSS is not quite high-level enough to be really be a productive foundation just on its own. Going all the way back to raw `Document.createElement` will come with its own special pain. With the WebComponents movement though, we are getting ever closer to being able to rely on native browser functionality for a good share of what frameworks set out to do. We're not all the way to bliss without frameworks, but for what it's worth here is my 481-byte library to support template interpolation with event binding in order to make WebComponents pretty workable mostly as-is: https://github.com/dchester/yhtml https://github.com/dchester/yhtml
reaperducer 4y ago
I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial Do it. Don't be afraid to, either. Over the years, I've put together a list of some big and VERY big companies whose web developers hand-code their web sites without assistance from the framework-du-jour. I recently learned about a new one for my list: A nine-figure household name tech company. The list is useful for when I'm in bars or developer meetups or coffee shops and someone who's only been putting together web sites for a few years starts preaching about how whatever shiny new thing they just learned about in junior college is the one and only way to do things.
- gratitoad 4y ago
  You tease. Dunno why you’d go out of your way to not name names, but it’s working: Who?
leros 4y ago
I'm usually the guy who is several versions behind on every library and I stick with what I know instead of exploring new features. I will say that React has been pretty pleasant to work with in regards to not forcing me to rewrite my code much. They're pretty good about keeping the old methods around our several major versions so you have plenty of time to make changes to your app or just keep doing things the old way.
atsjie 4y ago
> I want the decisions I make to last decades, not just a few years New to frontend?
FpUser 4y ago
I use some narrow scope libraries. Other than that I use plain JavaScript with Web Components. No frameworks. Saves me a bunch of time.
rwalle 4y ago
You probably should have a better understanding of how hooks work and why they are better before posting a long and meaningless rant like this. There are things that you complain when you are junior, but start to understand better and realize why people do certain things in a certain way when you get more experience and can look at things from a higher viewpoint.
FactoryReboot 4y ago
Hooks were the beginning of the end of my interest in React. Truly a terrible concept. Way to magic. Not overly aesthetic, not to mention the async programming techniques the js community has developed for over a decade all kinda break down with hooks. You can’t even just keep using class based as they have no way to consume hooks. Unit testing of hook based code is non existent IME. It’s some kinda funky E2E feeling test. React was my favorite framework before. It’s really a shame.
- SPBesui 4y ago
  > Unit testing of hook based code is non existent IME. It’s some kinda funky E2E feeling test. I’m guessing you’re referring to the fact that you can’t access component state like you can with class components. If so, that’s not required to do a unit test. That’s a sign that implementation details are leaking into your tests.
- motoxpro 4y ago
  They are just so simple to me that the "magic" never comes into play. Just a function that gets called when something in an array is different between renders.
bdangubic 4y ago
funniest thing to me is how many people identify themselves as "react person" or "angular person" and I am thinking "you'd be better off saying you are "cobol person"

motoxpro 4y ago

Picked up react in the last 5-6 years and looking at old class component examples confuse me to no end. I guess it’s just what you learned first.

andrewmcwatters 4y ago
:) True. My first web development experiences were on AOL Hometown and reading people's 1337 scripts from dynamicdrive.com. DHTML! Updating PHP scripts over FTP! Shared hosting. Oh right, you meant React wise... yeah...
- chess_buster 4y ago
  me too
Aeolun 4y ago
I worked with class components first. Built a whole app in them. Now we’ve migrated to functional and I look back at the class based ones wondering how I ever dealt with that. I didn’t want to adopt functional, but let everyone make their own decisions on what to use, and now I’m very happy I did.
- selfmodruntime 4y ago
  Right. I don‘t understand the HN crowd. A Haskell thread every weak, tons of people arguing that <current year> will be the breakthrough of lisp on desktop, but they scream for OO patterns in their frontend frameworks.
  - detaro 4y ago
    So why do you scream for OO patterns in frontend frameworks?
  - tome 4y ago
    Possibly the screaming for different things is being done by different people.

nmjohn 4y ago

> I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though. Asking for an API interface to be stable for decades __across all future versions of the library__ doesn't sound realistic to me. Nothing is forcing you to update to the future new version of react - which has not been released, and is likely years away - that removes support for class components.

hartator 4y ago
Basic HTML tags are more than 20 years old now.
- School-Cotton 4y ago
  There are some you can’t use anymore, like blink.
  - hartator 4y ago
    <blink> was never supported by all “in-fashion” browsers though.
- selfmodruntime 4y ago
  Yet some are deprecated, Quite a lot don‘t work how specified and even more work differently depending on the browser you‘re using.
andrewmcwatters 4y ago
[flagged]
- nmjohn 4y ago
  I've spent the vast majority of my career outside of front-end development. You're being extremely condescending and presumptuous so I will not engage further.

hartator 4y ago

Yes, I have trouble getting what was wrong with the first stables of React. It seems they are getting bored.

r3trohack3r 4y ago

This is exactly what I'm doing with my personal "framework" I use for client contracts. It's just Web Components with a handy class based wrapper. I call it Template, since it's based off <template> tags. It's a joy to work in, feels "frameworky" but it's just web standards with <100 lines of convenience JS wrapped around it. There is no magic beyond what the browser provides - I like it that way. https://github.com/retrohacker/template/ https://github.com/retrohacker/template/ It's "open source" as a reference. Just using it for myself. There aren't many docs beyond notes to myself. But the actual framework is a 90LoC JavaScript file that is an easy read. You're welcome to kick the tires. If you like it I'd entertain PRs and stuff but it's such a small library forking is probably entirely reasonable to make your own flavor too. The general idea is you extend the Template base class and call "super" with the id of the <template> that will get bound to the ShadowDOM when the class is mounted. Then you call instance.mount and pass a dom node to mount it into the DOM. For child nodes, you use `this.fragment.querySelector` to select them from the <template> you mounted. It supports garbage collection by tracking children, so when you "unmount" it recursively unmounts all child instances as well. Finally it has an event emitter implementation, so changes/actions/events bubble up the DOM while state can push down through the DOM. Keeps things clean. I recently added state methods since I was duplicating state management everywhere. Now the base template class has a `setState` that will emit a single `change` event for all changes in the current "tick" of the browser eval loop. Cheers and happy hacking!

andrewmcwatters 4y ago
Cheers, kudos to you for writing long lasting software. Edit: Hey another Arizona hacker! Right on!
- r3trohack3r 4y ago
  Right on! Just checked out your website. I'm also doing Software consulting in Arizona, would love to grab coffee (digital or otherwise) and compare notes. If you are in the PHX area, checkout https://www.heatsynclabs.org/ https://www.heatsynclabs.org/ - they do Coffee & Code every Wednesday.

bakugo 4y ago

> seems like a design choice intended to infantilize engineers and shelter them from reality. The entire front-end framework landscape is like this. It's all designed to appeal to the kind of "engineer" that just wants to copy paste code and have it work like magic without ever thinking about what's actually going on.

nailer 4y ago
This is exactly the “just use react” stereotype. Download a random react component from NPM and 90% chance they just added wrapper divs until they could get the CSS to (kind of) work.
andrewmcwatters 4y ago
It's just front-end engineering in general, you don't get this with people who work in other subfields of software engineering. I get it, though. It's OK until you need to learn and grow beyond it, which I think anyone doing this long enough will. It sucks that people learn this the hard way, though, and the only way to grow beyond this for people new to the field is to eventually get burned and learn there are other ways to do all of this. There are whole generations who don't know what session cookies are! And... that's just OK.
- Aeolun 4y ago
  > There are whole generations who don't know what session cookies are! I really enjoy JWTs, but the idea of sending all my user data on every request hadn’t occurred to me, and still feels mildly wasteful.
  - andrewmcwatters 4y ago
    Generally a session cookie requires that you send over a unique ID. That's usually it. If you use JWTs, you're sending over the same amount of data if not more, but now you have to do things yourself instead of just utilizing features browsers natively have. You could utilize a key system to gain the same advantage as not having to use persistence as one gets using JWTs when implementing session cookies, if you wanted, too.

epolanski 4y ago

I'm slowly trying to get most of my projects and client ones to leverage more and more web components, I'm sick of reimplementing the same things over and over.

timcobb 4y ago

Not seeing where it says that classes aren't going to be supported anymore

mwcampbell 4y ago

> seems like a design choice intended to infantilize engineers and shelter them from reality I think it's more charitable to assume that the designers are designing this for themselves and are just being aware of their own fallibility and limited mental capacity (we're only human after all), not seeking to infantilize or shelter some lesser class of programmers.

explaininjs 4y ago
Eh... having worked with a Facebook developer tools team, they quite literally do dismiss the vast majority of the engineers at the company as "those guys who wouldn't be able to understand the stuff us devtools people do".

davnn 4y ago

Your will be surprised how nicely a functional approach with hooks can improve your frontend architecture. Side effects are the source of all evil, it‘s quite useful to take special care.

andrewmcwatters 4y ago
I think the thing is that you're focused on this specific implementation detail of React. I just don't care. Not that you're not right, either! It's just a matter of competing interests. I'm running two businesses with a third on the way. I have bigger problems than people reinventing stuff with no benefits compared to what we were doing 20 years ago. I'm writing software every day, so I'm still involved in front-line work, but I'm interested in being the level of productive most people aren't. So the bigger questions on my mind are things like, "What knowledge can I build up that doesn't become obsolete?" "What social effects drive adoption that endanger those goals?" Those are questions that have, at least immediately, very little to do with implementation details, and are questions that help me navigate whether to ignore new technologies all together, or when I identify something new when I decide to adopt it. A part of that is looking for cues from maintainers that say, "Hey, we care that you're shipping, and we're not going to endanger your labor spent learning our intellectual property."
- Aeolun 4y ago
  Then you should use PHP. It’s the only thing I’ve ever used where I could run decade old websites with a marginal number of changes.
- selfmodruntime 4y ago
  Backwards compatibility with class components still exists. It will exist in the future.

azangru 4y ago

> I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial This is a great idea. Nothing controversial about it.

stuff20230314 4y ago
Decoupling your personal future from Silicon Valley devs' pursuit of promotions is always a great idea.
andrewmcwatters 4y ago
You end up having to answer to people in interview processes that have fewer years of experience than you, and have written sometimes orders of magnitude less code than you, and wonder why you make "weird" decisions not knowing that those decisions have been made with a collection of exceptional experiences. Lots of engineers out there today who don't have a simple answer for, "So what happens when one of your dependencies no longer exists on the Internet for one reason or another?"
- Aeolun 4y ago
  > So what happens when one of your dependencies no longer exists on the Internet for one reason or another? For this to be a problem would require it to disappear from both npm and Github simultaneously, and for none of our devs to still have it on their local machine so we can reupload it under a different name. Like, I didn’t think about that until you wrote it, but coming up with an answer isn’t exactly hard. I’d rather worry about things that are more likely to happen, like someone accidentally dropping the prod database tomorrow.
  - andrewmcwatters 4y ago
    And with Docker containers? And proprietary binaries? My point being, as you've proven in your reply, that most developers are going to only think of the most obvious cases. And when you're a prolific writer and you've experienced more than just npm and GitHub, you're going to run across a scenario that makes you start thinking about how your practices in one ecosystem don't apply everywhere. I own intellectual property composed of dependencies that can't be obtained anymore. Or two people in the world are the only individuals who are known to still have the dependency, but neither of them will supply it. What's your plan for depending on a SaaS who goes out of business? Is everyone experiencing that on a regular basis? No, they aren't. But then you do. Once. And it changes how you do everything later, because you no longer have the privilege of not thinking about it.

nfRfqX5n 4y ago

React has been out for a decade. Why can’t your system could stay on this version forever?

andrewmcwatters 4y ago
I won't immediately update, since future feature development will take priority, but eventually I will want to update since the current industrial risk is that surrounding dependencies may have bugs that are a risk to customers. It's a low likelihood, but I'd rather stay up to date when I can.

ojkelly 4y ago

> Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation. The writing has been on the wall for 4 years that hooks are the future. You _can still_ use class components. Function component with hooks is the simplest API you can get to React itself—classes are more of an abstraction. > I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me. We all adopted hooks because it makes things easier to reason about. If you’re still having trouble understanding them, I’d urge you to dig deeper into how they and React works. > I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years. I can’t think of a better way to develop an appreciation of UI frameworks that to go without. > I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though. Barely any software runs untouched for decades (documents don’t count). So it’s not that the sentiment isn’t appreciated, I think most of us would agree—it’s that it’s an impractical expectation.

andrewmcwatters 4y ago
When you maintain your own software for periods of time that outlast front-end engineering trends or IC's entire career tracks, your opinions might change. Plenty of software runs untouched for decades. A lot of it powers your interactions with people on HN right now, from drivers, to font rasterization and backing layer UI composition. There are bugs in codebases that have taken 20 years for people to even notice. It happens. When people don't have to worry about trivial details, they can focus greater efforts.
- lelandfe 4y ago
  At once I sympathize with your viewpoint and also have to say that React is the longest I've ever seen a Javascript thing stay in the notoriously fickle good graces of the frontend world – short of perhaps jQuery. Railing against it is railing against the best-in-class example of what you want... even if it still falls short of what you want. A decade is nothing to sneeze at.

Varqu 4y ago

As a programming newbie, I would love to see a hard fork of React without Hooks (and their magic)

web3-is-a-scam 4y ago
check out Preact and Inferno
- easrng 4y ago
  I love preact but it definitely has hooks.
  - web3-is-a-scam 4y ago
    good to know, it’s been a while since I’ve used it (moved on to htmx for my uses mostly) and a quick look on the homepage still espouses use of setState and class components.

xdennis 4y ago

> obscuring magical details and making side effects seem like more of a big deal than they really are in programming seems like a design choice intended to infantilize engineers and shelter them from reality. You seem to be taking it too personal. There's no need to call others infants for preferring hooks.

groestl 4y ago

> `Document.createElement()` and use native event handling. I'm not a frontend dev by all means, but I must say, I've worked on such projects (100LOC create utils & event handling) and it was a joy. I always wanted to recommend it to people when they complain about the state of js frameworks, but I felt I've no authority to do so, because my experience is limited (only internal projects).

Aeolun 4y ago
But have you built whole applications in them? React is one of the few frameworks where I almost never feel like they didn’t consider consider all use cases.
- deleted 4y ago
  [deleted]

codeptualize 4y ago

And then we have another framework! This is why we have so many :D

deleted 4y ago

[deleted]

brundolf 4y ago

I don't think it's productive to throw out enotionally-charged words like "fanatical" and "infantalize" in these conversations. There are many valid complaints to make about React hooks, but I'm not really seeing those here. And I'm not seeing evidence that you've crossed chesterton's fence with them either. I'll criticize hooks all day, but for all their footguns, they provide a level of abstraction (and a simplicity of implementation for it) that's really hard to argue with. They let you break up reactive stateful code in maybe the most scalable way I've ever seen, and their contract with the outside world allows for some crazy optimizations on the framework's part. I think the team is onto something really special here Of course they're also easy to misuse, and they can be really "magical" until you fully grasp them. Those are problems the ecosystem will have to grapple with (and I know the core team is aware of them). Though the "magic" at least is due more to weirdness and inversion of control than it is to actual complexity. Having a grasp on how they work, I feel like I wouldn't have too much trouble implementing a basic version of the same system myself, because the primitives are ultimately not very complicated I believe hooks are really good bones for building UIs, and I think they'll last because of it, even though the surface developer experience has some warts for now

andrewmcwatters 4y ago
I think it's sufficient to say that having been exposed to hundreds of thousands of lines of code across different industries and programming languages, I don't like React Hooks, and I don't even like them repurposing the word "hook" which is otherwise known as a trampoline in other programming language contexts. React Hooks, if anything should have just been called React Callback Queues. As for emotionally charged words, maybe it's not appropriate in the current zeitgeist to post without some degree first of self-censorship, but it's how I feel, so I'm going to say it. React Hooks were fanatically adopted, in my opinion. Side effects are a regular part of programming. I find it, thusly, infantilizing to hide those details. I wish people would stop this sort of thing, but if you want to say your part and that's how you feel, say it too. Edit: You've apparently even been downvoted for expressing this sentiment, which I hate on HN, because it's how you felt. I wish social sites wouldn't do this. No one should be able to invalidate that.

paulryanrogers 4y ago

> Class components remain supported, and are documented in the Legacy API section of the new site. So they're still not breaking backward compatibility. Looks like you don't have to refactor until you need something that's only hooks based.

nagonago 4y ago

> front ends independent of any of the existing frameworks that exist today, which I think is probably controversial Not sure controversial is the right word, in fact I think it is quite a common sentiment among developers, especially those that originally come from back-end. The only problem is finding a company that is willing to forgo the frameworks. They do exist though. Here's a short list of companies that use vanilla JavaScript, most notably GitHub and Netflix: https://gomakethings.com/companies-that-use-vanilla-js/ https://gomakethings.com/companies-that-use-vanilla-js/

fndex 4y ago

> I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though. Clojure and ClojureScript very much appreciate that sentiment. re-frame, a library for creating React apps with ClojureScript is rock solid, many years old, and still on version 1, meaning no breaking changes so far. 5 years old re-frame code still looks the same today.

koito17 4y ago
I use re-frame, but you cannot deny that class components being deprecated is going to be pure trouble for re-frame. Re-frame relies on the reagent library's Reaction interface. While re-frame does not depend on anything else in the reagent library, it is natural to use Reagent for your rendering. But reagent itself emits class components by default, since it predated hooks by several years. Now that class components are essentially deprecated in the documentation, and the fact that React 18 support is still an experimental feature in Reagent, people using ClojureScript and React today are in quite some trouble, especially since React is the only JS framework I know of that is compatible with functional programming. While reagent is able to emit function components, there is a performance penalty to this, since it employs some hacks in order to be compatible with both hooks and ratoms. Thankfully there are some projects that are attempting to bring modern React[1] and even bring the whole re-frame API alongside it.[2] Last weekend I decided to try out helix, refx, reitit, and shadow-cljs' lazy-loaded modules and managed to make a pretty nice demo app that uses essentially the re-frame API but it's all modern React and hooks, and the router was capable of lazily loading modules containing code of pages the user wanted to navigate to. [1] https://github.com/lilactown/helix https://github.com/lilactown/helix [2] https://github.com/ferdinand-beyer/refx https://github.com/ferdinand-beyer/refx
- askonomm 4y ago
  But Reagent supports functional components as well, with hooks and all. I don't see why I'd have to change an entire library because class components are being retired. I also very much like Hiccup, and so do many of us, because code is data and data is code, and Helix has decided not to support that.

Rapzid 4y ago

The docs are kinda poor on them IMHO. They don't approach the hooks from first principles. For example look up the useImperativeHandle hook docs. Use those to explain simple questions: > Why do you need this? > Why can't I just update the ref however I want! Look up forwardRef: > Why can't I just access ref as a prop? Further, everyone is trying to cram all logic into hooks and components. It's to the point of insanity. Look, React is so popular I know most are using it for throw away marketing sites and other low-tier shit (sorry y'all but you know it) but.. This architecture doesn't fly in large apps; ee b2b etc. React Router v6 seems to have no non-hook based APIs that aren't marked private!? They screwed the pooch on useNavigation; it causes unnecessary re-renders. Surprise surprise, but if they can't get it right...

jholman 4y ago
> React Router v6 seems to have no non-hook based APIs that aren't marked private!? They screwed the pooch on useNavigation; it causes unnecessary re-renders. Surprise surprise, but if they can't get it right... Whoa, you lost me here. React Router is no shining beacon of good API design. They've never done things well, just "well enough". I'm not saying RR is terrible, I'm not saying the RR devs should feel bad about how bad they are or something, I'm just saying that these guys are not the guys you want to point at for "if they can't get it right...". (Example of RR being not-so-amazing: Initially (v1? v2?) they required you to use attributes for the components that would render in a route, with no way to specify props short of making a custom component that wrapped the one you wanted. Then they added the ability to pass a function as an attribute, which let you specify props, so that was usable but clunky. Then, in yet a third version of the API (I think this is by v4?), we got the ability to use JSX in children to fully specify the components, which obviously was the right choice all along, it's literally the point of JSX. And again, I'm not saying I'm a better software engineer than those guys; I think I'd have got this one right but I'm sure I'd have screwed up a dozen other things.)
- Rapzid 4y ago
  I'm not going to argue with any of that but: * It is the de facto "official" community router solution * It's made by the same team as Remix..

robertoandred 4y ago

You call other devs “infants” but are unable to understand how hooks work. It’s really not complicated under the hood.

dxchester 4y ago

Agreed that investing in standards is always a good bet. But at the same time, we have so many web frameworks in part because what is spec'd in plain JavaScript/HTML/CSS is not quite high-level enough to be really be a productive foundation just on its own. Going all the way back to raw `Document.createElement` will come with its own special pain. With the WebComponents movement though, we are getting ever closer to being able to rely on native browser functionality for a good share of what frameworks set out to do. We're not all the way to bliss without frameworks, but for what it's worth here is my 481-byte library to support template interpolation with event binding in order to make WebComponents pretty workable mostly as-is: https://github.com/dchester/yhtml https://github.com/dchester/yhtml

reaperducer 4y ago

I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial Do it. Don't be afraid to, either. Over the years, I've put together a list of some big and VERY big companies whose web developers hand-code their web sites without assistance from the framework-du-jour. I recently learned about a new one for my list: A nine-figure household name tech company. The list is useful for when I'm in bars or developer meetups or coffee shops and someone who's only been putting together web sites for a few years starts preaching about how whatever shiny new thing they just learned about in junior college is the one and only way to do things.

gratitoad 4y ago
You tease. Dunno why you’d go out of your way to not name names, but it’s working: Who?

leros 4y ago

I'm usually the guy who is several versions behind on every library and I stick with what I know instead of exploring new features. I will say that React has been pretty pleasant to work with in regards to not forcing me to rewrite my code much. They're pretty good about keeping the old methods around our several major versions so you have plenty of time to make changes to your app or just keep doing things the old way.

atsjie 4y ago

> I want the decisions I make to last decades, not just a few years New to frontend?

FpUser 4y ago

I use some narrow scope libraries. Other than that I use plain JavaScript with Web Components. No frameworks. Saves me a bunch of time.

rwalle 4y ago

You probably should have a better understanding of how hooks work and why they are better before posting a long and meaningless rant like this. There are things that you complain when you are junior, but start to understand better and realize why people do certain things in a certain way when you get more experience and can look at things from a higher viewpoint.

FactoryReboot 4y ago

Hooks were the beginning of the end of my interest in React. Truly a terrible concept. Way to magic. Not overly aesthetic, not to mention the async programming techniques the js community has developed for over a decade all kinda break down with hooks. You can’t even just keep using class based as they have no way to consume hooks. Unit testing of hook based code is non existent IME. It’s some kinda funky E2E feeling test. React was my favorite framework before. It’s really a shame.

SPBesui 4y ago
> Unit testing of hook based code is non existent IME. It’s some kinda funky E2E feeling test. I’m guessing you’re referring to the fact that you can’t access component state like you can with class components. If so, that’s not required to do a unit test. That’s a sign that implementation details are leaking into your tests.
motoxpro 4y ago
They are just so simple to me that the "magic" never comes into play. Just a function that gets called when something in an array is different between renders.

bdangubic 4y ago

funniest thing to me is how many people identify themselves as "react person" or "angular person" and I am thinking "you'd be better off saying you are "cobol person"