14 ms·

Awesome release. I feel sorry though for someone getting into frontend dev now. > is a new hook to order Actions inside of a Transition with access to the sta

by demarq 2y ago

Awesome release. I feel sorry though for someone getting into frontend dev now. > is a new hook to order Actions inside of a Transition with access to the state of the action, and the pending state. It accepts a reducer that can call Actions, and the initial state used for first render. It also accepts an optional string that is used if the action is passed to a form action prop to support progressive enhancement in forms. I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start? EDIT: React is still an exceptional framework and this release is certainly an improvement. My criticism is more FE development in general not just React.

ChrisRR 2y ago
> Imagine you decided to start developing websites today, how do you even start I'm an embedded dev so I've so far removed from web dev, but recently started looking into learning web dev for some personal projects. My god what a mess. Any learning resource for a single topic , like javascript, Flask, CSS can't seem to stick to what it's trying to teach and insist that you start importing other libraries and frameworks. Most of the time they're not needed and the author just assumes that you understand this other library in order to continue following their examples So you google how to use that library, but the learning resources assume knowledge of a different library... When all the resources of just plain javascript and plain HTML/CSS. I don't want bootstrap or react, I just want to learn the fundamentals to build upon
azangru 2y ago
> Imagine you decided to start developing websites today, how do you even start? Not with React? Seriously, if you are starting developing websites today, the first thing you need to do is learn the web platform: html, css, javascript (probably typescript as well while you are at it), svg; and some basic server-side stuff. React is for when you get pretty comfy with those.
notapenny 2y ago
> Imagine you decided to start developing websites today, how do you even start? With HTML and CSS. And you don't touch JS until you understand the fundamentals of those. And only after those three do you touch a FE framework. I'm not even kidding either. Whether its React, Angular or any back-end driven templating, those things are all abstractions over fundamentals.
orliesaurus 2y ago
Maybe not with react
OtomotO 2y ago
My tip: you start by avoiding React altogether. It sounds bad, but if you can, do oldschool SSR with HTMX or the like. It's sooooo much better. I was paid to develop frontends in React for 4 years, I wrote my first website in 2005... I am currently migrating one client project from React to HMTX and it's sooooooooo incredibly much better. There are less bugs, less footguns with wrongly applied hooks... If you need to do CSR, use Solid or Vue, but don't do React. If you have no say in it: good luck!
- audessuscest 2y ago
  HTMX is certainly easier, but it's the worse if you want to actually learn FE
  - digdugdirk 2y ago
    As someone who isn't a web developer, what do you mean by that?
    - audessuscest 2y ago
      HTMX abstracts functionality into pseudo-HTML attributes, allowing you to handle tasks like event binding and DOM/content manipulation that would typically require JavaScript. By using HTMX, you primarily focus on learning HTML and its attributes, with minimal need to learn JavaScript.
  - baq 2y ago
    Not sure how to interpret what you're saying. HTMX allows you to learn the very basics: the HTML which is almost verbatim turned into DOM which the browser renders. It's the FE. Everything else is layers upon layers of abstraction which ultimately compile down to the DOM representation of HTML. ...or to put it differently, quoting HTMX's author: using HTTP to transfer HTML? How queer!
    - audessuscest 2y ago
      Sounds like you don't know anything about FE except htmx...
deadbabe 2y ago
Just start. I don’t get how people get so paralyzed of making the most optimal decisions all the time that they end up doing nothing or procrastinating by convincing themselves they need to learn some other basic framework instead.
- jfengel 2y ago
  It helps to know that the basic tutorials still apply. You don't need these advanced features. Certainly not for basic projects, and possibly not ever. After all, people successfully wrote React apps without it. One mark of a framework with a future is that it supports its past. A framework with a lot of breaking changes is one that is not mature, and may never be mature. Even with the substantial shift in React from classes to functions and hooks, old code still works. You probably don't want to start writing class-based React, so you want a tutorial written in the last 5 years, but those are hardly new and certainly not specific to React 19.
  - trgn 2y ago
    hooks was the beginning of the end imho. it replaced nicely encapsulated OO, with unmaintainable functional cruft. runtime footprint of react has vastly increased, and code has gotten harder to debug.
- rglullis 2y ago
  When I wanted to make a SPA for a project, I also wanted to avoid analysis paralysis. So I looked at Vue and React. Getting started with Vue was so much easier, I never looked back to React.
  - deadbabe 2y ago
    Do you ever wonder about the road not taken?
    - rglullis 2y ago
      Let me rephrase. I never looked back at React as the default option for any greenfield project. I still have to deal with React codebases, and every time I do I dread it.
iterateoften 2y ago
The rest of react still works. It’s not like it’s a primary entry point or required. Looks like an advanced feature.
pier25 2y ago
> I feel sorry though for someone getting into frontend dev now. Yeah. For the last decade or so frontend has felt like standing on shifting sands. In part it's the ecosystem and entangled deps but also because JS frameworks are really still figuring it out. A couple of years ago I was hoping we'd reach some sort of stable plateau but it just keeps going... "the DOM is slow we need a VDOM!" "the VDOM wasn't such a good idea... signals with fine-grained reactivity is really the solution for DOM udpates!" "oh wait but we now need a compiler!" "oh wait there's too much JS now... we better move stuff to the server and do SSR with full page hydration!" "maybe full page hydration wasn't such a good idea... we now need islands!" Etc. Don't get me wrong, each of these steps makes total sense. But we're getting into this uber complex solution that involves so much stuff across the whole stack... and it's not even clear to me that running JS in our servers was such a good idea to begin with.
- threatofrain 2y ago
  SSR was essential and the motivation was stuff like SEO. For people who care that was uncompromisable. For people who only care about SPA the conversation has been frozen for almost a decade; almost all the innovative fury has been on the SSR/MPA/hybrid side.
  - pier25 2y ago
    > For people who only care about SPA the conversation has been frozen for almost a decade I don't know, there's been a lot of stuff since 2014. In client-side React we've seen stuff like react-query, mobx, etc which weren't there a decade ago. Back in 2014 everyone was still using redux (ugh). Or Svelte and SolidJS which have brought massive improvements in performance and reducing JS with signals, compiler, etc.
    - acemarke 2y ago
      FWIW, both Redux and Mobx were invented in 2015.
      - 2y ago
klaussilveira 2y ago
It's hard not to use Next.js and React due to the insane amount of building blocks to built on top of. Not to mention design libraries and component libraries, such as Radix and shadcn. If you don't have the design skills, or the time, nothing beats that. Have you tried using v0 to generate a layout and a barebones application? It saves so much time. No more hunting for templates/themes, no more mocking.
- hi_hi 2y ago
  I went down this path very recently as a React newbie, for the exact reasons you stated. It looked like I'd be able to save a bunch of time, and I'm sure I did. But I also _spent_ a bunch of time as soon as I needed something slightly different to OOTB (or sometimes just wanted to understand how a thing worked better). At that point I ended up digging through Radix code, React library documentation where there were frequently multiple ways of doing the same thing and I had no idea which was "best". I had to delve into some of the more complex (to me, as a newbie) patterns like forwardRef. And this was all for a very trivial site/app that needed some form interactions. My takeaway at the end was, I'd learnt a bunch of new stuff, which was the point, but that was all workarounds for dealing with the complexities introduced by the tools which were meant to simplyfy my life. Perhaps for large projects with multiple devs, they bring efficiencies of scale. I think for my next solo project I'm trying Rails or Django with htmx.
  - klaussilveira 2y ago
    I understand that sentiment, although in an opposite away: for large projects with multiple devs, I'd prefer something like Rails or Django, precisely because they are battle-tested with a lot of official documentation. Things are done in one specific way and the team can just agree to whatever the framework recommends. And there are clear guidelines for pretty much everything. However, in solo projects, I want to spin something up quickly. I don't want to spend my scarce weekend time designing yet another date time picker. Or having to write hackish CSS to try and make whatever time picker library I chose to match the CSS of Bootstrap. And then everything falls apart because some other library does not fit into the overall style (looking at you DataTables). In React land, I don't have to worry about this. I just throw components together, link it to my API where the show real is, and call it a day. UIs are just UIs. They should be plug and play. So much time is wasted redesining data grids and data tables and pickers and filters for the 1000th time.
RandomThoughts3 2y ago
> I feel sorry though for someone getting into frontend dev now. I most certainly don’t. As someone who has mostly done low level coding and used to generally dislike my few interactions with web frontend development, I was extremely surprised when I picked up React a few years ago for a personal project. The whole thing feels like actual proper development. What a breath of fresh air compared to the situation before.
- ChrisRR 2y ago
  How did you learn? I'm an embedded dev and when I tried to learn basic web dev, all the resources were a mess of importing unnecessary libraries
  - RandomThoughts3 2y ago
    With the official doc. The react doc is well written. You have a quick start section, a good tutorial and the API is fully covered.
- typeofhuman 2y ago
  > personal project In professional projects with teams of developers contributing and PMs wanting feature flags, tracing, complex behavioral logic, it gets crazy.
  - yazaddaruvala 2y ago
    I’d say even more so for professional projects you’re better off with React. Been there and done that with and without. Junior (and Senior) devs fundamentally don’t read the docs. That and requirements churn are the problems. Given that, it ends up so much better with React.
vundercind 2y ago
I liked redux, but its vocabulary was the last thing core React should have adopted from it.
- acemarke 2y ago
  I maintain Redux, and I don't think Redux inspired this particular term usage (which came from the "Flux Architecture" pattern.) As far as I know this usage ultimately derives from HTML `<form action={}>`.
  - vundercind 2y ago
    Ah, different “action”, then? The presence of “reducer” had me assuming the action was also analogous. FWIW I liked Redux enough that I once half-reimplemented it for Brightscript so the UI guys would have something familiar to work with when they had to touch Roku apps. I always taught Redux initially using different terminology, though, because I found that most of my time learning it (which, mercifully, still wasn’t that long, because it’s small and pretty sensible) was figuring out the vocabulary (“do… do they just mean ‘event’? Well if so surely they’d write ‘event’, so I must be wrong…”)
    - acemarke 2y ago
      Hmm, that is a good point that `useActionState` accepts a reducer-like function (although I think it's async in this case?). And yeah, half of Redux's terminology is simply because the existing Flux Architecture libraries from the prior year all used those terms. There were several debates in the issues about whether to name them "actions", "events", or something else, and the conclusion was "let's just stick with the existing Flux terminology": - https://github.com/reduxjs/redux/issues/891#issuecomment-147666329 https://github.com/reduxjs/redux/issues/891#issuecomment-147... FWIW, as I've revamped the Redux docs over the years, I have specifically made sure we describe the "actions === events" aspect: - https://redux.js.org/style-guide/#model-actions-as-events-not-setters https://redux.js.org/style-guide/#model-actions-as-events-no... - https://redux.js.org/tutorials/essentials/part-1-overview-concepts#actions https://redux.js.org/tutorials/essentials/part-1-overview-co...
vouaobrasil 2y ago
I love website design for personal projects, but it is the least attractive of all development fields due to this complexity. I'm sure some people like it, but I found website dev a lot more fun 20 years ago...
- codr7 2y ago
  Same with backend dev imho.
  - codr7 2y ago
    What? You don't agree, or are you angry at me for reminding you?
meme3 2y ago
> Imagine you decided to start developing websites today, how do you even start? You learn vanilla HTML/CSS/JS (I think Mozilla has good courses on those). After making a few websites that way, you learn Svelte and you live happily ever after. Avoid React, NextJS at all cost especially since many of these new frameworks actively try to screw over new developers with PaaS.
- can16358p 2y ago
  I get NextJS but how does React itself try to screw devs with PaaS?
  - mhnthrow 2y ago
    The Getting Started docs recommend against using vanilla React and nudge you towards NextJS and similar frameworks because you're gonna end up needing that stuff eventually https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project So new projects have to actively not follow the recommended approach in the docs if they want to use vanilla React.
- billti 2y ago
  It's funny to think back now that JSX had such a strong negative reaction on launch. That's the one thing from React I love - having a declarative and strongly typed markup for HTML in my JS/TS code. I think React peaked with hooks around 2019. I write most of my front-end with the smallest 'React-like' library possible (Preact) using only functional components, and with as little 'magic' from useEffect etc. as possible. I like to stay close to 'raw' HTML/CSS/JS when possible, but the web platform APIs are just a little to clunky and verbose for me without the JSX abstraction.
  - breadwinner 2y ago
    You can use JSX syntax without using React. You can stay close to raw HTML/CSS/JS too. See here: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder And here's a complete app example: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie...
nailer 2y ago
I'd hoped this release would have added a compiler and drastically simplified the syntax to something close to a modern framework. I know React is eventually going to do that, but it feels like React has been drowning in overly complex DX for at least the last 5 years.
- acemarke 2y ago
  The React Compiler is currently in beta: https://react.dev/blog/2024/10/21/react-compiler-beta-release https://react.dev/blog/2024/10/21/react-compiler-beta-releas... That said, it doesn't change the APIs included in React itself, or the overall usage patterns. Ultimately it rewrites your component code to add a lot of conditional comparisons to see if props or state values changed, and uses that to trigger React's existing rendering optimization behaviors. Long-term, I expect that the React Compiler _will_ result in a significant change in the DX for using React. React's default behavior has always been "re-render recursively regardless of props changes" [0], but people often assume it's "only re-render the child if the props changed". React Compiler actually makes flips React's default behavior to make that a reality. [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/#standard-render-behavior https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
umvi 2y ago
Yeah I'm getting kubernetes vibes from all the abstractions mentioned in a single sentence. I'm sure the abstractions are needed and/or powerful to accomplish React's goals, but it's just a bunch of extra stuff added to the learning curve which makes it harder for outsiders to understand and contribute to the code.
mattgreenrocks 2y ago
It's insane that the total complexity of the ecosystem has only grown in the past decade, despite the amount of time and tools trying to contain it. I have a hard time seeing that expectations rose accordingly alongside this. I'm half-convinced it is tolerated as a collective subconscious gatekeeping/total employment mechanism. My response has been to avoid SPAs as much as possible. YAGNI! Just use boring forms and server responses. Some component libraries can be server-rendered, minimizing the JS payload while giving you some primitives to build off of. Components are a really nice abstraction even in a pure server context. You can contain the goopy Tailwind code a bit. It's not all bad. Astro seems pretty nice so far!
Stevvo 2y ago
"My criticism is more FE development in general not just React" No, it is not. Your criticism is very specific to React.
ww520 2y ago
Why is state management so complicate in React?
- CharlieDigital 2y ago
  React is the only major FE lib/framework that basically re-renders each (affected) component and sub-tree on update cycles. The model they've chosen is the opposite of what one would intuit and because of this model, it is necessary to manage state a bit differently in React compared to Vue or Svelte.
  - WesleyJohnson 2y ago
    I, for one, would intuit that exact process flow. If my UI is a function of my state, I expect state changes to re-render my UI. How else would you handle it, except for imperatively? This is genuine question; I've not used Vue or Svelte.
    - CharlieDigital 2y ago
      It re-invokes the entire render function of the component so that the state in the component (meaning not externalized to a hook or declared outside of the component) is effectively wiped out. Vue and Svelte don't work that way. In a Vue SFC, this is fine: <script setup> let counter = 0 <-- This code only runs once watch (someRef, () => { <-- Only this code runs when someRef changes counter++ console.log(counter) }) const fn = () => { ... } <-- Normal functions are stable function fn2 () { ... } <-- Stable as well </script> Basically, it behaves like you would expect normal JS closures to behave because the `setup` function is invoked only once. When `someRef` changes, only the `watch` function is executed (this is also why Vue and Svelte perform better because they can execute a smaller subset of code on updates). JS and DOM itself work with the same conceptual model, right? <button onclick="handler()">...</button> <script> let counter = 0 <-- Allocated once function handler() { } <-- Only this code is executed const fn = () => { ... } <-- Allocated once </script> In React, this (obviously trivial example) doesn't work: export const App = () => { let counter = 0 <-- New allocation on each render const fn = () => { ... } <-- New allocation on each render // ... } Because the entire `App()` function gets invoked again. So you have to use hooks to move state out of the path of the component function because the entire component function is re-invoked. Imagine if React, instead of invoking the entire `App()` function, only invoked the code affected by the change as captured in the dependency array. That's how Vue and Svelte work; the same way that a handler function via `addEventListener()` only executes the designated handler function. React does not work this way. Think hard about that and how React is conceptually opposite of how events work in DOM itself. This difference in design means that in Vue, there is -- in practice -- almost never a need to do manual memoization and never really a thought of "where should I put this"? It might seem obvious here, right? if `fn` has no dependencies on the component state, then it can just be moved out of the `App()` function. But this is a common mistake and it ends up with excess stack allocations (also why React is generally the poorest performer when it comes to memory usage). React's model is a bit of an outlier for UIs which generally assume state encapsulated by a component is stable. React says "no, the component function is going to be invoked on every change so you cannot have state in the component." A different way to think about this is to go look at game engines or desktop UI frameworks which render stateful objects onto a canvas and see how many game engines or UI engines assume that your object is recreated each time. This is certainly true of the underlying render buffer of the graphics card, right? But generally the developer builds on top of stateful abstractions. React has, in fact, moved the complexity onto the developer to properly place and manage state (while not being faster nor more memory efficient than Vue or Svelte). I believe that a lot of React's expanding complexity flows from this design decision to model inherently stateful UIs in a "pretend everything is a stateless function" way because it is fundamentally playing opposite day against the underlying JavaScript and DOM.
o_m 2y ago
The attitude I've heard from many frontend devs is that they acknowledge that AI will do most of the work. v0 and Bolt will do most of the work. Not because it does a better job, but because there will be a race to the bottom where employers don't want to pay for anything else. So this might mainly be a problem for the AI to learn.
markandrewj 2y ago
I generally feel the opposite way. React was changing every few weeks when I started using it, the docs and API are much more stable and consistent now. In general web standards are more stable then ever also. People younger then myself won't have learn 100s of layout hacks to get their pages displaying properly cross browser, or sometimes even in just one browser. This is just my perspective, although I also understand JavaScript fatigue, I feel it is actually one of the best times to start learning.
lukebuehler 2y ago
It’s not that bad. I started basically from zero about a year ago, have been doing react maybe 20% of my work time since then, and I would say I now understand and can use most concepts/features in react.
Cthulhu_ 2y ago
I'm trying to parse that sentence and as it turns out... probably nothing is relevant to me that just writes end user front-end stuff. Most React development is in the backend / rendering or for specialists that write libraries, feels like.
pjmlp 2y ago
My main approach, when it is something I control, I stay as much on .NET and Java solutions for Web development, with minimal JavaScript. When not, I focus on backend and devops instead. Although some SaaS products make our life harder, with React only SDKs.
AlwaysRock 2y ago
> Imagine you decided to start developing websites today, how do you even start? You'd slap together a Jenkins/Jekyll site and host it on github for free. It's easier now to set up a website than ever. But yeah that React sentence is pretty difficult to gronk.
thorum 2y ago
> I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start? Easy: By not using that optional feature. If you’re like 99% of developers you really don’t need stuff like that until your app reaches a certain stage of growth, if ever - and React doesn’t force it on you.
- aylmao 2y ago
  Huge +1 to this. Looking at python 3.13 release notes [1]: > asyncio.as_completed() now returns an object that is both an asynchronous iterator and a plain iterator of awaitables. The awaitables yielded by asynchronous iteration include original task or future objects that were passed in, making it easier to associate results with the tasks being completed. (Contributed by Justin Arthur in gh-77714.) "I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing python scripts today, how do you even start?" [1] https://docs.python.org/3/whatsnew/3.13.html#asyncio https://docs.python.org/3/whatsnew/3.13.html#asyncio
  - kovrik 2y ago
    Not sure if those are the same though? Async, await, iterators, futures etc. are pretty much standard constructs in almost all programming languages / concurrency frameworks. Whereas Actions, Transitions, Pending State, Reducers etc. are React-specific idiosyncrasies. I guess that's the main issue people have with React, when you learn it you have to spend so much time to learn all these React-specific constructs and idiosyncrasies that are not transferable anywhere else.
    - aylmao 2y ago
      When one is learning to program, one doesn't jump straight into learning coroutine management. Similarly, wether they are React-specific idiosyncrasies or not, one shouldn't assume people need to jump straight into Actions, Transitions, etc when first learning React.
- yawaramin 2y ago
rdsubhas 2y ago
In my experience, React was an interesting take, but it had certain flawed red-flags that were ignored from the start. I wrote posts about it, but was doomed as a skeptic. The original fundamental premise: let's do one-way binding with virtual DOM, re-render, diff – did not make fundamental sense. Double the memory in browser, complete re-render & diff for every interaction? The answer was: Make it reliable, then make it fast. Now, it's full of hacked-up constructs attempting to make it fast – but it's neither fast nor reliable. At least with honest two-way binding frameworks, fast is guaranteed, and reliability comes from my experience. With React it's just a mess. I pity all the frontend engineers who's first intro has been with React, because unlearning is much more difficult than learning. Being mindful of the never-ending-nirvana frontend spirit of churn, and after doing web development in VBScript, JS, JQuery, Mootools, Applets, Actionscript, YUI/Ext/Sencha, Backbone, Knockout, Angular1, Angular2, React, Vue1 – I'd say try Flutter. It's genuinely a breath of fresh air. Except... Dart. If only Flutter was in Typescript it might have been a bit closer to nirvana. The Dart part is still keeping the frontend spirit of churn alive.
- simplify 2y ago
  Virtual DOM is not inherently an issue. Many libraries use it and are much faster than React. The main issue is React forces you to tell it which components to re-render. This causes a bloat of ceremony that makes it endlessly annoying (in comparison to global redraws) to write in.
  - lyu07282 2y ago
    > React forces you to tell it which components to re-render That's a really weird statement, do you keep your application state in a mutable data structure instead of immutable? Do you know what a pure component is?
    - the_gipsy 2y ago
      So you don't use hooks at all? The one great unification of state management that comes included?
- 2y ago
soulofmischief 2y ago
Just use mithril and never look back. You can learn the API in one day and move on with your life creating compact and performant apps. React is unbelievably overengineered, classic case of creating solutions to self-invented problems.
rglover 2y ago
Shameless self-promotion, but anyone reading this who is just getting into front-end and doesn't want to deal with that ^, check out Joystick [1]. It's a full-stack JS framework with its own components library that uses plain HTML, CSS, and JS (and has dead-simple, obvious APIs for implementing more advanced logic like state and event handlers). It's a logical next step from learning web dev fundamentals to building full apps. [1] https://cheatcode.co/joystick https://cheatcode.co/joystick
- chrismorgan 2y ago
  Judging by your front page demo, your component stack is built on simple string concatenation (via untagged template strings), with nothing about escaping of any form, for any format. That's a very bad sign, you're just begging for injection attacks. There's absolutely no chance of me using a framework with a demo like that, even if it actually had decent tools for handling the situation.
  - rglover 2y ago
    That's all mitigated on the server. You also have access to additional escaping tools for handling user-generated data on the server, too.
    - chrismorgan 2y ago
      > That's all mitigated on the server. How? Please be specific, because unless you're altering the source (which I'd be very unpleasantly shocked by), your use of untagged template strings makes it fundamentally impossible to mitigate such stuff, short of forbidding characters like & and < and " from data, which would be insanity. You're mixing template and data willy-nilly.
      - rglover 2y ago
        The source isn't altered (I take the component HTML, parse it, build it into a DOM, and render it). The data from the API is compiled separately (where sanitization can happen if you have untrusted user data). The two are combined together during SSR by passing the sanitized data to the component. Developer controlled code at the component-level is assumed trusted, however, there are three mechanisms for handling escaping/sanitizing on the server: 1. There are helpers built in to the API (you can conditionally enable sanitization depending on need) to handle sanitization and helper functions built-in to the server-side to do one-off escaping/sanitization for HTML. 2. Query params are sanitized automatically to prevent injection. 3. To prevent unescaped HTML in data from breaking renders, I base64 encode it before sending it to the browser. This approach to escaping is by design as some use cases call for sanitization (they're rendering user-generated data) while others do not. You're welcome to audit the source and see if I missed something or make suggestions on improvements.
shams93 2y ago
htmx and python
SkyMarshal 2y ago
> Imagine you decided to start developing websites today, how do you even start? Probably with something simpler like Alpine.js, or even JQuery. No beginner is going to be building the kind of web app that requires such a heavyweight framework like React. Don't bother with it until you know you need it.
johannes1234321 2y ago
Reading changelogs certainly isn't the right place to start learning. A changelogs is a quite condensed view on changes from an implementation point of view. Some projects are good in promoting highlights from user perspective, but still a tutorial and manual are better places to start.
mu53 2y ago
I think its all tech jobs at this point. People used to be a good sysadmin with just some bash, but now there are so many complex frameworks and best practices. The quality expected of apps over the last 20 years has skyrocketed, and the tools to handle those requirements have gotten increasingly complex.
lmm 2y ago
The HN hate boner for React is unreal. They've added a new hook to allow you to provide a more optimized implementation for a particular special case. It sounds like it's in the obvious place to find it if you need it, and does what you would want it to do. Why would you care about this unless you needed it? And if you needed it you'd know what it does.
- reshlo 2y ago
  > And if you needed it you’d know what it does. Why would that be true? Often people don’t know what they need to solve a particular problem.
  - lmm 2y ago
    I meant the description quoted is the right description for someone who needs this to understand.
sergiomattei 2y ago
Why would a web dev learner need to know about this feature?
dcre 2y ago
I don’t think beginners are beginning by reading the release notes. Note that the wonderful learning guide doesn’t even discuss these advanced hooks. https://react.dev/learn https://react.dev/learn Even the reference section of the site makes clear how far down the priority list the advanced hooks are. https://react.dev/reference/react/hooks https://react.dev/reference/react/hooks
brundolf 2y ago
React has a dizzying number of concepts now. I don't love the direction it's taken the past few years; it used to be a really minimal and elegant core, but these days it's hard to keep up with all the abstractions
anonzzzies 2y ago
I read the updates and I know we will never need this stuff and we will never use it. However, we cannot not update to it for the clients that use it as other libraries will start using it. It is why we left react; this churn is just mental for things that have no value to most dev users. Even if it has potential value, many will just skip it as so many things from previous versions are not used in many codebases we see (and we see a lot in different large corp repositories).
paxys 2y ago
By that logic beginners can never get into programming (or really any other field) because there's some complexity on the deep end.
zild3d 2y ago
> I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start? You start where the docs say to start, https://react.dev/learn https://react.dev/learn which wouldn't be mentioning this advanced feature, just like pretty much any tech. Reading postgres, python, etc release notes will have a bunch of scary sounding new features to a beginner, but those won't be making their way into the "Get started" section

by demarq 2y ago

ChrisRR 2y ago

> Imagine you decided to start developing websites today, how do you even start I'm an embedded dev so I've so far removed from web dev, but recently started looking into learning web dev for some personal projects. My god what a mess. Any learning resource for a single topic , like javascript, Flask, CSS can't seem to stick to what it's trying to teach and insist that you start importing other libraries and frameworks. Most of the time they're not needed and the author just assumes that you understand this other library in order to continue following their examples So you google how to use that library, but the learning resources assume knowledge of a different library... When all the resources of just plain javascript and plain HTML/CSS. I don't want bootstrap or react, I just want to learn the fundamentals to build upon

azangru 2y ago

> Imagine you decided to start developing websites today, how do you even start? Not with React? Seriously, if you are starting developing websites today, the first thing you need to do is learn the web platform: html, css, javascript (probably typescript as well while you are at it), svg; and some basic server-side stuff. React is for when you get pretty comfy with those.

notapenny 2y ago

> Imagine you decided to start developing websites today, how do you even start? With HTML and CSS. And you don't touch JS until you understand the fundamentals of those. And only after those three do you touch a FE framework. I'm not even kidding either. Whether its React, Angular or any back-end driven templating, those things are all abstractions over fundamentals.

orliesaurus 2y ago

Maybe not with react

OtomotO 2y ago

My tip: you start by avoiding React altogether. It sounds bad, but if you can, do oldschool SSR with HTMX or the like. It's sooooo much better. I was paid to develop frontends in React for 4 years, I wrote my first website in 2005... I am currently migrating one client project from React to HMTX and it's sooooooooo incredibly much better. There are less bugs, less footguns with wrongly applied hooks... If you need to do CSR, use Solid or Vue, but don't do React. If you have no say in it: good luck!

audessuscest 2y ago
HTMX is certainly easier, but it's the worse if you want to actually learn FE
- digdugdirk 2y ago
  As someone who isn't a web developer, what do you mean by that?
  - audessuscest 2y ago
    HTMX abstracts functionality into pseudo-HTML attributes, allowing you to handle tasks like event binding and DOM/content manipulation that would typically require JavaScript. By using HTMX, you primarily focus on learning HTML and its attributes, with minimal need to learn JavaScript.
- baq 2y ago
  Not sure how to interpret what you're saying. HTMX allows you to learn the very basics: the HTML which is almost verbatim turned into DOM which the browser renders. It's the FE. Everything else is layers upon layers of abstraction which ultimately compile down to the DOM representation of HTML. ...or to put it differently, quoting HTMX's author: using HTTP to transfer HTML? How queer!
  - audessuscest 2y ago
    Sounds like you don't know anything about FE except htmx...

deadbabe 2y ago

Just start. I don’t get how people get so paralyzed of making the most optimal decisions all the time that they end up doing nothing or procrastinating by convincing themselves they need to learn some other basic framework instead.

jfengel 2y ago
It helps to know that the basic tutorials still apply. You don't need these advanced features. Certainly not for basic projects, and possibly not ever. After all, people successfully wrote React apps without it. One mark of a framework with a future is that it supports its past. A framework with a lot of breaking changes is one that is not mature, and may never be mature. Even with the substantial shift in React from classes to functions and hooks, old code still works. You probably don't want to start writing class-based React, so you want a tutorial written in the last 5 years, but those are hardly new and certainly not specific to React 19.
- trgn 2y ago
  hooks was the beginning of the end imho. it replaced nicely encapsulated OO, with unmaintainable functional cruft. runtime footprint of react has vastly increased, and code has gotten harder to debug.
rglullis 2y ago
When I wanted to make a SPA for a project, I also wanted to avoid analysis paralysis. So I looked at Vue and React. Getting started with Vue was so much easier, I never looked back to React.
- deadbabe 2y ago
  Do you ever wonder about the road not taken?
  - rglullis 2y ago
    Let me rephrase. I never looked back at React as the default option for any greenfield project. I still have to deal with React codebases, and every time I do I dread it.

iterateoften 2y ago

The rest of react still works. It’s not like it’s a primary entry point or required. Looks like an advanced feature.

pier25 2y ago

> I feel sorry though for someone getting into frontend dev now. Yeah. For the last decade or so frontend has felt like standing on shifting sands. In part it's the ecosystem and entangled deps but also because JS frameworks are really still figuring it out. A couple of years ago I was hoping we'd reach some sort of stable plateau but it just keeps going... "the DOM is slow we need a VDOM!" "the VDOM wasn't such a good idea... signals with fine-grained reactivity is really the solution for DOM udpates!" "oh wait but we now need a compiler!" "oh wait there's too much JS now... we better move stuff to the server and do SSR with full page hydration!" "maybe full page hydration wasn't such a good idea... we now need islands!" Etc. Don't get me wrong, each of these steps makes total sense. But we're getting into this uber complex solution that involves so much stuff across the whole stack... and it's not even clear to me that running JS in our servers was such a good idea to begin with.

threatofrain 2y ago
SSR was essential and the motivation was stuff like SEO. For people who care that was uncompromisable. For people who only care about SPA the conversation has been frozen for almost a decade; almost all the innovative fury has been on the SSR/MPA/hybrid side.
- pier25 2y ago
  > For people who only care about SPA the conversation has been frozen for almost a decade I don't know, there's been a lot of stuff since 2014. In client-side React we've seen stuff like react-query, mobx, etc which weren't there a decade ago. Back in 2014 everyone was still using redux (ugh). Or Svelte and SolidJS which have brought massive improvements in performance and reducing JS with signals, compiler, etc.
  - acemarke 2y ago
    FWIW, both Redux and Mobx were invented in 2015.
    - 2y ago

klaussilveira 2y ago

It's hard not to use Next.js and React due to the insane amount of building blocks to built on top of. Not to mention design libraries and component libraries, such as Radix and shadcn. If you don't have the design skills, or the time, nothing beats that. Have you tried using v0 to generate a layout and a barebones application? It saves so much time. No more hunting for templates/themes, no more mocking.

hi_hi 2y ago
I went down this path very recently as a React newbie, for the exact reasons you stated. It looked like I'd be able to save a bunch of time, and I'm sure I did. But I also _spent_ a bunch of time as soon as I needed something slightly different to OOTB (or sometimes just wanted to understand how a thing worked better). At that point I ended up digging through Radix code, React library documentation where there were frequently multiple ways of doing the same thing and I had no idea which was "best". I had to delve into some of the more complex (to me, as a newbie) patterns like forwardRef. And this was all for a very trivial site/app that needed some form interactions. My takeaway at the end was, I'd learnt a bunch of new stuff, which was the point, but that was all workarounds for dealing with the complexities introduced by the tools which were meant to simplyfy my life. Perhaps for large projects with multiple devs, they bring efficiencies of scale. I think for my next solo project I'm trying Rails or Django with htmx.
- klaussilveira 2y ago
  I understand that sentiment, although in an opposite away: for large projects with multiple devs, I'd prefer something like Rails or Django, precisely because they are battle-tested with a lot of official documentation. Things are done in one specific way and the team can just agree to whatever the framework recommends. And there are clear guidelines for pretty much everything. However, in solo projects, I want to spin something up quickly. I don't want to spend my scarce weekend time designing yet another date time picker. Or having to write hackish CSS to try and make whatever time picker library I chose to match the CSS of Bootstrap. And then everything falls apart because some other library does not fit into the overall style (looking at you DataTables). In React land, I don't have to worry about this. I just throw components together, link it to my API where the show real is, and call it a day. UIs are just UIs. They should be plug and play. So much time is wasted redesining data grids and data tables and pickers and filters for the 1000th time.

RandomThoughts3 2y ago

> I feel sorry though for someone getting into frontend dev now. I most certainly don’t. As someone who has mostly done low level coding and used to generally dislike my few interactions with web frontend development, I was extremely surprised when I picked up React a few years ago for a personal project. The whole thing feels like actual proper development. What a breath of fresh air compared to the situation before.

ChrisRR 2y ago
How did you learn? I'm an embedded dev and when I tried to learn basic web dev, all the resources were a mess of importing unnecessary libraries
- RandomThoughts3 2y ago
  With the official doc. The react doc is well written. You have a quick start section, a good tutorial and the API is fully covered.
typeofhuman 2y ago
> personal project In professional projects with teams of developers contributing and PMs wanting feature flags, tracing, complex behavioral logic, it gets crazy.
- yazaddaruvala 2y ago
  I’d say even more so for professional projects you’re better off with React. Been there and done that with and without. Junior (and Senior) devs fundamentally don’t read the docs. That and requirements churn are the problems. Given that, it ends up so much better with React.

vundercind 2y ago

I liked redux, but its vocabulary was the last thing core React should have adopted from it.

acemarke 2y ago
I maintain Redux, and I don't think Redux inspired this particular term usage (which came from the "Flux Architecture" pattern.) As far as I know this usage ultimately derives from HTML `<form action={}>`.
- vundercind 2y ago
  Ah, different “action”, then? The presence of “reducer” had me assuming the action was also analogous. FWIW I liked Redux enough that I once half-reimplemented it for Brightscript so the UI guys would have something familiar to work with when they had to touch Roku apps. I always taught Redux initially using different terminology, though, because I found that most of my time learning it (which, mercifully, still wasn’t that long, because it’s small and pretty sensible) was figuring out the vocabulary (“do… do they just mean ‘event’? Well if so surely they’d write ‘event’, so I must be wrong…”)
  - acemarke 2y ago
    Hmm, that is a good point that `useActionState` accepts a reducer-like function (although I think it's async in this case?). And yeah, half of Redux's terminology is simply because the existing Flux Architecture libraries from the prior year all used those terms. There were several debates in the issues about whether to name them "actions", "events", or something else, and the conclusion was "let's just stick with the existing Flux terminology": - https://github.com/reduxjs/redux/issues/891#issuecomment-147666329 https://github.com/reduxjs/redux/issues/891#issuecomment-147... FWIW, as I've revamped the Redux docs over the years, I have specifically made sure we describe the "actions === events" aspect: - https://redux.js.org/style-guide/#model-actions-as-events-not-setters https://redux.js.org/style-guide/#model-actions-as-events-no... - https://redux.js.org/tutorials/essentials/part-1-overview-concepts#actions https://redux.js.org/tutorials/essentials/part-1-overview-co...

vouaobrasil 2y ago

I love website design for personal projects, but it is the least attractive of all development fields due to this complexity. I'm sure some people like it, but I found website dev a lot more fun 20 years ago...

codr7 2y ago
Same with backend dev imho.
- codr7 2y ago
  What? You don't agree, or are you angry at me for reminding you?

meme3 2y ago

> Imagine you decided to start developing websites today, how do you even start? You learn vanilla HTML/CSS/JS (I think Mozilla has good courses on those). After making a few websites that way, you learn Svelte and you live happily ever after. Avoid React, NextJS at all cost especially since many of these new frameworks actively try to screw over new developers with PaaS.

can16358p 2y ago
I get NextJS but how does React itself try to screw devs with PaaS?
- mhnthrow 2y ago
  The Getting Started docs recommend against using vanilla React and nudge you towards NextJS and similar frameworks because you're gonna end up needing that stuff eventually https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project So new projects have to actively not follow the recommended approach in the docs if they want to use vanilla React.
billti 2y ago
It's funny to think back now that JSX had such a strong negative reaction on launch. That's the one thing from React I love - having a declarative and strongly typed markup for HTML in my JS/TS code. I think React peaked with hooks around 2019. I write most of my front-end with the smallest 'React-like' library possible (Preact) using only functional components, and with as little 'magic' from useEffect etc. as possible. I like to stay close to 'raw' HTML/CSS/JS when possible, but the web platform APIs are just a little to clunky and verbose for me without the JSX abstraction.
- breadwinner 2y ago
  You can use JSX syntax without using React. You can stay close to raw HTML/CSS/JS too. See here: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder And here's a complete app example: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie...

nailer 2y ago

I'd hoped this release would have added a compiler and drastically simplified the syntax to something close to a modern framework. I know React is eventually going to do that, but it feels like React has been drowning in overly complex DX for at least the last 5 years.

acemarke 2y ago
The React Compiler is currently in beta: https://react.dev/blog/2024/10/21/react-compiler-beta-release https://react.dev/blog/2024/10/21/react-compiler-beta-releas... That said, it doesn't change the APIs included in React itself, or the overall usage patterns. Ultimately it rewrites your component code to add a lot of conditional comparisons to see if props or state values changed, and uses that to trigger React's existing rendering optimization behaviors. Long-term, I expect that the React Compiler _will_ result in a significant change in the DX for using React. React's default behavior has always been "re-render recursively regardless of props changes" [0], but people often assume it's "only re-render the child if the props changed". React Compiler actually makes flips React's default behavior to make that a reality. [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/#standard-render-behavior https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

umvi 2y ago

Yeah I'm getting kubernetes vibes from all the abstractions mentioned in a single sentence. I'm sure the abstractions are needed and/or powerful to accomplish React's goals, but it's just a bunch of extra stuff added to the learning curve which makes it harder for outsiders to understand and contribute to the code.

mattgreenrocks 2y ago

It's insane that the total complexity of the ecosystem has only grown in the past decade, despite the amount of time and tools trying to contain it. I have a hard time seeing that expectations rose accordingly alongside this. I'm half-convinced it is tolerated as a collective subconscious gatekeeping/total employment mechanism. My response has been to avoid SPAs as much as possible. YAGNI! Just use boring forms and server responses. Some component libraries can be server-rendered, minimizing the JS payload while giving you some primitives to build off of. Components are a really nice abstraction even in a pure server context. You can contain the goopy Tailwind code a bit. It's not all bad. Astro seems pretty nice so far!

Stevvo 2y ago

"My criticism is more FE development in general not just React" No, it is not. Your criticism is very specific to React.

ww520 2y ago

Why is state management so complicate in React?

CharlieDigital 2y ago
React is the only major FE lib/framework that basically re-renders each (affected) component and sub-tree on update cycles. The model they've chosen is the opposite of what one would intuit and because of this model, it is necessary to manage state a bit differently in React compared to Vue or Svelte.
- WesleyJohnson 2y ago
  I, for one, would intuit that exact process flow. If my UI is a function of my state, I expect state changes to re-render my UI. How else would you handle it, except for imperatively? This is genuine question; I've not used Vue or Svelte.
  - CharlieDigital 2y ago
    It re-invokes the entire render function of the component so that the state in the component (meaning not externalized to a hook or declared outside of the component) is effectively wiped out. Vue and Svelte don't work that way. In a Vue SFC, this is fine: <script setup> let counter = 0 <-- This code only runs once watch (someRef, () => { <-- Only this code runs when someRef changes counter++ console.log(counter) }) const fn = () => { ... } <-- Normal functions are stable function fn2 () { ... } <-- Stable as well </script> Basically, it behaves like you would expect normal JS closures to behave because the `setup` function is invoked only once. When `someRef` changes, only the `watch` function is executed (this is also why Vue and Svelte perform better because they can execute a smaller subset of code on updates). JS and DOM itself work with the same conceptual model, right? <button onclick="handler()">...</button> <script> let counter = 0 <-- Allocated once function handler() { } <-- Only this code is executed const fn = () => { ... } <-- Allocated once </script> In React, this (obviously trivial example) doesn't work: export const App = () => { let counter = 0 <-- New allocation on each render const fn = () => { ... } <-- New allocation on each render // ... } Because the entire `App()` function gets invoked again. So you have to use hooks to move state out of the path of the component function because the entire component function is re-invoked. Imagine if React, instead of invoking the entire `App()` function, only invoked the code affected by the change as captured in the dependency array. That's how Vue and Svelte work; the same way that a handler function via `addEventListener()` only executes the designated handler function. React does not work this way. Think hard about that and how React is conceptually opposite of how events work in DOM itself. This difference in design means that in Vue, there is -- in practice -- almost never a need to do manual memoization and never really a thought of "where should I put this"? It might seem obvious here, right? if `fn` has no dependencies on the component state, then it can just be moved out of the `App()` function. But this is a common mistake and it ends up with excess stack allocations (also why React is generally the poorest performer when it comes to memory usage). React's model is a bit of an outlier for UIs which generally assume state encapsulated by a component is stable. React says "no, the component function is going to be invoked on every change so you cannot have state in the component." A different way to think about this is to go look at game engines or desktop UI frameworks which render stateful objects onto a canvas and see how many game engines or UI engines assume that your object is recreated each time. This is certainly true of the underlying render buffer of the graphics card, right? But generally the developer builds on top of stateful abstractions. React has, in fact, moved the complexity onto the developer to properly place and manage state (while not being faster nor more memory efficient than Vue or Svelte). I believe that a lot of React's expanding complexity flows from this design decision to model inherently stateful UIs in a "pretend everything is a stateless function" way because it is fundamentally playing opposite day against the underlying JavaScript and DOM.

o_m 2y ago

The attitude I've heard from many frontend devs is that they acknowledge that AI will do most of the work. v0 and Bolt will do most of the work. Not because it does a better job, but because there will be a race to the bottom where employers don't want to pay for anything else. So this might mainly be a problem for the AI to learn.

markandrewj 2y ago

I generally feel the opposite way. React was changing every few weeks when I started using it, the docs and API are much more stable and consistent now. In general web standards are more stable then ever also. People younger then myself won't have learn 100s of layout hacks to get their pages displaying properly cross browser, or sometimes even in just one browser. This is just my perspective, although I also understand JavaScript fatigue, I feel it is actually one of the best times to start learning.

lukebuehler 2y ago

It’s not that bad. I started basically from zero about a year ago, have been doing react maybe 20% of my work time since then, and I would say I now understand and can use most concepts/features in react.

Cthulhu_ 2y ago

I'm trying to parse that sentence and as it turns out... probably nothing is relevant to me that just writes end user front-end stuff. Most React development is in the backend / rendering or for specialists that write libraries, feels like.

pjmlp 2y ago

My main approach, when it is something I control, I stay as much on .NET and Java solutions for Web development, with minimal JavaScript. When not, I focus on backend and devops instead. Although some SaaS products make our life harder, with React only SDKs.

AlwaysRock 2y ago

> Imagine you decided to start developing websites today, how do you even start? You'd slap together a Jenkins/Jekyll site and host it on github for free. It's easier now to set up a website than ever. But yeah that React sentence is pretty difficult to gronk.

thorum 2y ago

> I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start? Easy: By not using that optional feature. If you’re like 99% of developers you really don’t need stuff like that until your app reaches a certain stage of growth, if ever - and React doesn’t force it on you.

aylmao 2y ago
Huge +1 to this. Looking at python 3.13 release notes [1]: > asyncio.as_completed() now returns an object that is both an asynchronous iterator and a plain iterator of awaitables. The awaitables yielded by asynchronous iteration include original task or future objects that were passed in, making it easier to associate results with the tasks being completed. (Contributed by Justin Arthur in gh-77714.) "I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing python scripts today, how do you even start?" [1] https://docs.python.org/3/whatsnew/3.13.html#asyncio https://docs.python.org/3/whatsnew/3.13.html#asyncio
- kovrik 2y ago
  Not sure if those are the same though? Async, await, iterators, futures etc. are pretty much standard constructs in almost all programming languages / concurrency frameworks. Whereas Actions, Transitions, Pending State, Reducers etc. are React-specific idiosyncrasies. I guess that's the main issue people have with React, when you learn it you have to spend so much time to learn all these React-specific constructs and idiosyncrasies that are not transferable anywhere else.
  - aylmao 2y ago
    When one is learning to program, one doesn't jump straight into learning coroutine management. Similarly, wether they are React-specific idiosyncrasies or not, one shouldn't assume people need to jump straight into Actions, Transitions, etc when first learning React.
yawaramin 2y ago

rdsubhas 2y ago

In my experience, React was an interesting take, but it had certain flawed red-flags that were ignored from the start. I wrote posts about it, but was doomed as a skeptic. The original fundamental premise: let's do one-way binding with virtual DOM, re-render, diff – did not make fundamental sense. Double the memory in browser, complete re-render & diff for every interaction? The answer was: Make it reliable, then make it fast. Now, it's full of hacked-up constructs attempting to make it fast – but it's neither fast nor reliable. At least with honest two-way binding frameworks, fast is guaranteed, and reliability comes from my experience. With React it's just a mess. I pity all the frontend engineers who's first intro has been with React, because unlearning is much more difficult than learning. Being mindful of the never-ending-nirvana frontend spirit of churn, and after doing web development in VBScript, JS, JQuery, Mootools, Applets, Actionscript, YUI/Ext/Sencha, Backbone, Knockout, Angular1, Angular2, React, Vue1 – I'd say try Flutter. It's genuinely a breath of fresh air. Except... Dart. If only Flutter was in Typescript it might have been a bit closer to nirvana. The Dart part is still keeping the frontend spirit of churn alive.

simplify 2y ago
Virtual DOM is not inherently an issue. Many libraries use it and are much faster than React. The main issue is React forces you to tell it which components to re-render. This causes a bloat of ceremony that makes it endlessly annoying (in comparison to global redraws) to write in.
- lyu07282 2y ago
  > React forces you to tell it which components to re-render That's a really weird statement, do you keep your application state in a mutable data structure instead of immutable? Do you know what a pure component is?
  - the_gipsy 2y ago
    So you don't use hooks at all? The one great unification of state management that comes included?
2y ago

soulofmischief 2y ago

Just use mithril and never look back. You can learn the API in one day and move on with your life creating compact and performant apps. React is unbelievably overengineered, classic case of creating solutions to self-invented problems.

rglover 2y ago

Shameless self-promotion, but anyone reading this who is just getting into front-end and doesn't want to deal with that ^, check out Joystick [1]. It's a full-stack JS framework with its own components library that uses plain HTML, CSS, and JS (and has dead-simple, obvious APIs for implementing more advanced logic like state and event handlers). It's a logical next step from learning web dev fundamentals to building full apps. [1] https://cheatcode.co/joystick https://cheatcode.co/joystick

chrismorgan 2y ago
Judging by your front page demo, your component stack is built on simple string concatenation (via untagged template strings), with nothing about escaping of any form, for any format. That's a very bad sign, you're just begging for injection attacks. There's absolutely no chance of me using a framework with a demo like that, even if it actually had decent tools for handling the situation.
- rglover 2y ago
  That's all mitigated on the server. You also have access to additional escaping tools for handling user-generated data on the server, too.
  - chrismorgan 2y ago
    > That's all mitigated on the server. How? Please be specific, because unless you're altering the source (which I'd be very unpleasantly shocked by), your use of untagged template strings makes it fundamentally impossible to mitigate such stuff, short of forbidding characters like & and < and " from data, which would be insanity. You're mixing template and data willy-nilly.
    - rglover 2y ago
      The source isn't altered (I take the component HTML, parse it, build it into a DOM, and render it). The data from the API is compiled separately (where sanitization can happen if you have untrusted user data). The two are combined together during SSR by passing the sanitized data to the component. Developer controlled code at the component-level is assumed trusted, however, there are three mechanisms for handling escaping/sanitizing on the server: 1. There are helpers built in to the API (you can conditionally enable sanitization depending on need) to handle sanitization and helper functions built-in to the server-side to do one-off escaping/sanitization for HTML. 2. Query params are sanitized automatically to prevent injection. 3. To prevent unescaped HTML in data from breaking renders, I base64 encode it before sending it to the browser. This approach to escaping is by design as some use cases call for sanitization (they're rendering user-generated data) while others do not. You're welcome to audit the source and see if I missed something or make suggestions on improvements.

shams93 2y ago

htmx and python

SkyMarshal 2y ago

> Imagine you decided to start developing websites today, how do you even start? Probably with something simpler like Alpine.js, or even JQuery. No beginner is going to be building the kind of web app that requires such a heavyweight framework like React. Don't bother with it until you know you need it.

johannes1234321 2y ago

Reading changelogs certainly isn't the right place to start learning. A changelogs is a quite condensed view on changes from an implementation point of view. Some projects are good in promoting highlights from user perspective, but still a tutorial and manual are better places to start.

mu53 2y ago

I think its all tech jobs at this point. People used to be a good sysadmin with just some bash, but now there are so many complex frameworks and best practices. The quality expected of apps over the last 20 years has skyrocketed, and the tools to handle those requirements have gotten increasingly complex.

lmm 2y ago

The HN hate boner for React is unreal. They've added a new hook to allow you to provide a more optimized implementation for a particular special case. It sounds like it's in the obvious place to find it if you need it, and does what you would want it to do. Why would you care about this unless you needed it? And if you needed it you'd know what it does.

reshlo 2y ago
> And if you needed it you’d know what it does. Why would that be true? Often people don’t know what they need to solve a particular problem.
- lmm 2y ago
  I meant the description quoted is the right description for someone who needs this to understand.

sergiomattei 2y ago

Why would a web dev learner need to know about this feature?

dcre 2y ago

I don’t think beginners are beginning by reading the release notes. Note that the wonderful learning guide doesn’t even discuss these advanced hooks. https://react.dev/learn https://react.dev/learn Even the reference section of the site makes clear how far down the priority list the advanced hooks are. https://react.dev/reference/react/hooks https://react.dev/reference/react/hooks

brundolf 2y ago

React has a dizzying number of concepts now. I don't love the direction it's taken the past few years; it used to be a really minimal and elegant core, but these days it's hard to keep up with all the abstractions

anonzzzies 2y ago

I read the updates and I know we will never need this stuff and we will never use it. However, we cannot not update to it for the clients that use it as other libraries will start using it. It is why we left react; this churn is just mental for things that have no value to most dev users. Even if it has potential value, many will just skip it as so many things from previous versions are not used in many codebases we see (and we see a lot in different large corp repositories).

paxys 2y ago

By that logic beginners can never get into programming (or really any other field) because there's some complexity on the deep end.

zild3d 2y ago

> I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start? You start where the docs say to start, https://react.dev/learn https://react.dev/learn which wouldn't be mentioning this advanced feature, just like pretty much any tech. Reading postgres, python, etc release notes will have a bunch of scary sounding new features to a beginner, but those won't be making their way into the "Get started" section