|
IMO React itself is great mostly because it doesn't try to do everything for you however that also means the community solutions for the missing pieces are typically much lower quality in terms of dev experience. Agreed that most of the ecosystem is a mess.
|
# ? Apr 11, 2024 03:07 |
|
|
# ? May 4, 2024 13:11 |
|
I'm sure I'm wrong about this but at this point it doesn't seem like react even recommends just using react. The installation instructions takes you to one of three external options that happen to use react. Can you just get react and use it anymore?
|
# ? Apr 13, 2024 12:05 |
|
Nolgthorn posted:I'm sure I'm wrong about this but at this point it doesn't seem like react even recommends just using react. The installation instructions takes you to one of three external options that happen to use react. Absolutely though you probably want to use it via something like create-react-app to handle setting up the dev environnement et al
|
# ? Apr 13, 2024 12:43 |
|
A large part of modern react is supposed to be server components, which requires some additional build integration, so using a framework makes more sense in that case. The last official release was also 2 years ago. If you don't want server components, then you can still use it standalone just fine.
|
# ? Apr 13, 2024 14:36 |
|
I think it's interesting that modern tools have changed the foundations of web development to such a degree that almost everything at this point has been replaced by proprietary alternatives. Script for example replaces script, Link replaces a. Etc. We noted recently that none of our embeds were working when navigating. This is because of hyper optimizations that only server-rendered part of the page, then on the client would replace old with new. Which meant there was no page load which in some way caused the embed JavaScript not to run. The solution, after some investigation, was of course to build a new proprietary component. Is this a spiral away from html and common web practices and wisdom? Or is it progress. I guess it's progress but maybe I'm tired of what used to be. Nolgthorn fucked around with this message at 20:07 on Apr 13, 2024 |
# ? Apr 13, 2024 15:11 |
|
What's the state of offline web apps lately? I'd like to make something that can work offline or connected through the browser. I'm wondering if I should take the react native route to begin with, since I think the main use case will be on mobile. I'm a little reluctant to do that since I don't think messing with app stores and such is worth it for what I want to deliver, though.
|
# ? Apr 13, 2024 16:15 |
|
There are some rough edges sure, but I think people are really overstating how bad everything is in the React ecosystem. You can use the fancy new stuff or do it the way you've done it for 8 years, and it'll still work the same way. Only now you have stuff like react-query and suspense (which makes fetching data insanely easy to use and understand), typescript for everything (which makes your code more stable and improves DX a lot) and cool libs like zod, tailwind, zustand/jotai, react hook form, radix, shadcn, etc. all of which are imo very solid tools that solve real problems and have great DX. I guess I'm just saying it's not as bad as some people make it out to be, and you're getting all of it for free to boot
|
# ? Apr 13, 2024 17:12 |
|
Chas McGill posted:What's the state of offline web apps lately? I'd like to make something that can work offline or connected through the browser. I'm wondering if I should take the react native route to begin with, since I think the main use case will be on mobile. I'm a little reluctant to do that since I don't think messing with app stores and such is worth it for what I want to deliver, though. You can do it with a PWA, probably, it depends on your use case. Depends on what you are expecting by working offline and are fine with any iOS restrictions on PWA functionality.
|
# ? Apr 13, 2024 17:42 |
hey mom its 420 posted:You can use the fancy new stuff or do it the way you've done it for 8 years, and it'll still work the same way. Then you go look for a job and they ask for the fancy new stuff and oops, sorry.
|
|
# ? Apr 13, 2024 18:22 |
|
lunar detritus posted:Then you go look for a job and they ask for the fancy new stuff and oops, sorry. Right, and the pages router will be deprecated one day and you'll be stuck using older versions of Next, which is going to keep you stuck on an older version of React. Then one day you'll want to add a new feature and one of your dependencies is going to require the most up-to-date version of React, and suddenly the once optional API feels decisively less optional. A year ago I had to add a simple feature to a two year old Gatsby site. Not recommended.
|
# ? Apr 13, 2024 18:46 |
|
our next.js pages router app doesn't keep me up at night as much as our react+redux home-rolled no-framework app that is stuck on react 16 because we got stuck on redux-form (long abandoned) and after an incremental two year migration process we are almost fully replaced with react-hook-form we also still have to replace enzyme for RTL in that app so looking forward to finishing this upgrade in like 2027 part of software development is long-term maintenance. that's a good thing because if it wasn't more of us wouldn't have jobs
|
# ? Apr 13, 2024 18:51 |
|
lunar detritus posted:Then you go look for a job and they ask for the fancy new stuff and oops, sorry. yeah, but that's more like terrible hiring practices for some jobs, which is a shame. on the odd occasions when I have to interview people, I try to gauge their fundamentals instead of screening if they know all the cool new libs. imo you can quickly pick up all these new fancy techs (they're not that revolutionary really) if you get the job. if your potential employer doesn't share that sentiment, you can also just take a day or two to try them out and then just say you've used them and know them on the interview but yeah, probably the worst react apps to maintain have been the ones using redux and no framework. in my experience they almost always devolve into 3k line files with actions for each big model in the app, and actions just dispatch whatever other actions they want and have access to all state. and if you want to follow what's going on, good luck jumping between a few different react components, reducers and actions files just to figure out what happens when the user clicks a button.
|
# ? Apr 13, 2024 19:25 |
|
hey mom its 420 posted:but yeah, probably the worst react apps to maintain have been the ones using redux and no framework. in my experience they almost always devolve into 3k line files with actions for each big model in the app, and actions just dispatch whatever other actions they want and have access to all state. and if you want to follow what's going on, good luck jumping between a few different react components, reducers and actions files just to figure out what happens when the user clicks a button. my favorite antipattern that i've always seen in these kinds of vanilla-redux codebases is going all-in on unit testing. inevitably this means that the action creators, container components, and reducer logic are all tested separately with ZERO TESTING THAT ACTUALLY ENSURES THE CONTRACT BETWEEN THEM "look at how nice this is we can just use a mock redux store and mock out the i/o our action creators do " and then everyone gets surprised when the code hits production and some edge case produces a million "undefined is not an object" errors
|
# ? Apr 13, 2024 19:31 |
|
hey mom its 420 posted:yeah, but that's more like terrible hiring practices for some jobs, which is a shame. on the odd occasions when I have to interview people, I try to gauge their fundamentals instead of screening if they know all the cool new libs. imo you can quickly pick up all these new fancy techs (they're not that revolutionary really) if you get the job. if your potential employer doesn't share that sentiment, you can also just take a day or two to try them out and then just say you've used them and know them on the interview yea, the funny thing about the new crop of react stuff is that so much of it was a reaction to problems in big unstructured codebases. even if someone's been toiling away at a vanilla react/redux app for the last five years, they should immediately understand what a lot of the abstractions in these new frameworks are doing, usually a lot better than someone who used them from day 1
|
# ? Apr 13, 2024 19:35 |
|
haha, that seems par for the course alright. most of these codebases I've encountered didn't have types or tests. but yup, goes to show how that's a bad architecture since everything is an intricate and delicate web of dependencies between these layers, it doesn't matter if you can reason within the layers themselves, you'll always have to keep everything in your head when coding, or else risk these layers miscommunicating. what I like about just fetching (and POSTing) inside components (and using tailwind in them) and keeping minimal global state is that even if you have some sort of weird wtf problem, it's fine because it's encapsulated within the component so you can probably manage it. whenever I deal with our old codebase and see a vue component that hooks up to five different "stores" and reads state from them and dispatches actions I just groan
|
# ? Apr 13, 2024 19:39 |
|
I don't really get the white knighting of React in general. I've used it for seven or eight years but started incorporating Svelte into more projects since Next 13 came out. There's almost nothing I miss from React. This Josh Collinsworth piece probably comes across as pretty elitist but pretty well captures my sentiments to a tee: https://joshcollinsworth.com/blog/antiquated-react
|
# ? Apr 13, 2024 21:32 |
|
I started using react again after next 14 and it's actually good now I think. It used to be a bloated nightmare for a long long time now it seems to work pretty smoothly in my opinion. I am surprised. Probably getting rid of webpack cut down a lot.
|
# ? Apr 13, 2024 22:54 |
|
Actually I'll white knight a little bit more. Whatever has been going on since I left they're doing a great job over there. After writing an app using server components instead of two separate apps for the frontend and the backend I am pretty confident this is one of those events that completely changes the industry. I think about doing it the old way and I'm immediately put off by it. The things that have been holding the react world back aside from a killer feature like that is it's one of the only ones that doesn't have a compiler. Because of that you had to do a lot of the work that others did, manually. Like useEffect or all sorts of things like that, there's also performance concerns. But the people working on these things are going to make another big change by introducing the react compiler. I think react honestly has been dominating for the wrong reasons up until now, and very smart people noticed that and are turning it into something to celebrate before it's too late. Nolgthorn fucked around with this message at 23:39 on Apr 13, 2024 |
# ? Apr 13, 2024 23:16 |
|
If you call having a positive but measured opinion about something white knighting then sure I'm white knighting react lol. It has its own bag of warts and footguns, but think it's been consistently making really good innovations (the data flow, JSX, TS support, then hooks, suspense, server components and server actions) while remaining backwards compatible. contrast that with vue, which had to make a huge breaking change just to catch up to react in terms of TS support and better ergonomics with something that resembles hooks. we were thinking about migrating our terrible vue 2 app to vue 3 but then just decided to go switch to react because it was the same amount of work.
|
# ? Apr 14, 2024 07:51 |
|
I wrote a vue3 app immediately before my next14 app and I appreciate that I was using a lot less tooling while building the former. The next was just so clean and easy, I dunno. They're not doing everything wrong is my point that's for sure.
|
# ? Apr 14, 2024 10:43 |
|
It's just nearly all of these features you all are listing as positives in React exist in basically every other contemporary JS framework already. And some of the listed features, i.e. RSC, aren't even technically stable yet! (I know their implementation in Next is confusingly labeled "stable", but sure felt like anything but at Next 13's launch. And, might I add, horrible ergonomics IMO even assuming stability.) I know I'm fanboying for Svelte in particular, but I don't think React has any clear advantages over it. Svelte/SvelteKit has a much terser syntax, collocation of styles, native global state management, no virtual DOM, etc etc. I don't have to wait until an indeterminate future date for a compiler because it has always had a compiler.
|
# ? Apr 14, 2024 16:05 |
|
Svelte's typescript support is worse. Doing something simple like making a component that takes all the props of an HTML <button /> plus two or three custom props and maintaining that type safety basically wasn't possible last time I tried Svelte. In React it'scode:
React with Vite, React Router, and React Query is very very good. If you need SSR React with Remix is very very good. If you need SSG Astro with whatever view libraries you want is very good. It's a wealth of options. It's very unlikely you need to use Redux in 2024 but even if you do Redux Toolkit has made it 1000x more approachable than what we were stuck doing in 2016.
|
# ? Apr 14, 2024 18:12 |
|
Not sure when you were attempting to use Svelte, but I don't think it's currently challenging (dollar sign in "script" for forum-related reasons):code:
fsif fucked around with this message at 19:07 on Apr 14, 2024 |
# ? Apr 14, 2024 19:03 |
|
fsif posted:Not sure when you were attempting to use Svelte, but I don't think it's currently challenging (dollar sign in "script" for forum-related reasons): This was quite a while ago, so if they've added this I'm gonna have to give it a second look. The first thing I do on new projects is create my base components so it kinda put me off right away even though there was other stuff I really liked (like tick())
|
# ? Apr 14, 2024 22:22 |
|
Chas McGill posted:What's the state of offline web apps lately? I'd like to make something that can work offline or connected through the browser. I'm wondering if I should take the react native route to begin with, since I think the main use case will be on mobile. I'm a little reluctant to do that since I don't think messing with app stores and such is worth it for what I want to deliver, though. https://localfirstweb.dev/ I found this site last week. Might be a useful starting point.
|
# ? Apr 15, 2024 13:56 |
|
anyone have recs on what the defacto terminal emulator is these days? Looking at this now: https://www.npmjs.com/package/xterm
|
# ? Apr 26, 2024 18:48 |
|
does anyone here use module federation at work? As I understand it, the target audience is companies like facebook that have 100s of distributed developers working on the same website. At my work we have 10 front-end devs, and I'm trying to wrap my head around the problems is solves before going to war about why we don't need it. e: to be clear i'm talking about "micro front-ends" that are a bunch of little apps like the header, footer, and other pieces of a page that all come together at build time to form one big website teen phone cutie fucked around with this message at 23:13 on May 3, 2024 |
# ? May 3, 2024 23:11 |
|
teen phone cutie posted:does anyone here use module federation at work? The main benefit is that it lets you pull in code from multiple servers and endpoints while still de-duplicating identical dependencies between them, without requiring any special coordination of those different deployments ahead of time other than using module federation. If you don't have multiple separate servers/domains and frontend endpoints, it's just adding more complexity on top of what any bundler already does. I would personally assume that whoever's proposing to use it for a team of 10 is probably the same kind of resume-driven doofus who tries to use Kubernetes and Helm for absolutely everything.
|
# ? May 4, 2024 00:09 |
|
Roadie posted:I would personally assume that whoever's proposing to use it for a team of 10 is probably the same kind of resume-driven doofus who tries to use Kubernetes and Helm for absolutely everything. yeah this is where my head is at too. The problem here is that i'm in the minority vote, so I guess i'm about to start hooting and hollering
|
# ? May 4, 2024 00:29 |
|
|
# ? May 4, 2024 13:11 |
|
With ten developers you're still in "we can keep using the full stack monolith" territory, never mind microfrontends. Someone wants to go back to zirp times I guess
|
# ? May 4, 2024 09:04 |