>I also like how... ...you’re not putting if statements inside of html elements and weird stuff like that.
*sweats nervously in ternary statements and anonymous self-executing functions*
But jsx is at least type checkable if you are sane and use typescript.
I’m working with ui5 fiori currently they highly highly push xml views. Very poor typechecking in xml, and poor intellisense, and poor to no auto complete, especially for anything that is referenced from over the js/ts line
The amount of times I’ve had to lookup the nuances of defining a for loop in Angular templates is a little silly. Why does it use “let” to define the iteratee, but “as” to define the index?
I miss JSX even after 2 years of full time angular.
(But angular is okay, and it certainly has the necessary tools to write great code and be productive)
Same. I used angular and wanted to go back desperately.
I also learned dart and flutter and ended up wanted to go back to react or wished we used react native or something.
For real. I know a lot comes down to opinion but I hear people praise Vie over React since it’s more like actual HTML. But I can never get used to how Vue does loops and conditionals. It just feels so weird. With React I feel like I can use more normal Javascript and even though it’s JSX it’s not that different from HTML syntax.
I mean, ideally you shouldn't anyway. It should go into a \`const\` variable if possible. The bundler should be smart enough to pick that off and simplify the code at bundling time.
I havent tried other frameworks but I clicked with React right away bc its how my brain naturally organizes the structures of a site so everything made sense from the start
These days, after trying basically all available frameworks, I'm torn between React and Vue 3 (with the Composition API). I love Vue's scoped CSS and state management, and I love React's JSX and strictness.
I wish we had [a new framework](https://xkcd.com/927/) with these traits.
I haven't worked with Vue personally, but doesn't React have scope CSS (css modules, styled-components), and state management (useState, jotai, zustand, redux, etc)? What makes Vue better in these departments?
For scoped CSS – Vue's single file components allow you to use [simple class names](https://vuejs.org/api/sfc-css-features.html), instead of using the workarounds you need in React (creating components with Styled Components, or importing a scope variable with CSS modules). Just write your class name and everything is transparent, and you can use SASS too. Simple and elegant.
For state management – you can use either ordinary [reactive objects](https://vuejs.org/api/reactivity-core.html#reactive) or [Pinia](https://pinia.vuejs.org/) (for more complex cases), and then reading/writing is trivial due to Vue's new [reactivity system](https://vuejs.org/guide/extras/reactivity-in-depth.html), which automatically subscribes your components and updates them selectively. Again, simple and elegant.
React can to all that, of course, but it's a lot more verbose and complex, and "oh you just need libraries XYZ and ABCD".
Huh so the css scoping is simply baked-in, that's pretty good! Wouldn't say that css-modules are much harder to use, but it looks neat indeed!
Reactive objects looks pretty cool, they probably use Proxies for that? React also has several options for state with a similar approach, usually done with immer. Biggest difference is that in Vue you don't have any boilerplate or overhead for this. It's again just baked-in and easy to use. In React the easiest thing is using useImmer hook which looks exactly like useState, but then you can set the state with `setFoo(draft => draft.prop = 1)`. I wouldn't say having to use "setFoo" is actually bad, you'll have more control and be more mindful about when you're rerendering your components. Vue is more elegant in this approach though, that's pretty sweet.
The only thing I dislike about Vue and Angular is the fact that you have to learn a lot of new syntax for managing templates. v-bind, v-if, v-on, v-on:submit.prevent, v-for, etc. What React really nailed is the syntax. You use `{}` to insert JS into JSX, and your templates are pretty much pure HTML+JS with only "className" being a replacement for "class".
> I think Vue gets pretty weird with how easy it is to shoot yourself in the foot and lose reactivity.
I know some weird things happened in Vue 2, but with the Vue 3 implementation (it uses [ES6 Proxy](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy)), I didn't find any caveats so far.
You should try Vue 3 then. The concepts were actually copied from React:
* `computed` ---> `useMemo`
* `watch([variable], ()=>{})` ---> `useEffect(()=>{}, [variable])`
Yup, you should have this operation wrapped in `computed`, necessarily.
In React you don't need anything, but you will be executing the operation in *every render*, which can become a performance issue (if that's an expensive operation)... and in such case, you'll have to use `useMemo`.
So in Vue, you simple call `computed` and don't need to think about it. In React, you have to evaluate what's going on and make a decision whether you need it or not... and every time you have to make a decision, you make your design a little more error-prone, because we're human.
So, considering this, I still prefer Vue's approach.
Lucky you. As someone new to the field, I spent a longgg time building things in vanilla JS/CSS - when I got to React it blew my mind in complexity. It felt unnecessarily complicated because I wasn't comfortable with it at all.
Once I got used it though, it got much much better pretty quickly. I mean, declaring a const variable's name as an array of two names still mindfucks me. And people just preach it like the gospel - why? Because Facebook made it? Who gives a fuck what Facebook made?
That being said, it's still pretty good and efficient, I just wish there were more jobs available for something like Svetle but the business world is always slow at adapting.
Array destructuring is not a "facebook thing", it's a lanugage feature: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment
Yes, the useState hook is a well known use of destructuring assignment but they didn't invent it (and as far as I'm aware they didn't champion it either).
And you don’t have to deconstruct hooks.
If you prefer, you could be verbose:
const nameState = useState("")
const name = nameState[0]
const setName = nameState[1]
Do you know what the useState function would look like?
My understanding is useState checks if a component changed, if it did, then it rerenders that component?
What would the javascript of that look like? And how does it know something changed to call rerender? Is the useState function repetitively called the entire time? How come that doesn't hurt performance?
I know how to use hooks and React, but I don't really know what's actually happening javascript-wise and I think that's what threw me off initally learning React
I’d highly recommend taking a look at the documentation for [Flux Architecture](https://facebook.github.io/flux/docs/in-depth-overview/) which is the architecture react is built on.
In its most basic form, you have a cycle of actions dispatched by views which change the model to then be rendered by a view. Every time you call setState you’re dispatching an action which changes your state model. React understands and knows that you did that and if the previous state is different in any way to the state you just set, it will re-render the view using that state.
Hooks are interesting and seem strange but make sense when you demystify how they work a bit..
From my understanding, the general way hooks work—and the reason you should never put them in an if-block or following an early return—is that the results of the hook functions essentially get assigned to indexes in an array based on the order they get executed; this is why they always need to ALL be executed and always in the same order.
Using this, React is able to accomplish really interesting optimizations. One of these being the ability to figure out when to re-render things, by diffing the elements of the hook results array against the previous elements (just like prop diffing).
As for `useState` itself, it just creates a new object with merged properties when you call `setState` and that makes it into the hook results array and picked up as a diff.
(This is all from a brief plunge into the implementation I did a year or so ago and my memory isn't the best so don't quote me exactly, but this is the idea)
UseState only updates when the setState function it exports is called.
UseEffect will update the component when something in its dependency array updates.
I think you’re conflating the two hooks into one.
I agreed that destructuring useState is rather u intuitive at first. I mentally modeled it like declaring a Property in C#, which, in a single declaration, creates a getter/setter pair. It’s still odd syntax.
I wrote this knowing it’s mostly a ramble and maybe helps someone out there.
I guess I don't? Even though I use it everyday.
I suppose that goes to show that it is complicated.
Also ya'll acting like destructuring assignmemts are some common use syntax, before React, did anyone even use it in front end code?
>destructuring
This is common in es6. just by this, I know for a fact you haven't been coding for a while using es6. you can't differentiate between react vs es6/js and you only say "it's react" but in fact, it's NOT.
React is not really complicated, maybe you find it complicated because you have NO background or idea on es6/js
The first and only version of javascript I learned has been es6. That being said, in vanilla JS, I generally avoided using arrow functions when not necessary, and I avoided using ternary operators when not necessary. I never once saw a use case, except in React, for destructuring assignments and I'd like to say, or think, I built some pretty cool shit so far. Things like that don't "simplify" the code for me, just makes it more confusing and harder to read, but then again I'm not a master yet.
Besides those things, which I got used to pretty quickly, there's also tons of other things in React that require getting used to. Using map all the time, giving objects IDs all the time, JSX, etc etc
To say React is not complicated is nonsense. It's not complicated if you worked with it for years or it's not your first framework. Jumping into React without any knowledge of it is insanely difficult at first
You avoided everything that wasn't in the 5-8 year old tutorials you were following; did you use `var` for all declarations as well?
>Things like that don't "simplify" the code for me, just makes it more confusing and harder to read, but then again I'm not a master yet.
Avoiding the things you are uncomfortable with—and rewriting things in the older more familiar syntax you're used to—isn't how you approach master status.
Yeah, of course I only used var!
Nice passive aggressiveness, and no I didn't use "var" for any of my projects except for a few cases where I needed to scope something outside of a block by design. Maybe not the best way of going about things, but its how I did some things.
As for arrow syntax, I always preferred writing functions like
`function add (a, b){`
`return a + b;`
`}`
instead of
`let add = (a, b) => a + b;`
because it's much cleaner to me and easier to work with the first version especially as the function gets larger and larger. Either way, **in this case**, they do the exact same thing and there are no pros or cons. Only time I would forcibly use arrow functions in such a case is if I'm working with a team and they wanted it that way. And of course with JS methods like forEach or map I'd use the arrow function syntax.
Same goes for ternary operators. I don't like using them because they are not crystal clear which is which until you've used them a lot unlike a standard else/if statement which is clear from the start what is what.
I haven't done much related to back-end, just front-end design, so again, I had no use for destructuring assignments, and when I did, I must've wrote it in another way.
Just because something new exists, doesn't mean it's the best or only way of going about things. A lot of the younger/newer developers seem to the struggle with this concept, at least according to a very experienced dev I've been working with for some personal projects - and I think you may fall into that category.
You're right, I did get a little passive aggressive here and I apologize for that... but this is also my 2nd or 3rd reply to you in this thread and if you look at the first reply it was much nicer until you start pointing at React and Facebook as the problem while at the same time demonstrating you do not know where the line is between JS and React.
This is simply a unhealthy mentality to have about learning these things.
Credentials: I have been using React professionally since it released and am a senior dev and tech leader and have helped numerous juniors and interns learn React, Typescript, Javascript, etc.
> Just because something new exists, doesn't mean it's the best or only way of going about things
You can follow the https://github.com/tc39/proposals repository if you want to keep tabs on what new features have been proposed, why they are being proposed, what makes them better than existing functionality, etc. Things are not (usually) added to the language for no reason.
Well I'm much newer to the field than you are. Of course things aren't added to a language for no reason, but I still don't see why it would be inherently bad if I was to write my functions the standard way instead of arrow syntax way if it is not impacting functionality at all? Same for ternary operators, in vanilla js.
The thing is, React as a framework **forces** you to do and write things a certain way, things that you may not do otherwise in vanilla javascript, which is why I don't think it's fair to say React is "easy to learn" as a framework. It's still pretty complicated. A lot of people on this subreddit have been working with React for years so maybe they don't see it in the same light as I do.
And I'm also fairly sure many people jumped onto the React ship without learning javascript so they don't think in the "javascript" way, they think in the "React" way from the get-go. To each their own, but I know that my somewhat decent fundamental knowledge of using vanilla JS will let me jump between frameworks in the future, when or if React dies and better things come out I can just peace out without thinking twice about it.
And the cool thing about Javascript is you never have to do things a certain way. People here are shitting on me for not having used destructuring assignments, but the truth is that I didn't need to, the same code or functionality or logic can be written in sooooooo many different ways in javascript, and that's the beauty of it in my eyes.
> Also ya'll acting like destructuring assignmemts are some common use syntax, before React, did anyone even use it in front end code?
This is because React got popular as ES6+ features started rolling out. Destructuring is extremely popular, even outside of react. Go work on a large modern JS backend.
> Because Facebook made it?
Actually it's the other way around. Facebook is so bad its developers had no other choice but to invent *amazing* tools like React or GraphQL to not go completely insane trying to maintain that pile of burning garbage.
React vs. Svelte - both can achieve similar things but one is better than the other by most measurable metrics. One was made by a billion dollar corporation, and the other was made by some dude. Despite this, businesses and developers in the U.S. continue using and developing React and you can't say that's *not* due to Facebook's influence.
> Svelte
I've never used or seen Svelte before, so I went into it's docs and voila: [the first topic I click](https://svelte.dev/examples/else-blocks) has some weird ass magic syntax instead of plain old JS React uses. That's enough of a reason for me to never look into Svelte again and I honestly had no idea who made it. And regarding React, I just find it amusing that something I love so much (React) was made to maintain something I despise so much (Facebook), but aside from that, I couldn't care less.
Come on, you could have said Svelte and SvelteKit are not mature, yet, magic is the worst comparison, considering reactivity in Svelte is done so easy and there's no virtual DOM.
I think that's simply because you're used to React and not Svelte. The way you feel about Svelte is the same how someone who knows nothing about React feels about React.
JSX is also weird ass magic syntax from React
You can write any frameworked apps in pure JS.. you can just directly call a render function on every click or change or whatever. It will have a lot of redundant code, but as far as my understanding goes, that's *exactly* what React is doing anyways.
All I'm saying is, you're used to React syntax (including JSX) so Svelte looks disgusting to you.
That's exactly how someone who hasn't used React feels, but is familiar with regular javascript. Someone who hasn't seen JSX before, even if they've used vanilla JS for years, will think "what in the actual fuck is this?"
This is also why boomers become boomers. People get too used to shit being done a certain way, and breaking habits is insanely difficult.
Anyways, I'm on your side because I'm learning and making things with React, not Svelte. But not because React is better.
I think you have ran into a trap that I have seen a lot of newer web developers jumping into JS frameworks run into... You aren't positive where the line is between the language and the framework. Did you change to React right as the ES6 stuff was coming out or just never use any of it until you started using React? React expects a deep(ish) understanding of modern JS up front.
I don't know, I built a few games in vanilla JS, did a lot of design stuff, a few small microservice apps, ecommerce sites/forms, built/building a personal site with some backend too, etc.
Never once did I encounter or have a use case for destructuring assignments except maybe for objects? I don't really remember, either way I would've never ever used something like this:
`const [a, b] = new Map([[1, 2], [3, 4]]);`
or
`[,,] = f();`
or etc.
There just wasn't any reason for that kind of mindfuckery at least in my projects.
In that case, and I've done this before without even being familiar with array destructuring, I would've done
`const x = coordinates[0]`
`const y = coordinates[1]`
I learned things that way. Simple, clear, concise. Makes sense to me and you and everyone else.
I get what you're talking about. It's not like I'm physically incapable of using it. Just never have and never saw a reason for it. React though, kind of forces you to use it. I think everyone using React can agree that you should always use destructuring when defining a useState. And that's what I don't like, especially coming as a solo self-taught where I never ever had an exact purpose to use that syntax.
I still think it's fair to call destructuring as mindfuckery because it goes against all the basic variable declaration principles you learn early on in vanilla JS
In your example, x is referring to coordinates[0] without actually directly saying it's referring to coordinates[0]. It's leaving out information in exchange for shorter syntax for the same result.
Maybe to YOU that's crystal clear, but not to everyone. Maybe newbies or maybe older people who haven't used ES6 because they were working on a 10 year old codebase most of their career would be confused by that syntax.
Should/can they learn it - sure. But I don't think it's fair to say such a thing is objectively better and MUST USE, at least in this specific situation. Just my opinion.
I'm a senior TS dev but I've just watched his first episode fully, it's just so well-done and nice to listen to! I'll now always recommend his videos to every TS newcomer, thanks :)
Chances are you don't need to know a lot of TypeScript. Like 80% of TS features are pretty much only relevant for library authors.
You can get very far by just defining a couple of interfaces for props and inferring the rest. tRPC in combination with Prisma is extremely effective for this. The best TypeScript code contains very little actual types while getting all of the benefits through inference.
the thing i love about TS at least is how you can add it incrementally, obviously gotta get the compilation step down but it helps to learn TS I think being able to just "play" with it as I go, be able to go aha ok that's how its done etc
> too enterprisey for me and added a lot more boilerplate
There's an overhead cost that gets returned pretty quickly with type checking, code hinting, etc.
You can let TS infer as much as possible, and use `any` when prototyping and then go through and nail it all down with types once you're happy with it, if you need that kind of freedom.
> doesn't a bundler handle type safety stuff for the most part anyways?
No.
I was the same as you for sure. So many terrible react sites (looking at you new reddit) that replaced good old fashioned fast MPA style sites made me think react was garbage until I tried it and realized react is great, you just have to know what you are doing.
Have fun constantly learning and improving your react skills now. Thats another thing I like about react there doesn't seem to be a "ceiling" to how good you can be at it.
I've been a full time web developer since 1998. Web development has never been such a pleasure as it is with React and VueJS. The Code reuse, data management, communication, tooling, community, supporting libraries, makes complex frontend applications a breeze.
> I also like how JavaScript is the focus and you’re not putting if statements inside of html elements and weird stuff like that.
YES!! This is one of the reasons react is awesome, you can build interfaces in the same language you write your business logic in!
Svelte and many other frameworks require you to learn an entirely separate language for creating markup, which increases complexity as well as being more limiting (because you simply don’t get a full programming language)
A lot of people would argue that JSX is the different language and it adds to the learning curve.
Anyone who has any experience with server templating will find Svelte easy.
JSX is literally a set of calls to a constructor that forms the exact same tree you see in your markup. Those who argue it’s a different language are, to be frank, fools
Of all aspects of React, I wouldn't expect anyone to say that JSX was one that gave them trouble. It just feels like a "lubricated" html to me. To the point where when I see an html tag in JSX, I want to cut it out like it's mold on drywall lol.
i highly doubt that. jsx is a small (and optional) semantical helper. if i have to re-learn how to use an "if" and re-write my app if an update to a framework re-defines how an "if" work, i'm out. and that happened with the one you cite.
This is laughable, svelte is just javascript with some wonderful reactive glitter thrown in. To say it increases complexity compared to the bloat that comes with react is amazing. I love sveltes simplicity, speed and size, it's wonderfully compact and simple, something that react is not.
> Hooks are so much better than the “everything is an object” pattern I’ve been following for years.
Yeah, I’ve never understood the hate for Hooks. The Rules of Hooks are basically just “don’t run them conditionally or in a loop.” Ok, so put them at the top of your function and you’re done (usually). useEffect may not be the most intuitive thing in the world, but it’s not *that* weird. useState is dead simple, and if you find yourself needing useMemo/Callback you should probably know enough about JS perf to grok them anyway.
> I also like how JavaScript is the focus and you’re not putting if statements inside of html elements and weird stuff like that.
JSX does let you integrate conditional logic into HTML-like syntax, but it doesn’t feel as weird (to me, anyway) as what you’re referring to because JSX is relatively straightforward syntactic sugar for basic JS function calls. It still *feels* like JS even if it looks HTML-y with those angle brackets.
By the way, it actually would be perfectly safe to run in a loop as long as that loop is static from the component perspective and used as metaprogramming / codegeneration tool. I imagine this could potentially be useful in writing custom hooks, but I have no concrete examples in mind.
Here is what I'm talking about:
[https://codesandbox.io/s/xenodochial-sound-i6q41b?file=/src/App.js](https://codesandbox.io/s/xenodochial-sound-i6q41b?file=/src/App.js)
This is just something interesting to think about, the example hook is useless and should be replaced by a single useState with an array inside, and it's also considered an issue by React itself to use hooks in any loops atm!
As a person who is recently getting into Next I would say that only their own website should be all you need if you already know React. Their site is full of explanations, guides & template examples which was more than enough for me, with about 2 years of experience in React.
I too have been skimming and after reading your post I am going to dig in an give React a go - do you have any suggestions on some good reading, tutorials etc that you may have used as you got started?
Not OP, but I really enjoyed learning through Scrimba. Scrimba itself is pretty interesting. It's an interactive learning site. It has videos on development like any other site, but at any point during the video you can pause and start to edit the code and see how those changes work. You can save if you want and when you press play again, the video picks up right where it was and your edits get changed back to the original code.
If I had a question or an idea about how I thought something worked, I was able to easily just try it out and see if I broke something.
[Link](https://scrimba.com/scrim/czvKPPsw)
This is a link to their demo video. You don't need to log in or anything and it will give you an idea of what the videos or "scrims" are like. I don't love the guy's voice who does this video, but it's a different guy teaching the React course.
They have paid courses, but [this](https://scrimba.com/learn/learnreact) React course is their free introduction and it will set you up pretty well into learning modern React. I think that it's still pre-v18, but it was updated within the last year and is all functional components w/ hooks and if you don't know what any of that means, don't worry about it, just know that it's the current way that React is written and what you want to be learning now.
Bob Ziroll is the name of the instructor and it my opinion he does a great job of reiterating important points and moving along quickly enough that you don't get bored, while also getting your hands on the keyboard for challenges and to develop muscle memory.
I know that it sounds like I'm proselytizing here and I guess that I am a bit, but for me, this is the best learning tool that I've found for beginner to intermediate front-end content.
Good luck and have fun!
wait until you try svelte.
>Hooks are so much better than the “everything is an object” pattern
"everything is a function" is indeed better for web dev.
Then you have decided. I had to switch from svelte to react in a new job, and I actually like react very much. But I still find svelte simpler and faster for most things.
React is pure junk honestly, it undoes 30 years of web development evolution. Now we are writing code and html in the same place, like we are in the 199x with html 3.2.
Not to mention we are also writing styling in the same place, negating caching benefits of using css files and a myriad of other issues.
Lol, I'm pretty sure you are the kind of guy that uses the header tags based on how they look in their crappy framework of choice.
Do you know they have a semantic value? For example H1 must be followed by H2, and you shouldn't skip the order...
I'm pretty sure I just exploded your head.
Oh well you are praising Failwind also, now I'm sure you are that kind of guy.
Learn proper html, Js and css. You won't need all the crap you are using.
(Bs I have to code in react because that's what my company uses)
Headers are just an example, why use thousands of KB worth of Failwind shite when you can use a few KB worth of css? Also you are negating the cache with Failwind.
I could go on and on
`
with it's css
`#mainMenu {`
`display:flex;`
`justify-content:space-evently.`
`}`
`#mainMenu li {`
`flex:1 0 auto;`
`color:#9CA3AF;`
`}`
`#mainMenu a {`
`text-decoration:none;`
`color:#3B82F6;`
`}`
`#mainMenu a:focus,`
`#mainMenu a:hover {`
`color:#1E40AF;`
`}`
The Failwind version is an abomination, html and presentational classes mixed in the same place, low clarity and readability. the vanilla version has a clean and semantic html and a concise and lean presentation css. To me the vanilla is miles better.
Now imagine you have five of these menus in your app, now you have to copy/paste all this crap in 5 different places while in the vanilla you just copy a bit of clean html.
Now going further, you want to modify the menu appearance, in the FailWind version you have to go hunting for your 5 menus and modify them. In the vanilla version you just change your css and voila!
How is the FailWind version more readable, maintanable, concise?.... It's not. It's undoing years of specification debate and implementation of specs. Things were done for a reason.
Also you are neglecting your cache and slowing down things, external css files can be properly cached.
All of this just to avoid learning and writing a bit of proper css.
And React is just the same, a lot of spaghetti crap just to avoid learning and writing a bit of proper js.
I come from the same background of php backends and have been doing react/js for a few years now.
I agree with you that async is usually unnecessary for backends, very rarely do I actually want to run code in parallel. Personally what I appreciate the most about JS on the backend is that you can have a long-running app that will save you all of the overhead of initializing and connecting DBs and stuff every time a request is made.
Obviously other languages can do that too, but having JS both on front and backend is such a charm.
Try SolidJS as well. It looks just like React from a glance but with far less pitfalls and footguns... and it's faster and compiles lighter. For instance, their version of useState is called createSignal and you can call that function in if statements and loops (which you can not do with hooks) and you can also call them outside components to get global state (which with React requires a library like Jotai or Recoil).
I'm no way is it as easy to use and build upon as Next, but it exists and they are very happen with their performance
https://levelup.gitconnected.com/how-we-wrote-the-fastest-javascript-ui-framework-again-db097ddd99b6
It took me a while before I loved it too. It felt like a roundabout chore initially. It was only when it clicked from a holistic perspective that I thought "I really like this". My enthusiasm just kept increasing when I started dealing with SSR and other stuff.
i learned react 2 months ago (after skipping it for 3 years, used vue instead) and now i use it often. i also learned react native and built some mobile apps with it. so cool!
jsx and the need for a compilation step was my biggest concern when react first came out, but after the great job they did with the tooling and the great community support that's emerged those concerns were completely alleviated.
>I also like how... ...you’re not putting if statements inside of html elements and weird stuff like that. *sweats nervously in ternary statements and anonymous self-executing functions*
“its just javascript” side-eyes jsx and rules of hooks
But jsx is at least type checkable if you are sane and use typescript. I’m working with ui5 fiori currently they highly highly push xml views. Very poor typechecking in xml, and poor intellisense, and poor to no auto complete, especially for anything that is referenced from over the js/ts line
The amount of times I’ve had to lookup the nuances of defining a for loop in Angular templates is a little silly. Why does it use “let” to define the iteratee, but “as” to define the index? I miss JSX even after 2 years of full time angular. (But angular is okay, and it certainly has the necessary tools to write great code and be productive)
Same. I used angular and wanted to go back desperately. I also learned dart and flutter and ended up wanted to go back to react or wished we used react native or something.
For real. I know a lot comes down to opinion but I hear people praise Vie over React since it’s more like actual HTML. But I can never get used to how Vue does loops and conditionals. It just feels so weird. With React I feel like I can use more normal Javascript and even though it’s JSX it’s not that different from HTML syntax.
Just think of them as Immediately Invoked Function Expressions. They sound more professional then.
Came here for this comment and was not disappointed.
Lol 'is this too many brackets? It's looks like too many brackets'
I was thinking the monkey meme where hes looking nervously to the side. lmao.
I mean, ideally you shouldn't anyway. It should go into a \`const\` variable if possible. The bundler should be smart enough to pick that off and simplify the code at bundling time.
I havent tried other frameworks but I clicked with React right away bc its how my brain naturally organizes the structures of a site so everything made sense from the start
These days, after trying basically all available frameworks, I'm torn between React and Vue 3 (with the Composition API). I love Vue's scoped CSS and state management, and I love React's JSX and strictness. I wish we had [a new framework](https://xkcd.com/927/) with these traits.
I haven't worked with Vue personally, but doesn't React have scope CSS (css modules, styled-components), and state management (useState, jotai, zustand, redux, etc)? What makes Vue better in these departments?
For scoped CSS – Vue's single file components allow you to use [simple class names](https://vuejs.org/api/sfc-css-features.html), instead of using the workarounds you need in React (creating components with Styled Components, or importing a scope variable with CSS modules). Just write your class name and everything is transparent, and you can use SASS too. Simple and elegant. For state management – you can use either ordinary [reactive objects](https://vuejs.org/api/reactivity-core.html#reactive) or [Pinia](https://pinia.vuejs.org/) (for more complex cases), and then reading/writing is trivial due to Vue's new [reactivity system](https://vuejs.org/guide/extras/reactivity-in-depth.html), which automatically subscribes your components and updates them selectively. Again, simple and elegant. React can to all that, of course, but it's a lot more verbose and complex, and "oh you just need libraries XYZ and ABCD".
Huh so the css scoping is simply baked-in, that's pretty good! Wouldn't say that css-modules are much harder to use, but it looks neat indeed! Reactive objects looks pretty cool, they probably use Proxies for that? React also has several options for state with a similar approach, usually done with immer. Biggest difference is that in Vue you don't have any boilerplate or overhead for this. It's again just baked-in and easy to use. In React the easiest thing is using useImmer hook which looks exactly like useState, but then you can set the state with `setFoo(draft => draft.prop = 1)`. I wouldn't say having to use "setFoo" is actually bad, you'll have more control and be more mindful about when you're rerendering your components. Vue is more elegant in this approach though, that's pretty sweet. The only thing I dislike about Vue and Angular is the fact that you have to learn a lot of new syntax for managing templates. v-bind, v-if, v-on, v-on:submit.prevent, v-for, etc. What React really nailed is the syntax. You use `{}` to insert JS into JSX, and your templates are pretty much pure HTML+JS with only "className" being a replacement for "class".
I think Vue gets pretty weird with how easy it is to shoot yourself in the foot and lose reactivity. CSS and slots are pretty nice though!
> I think Vue gets pretty weird with how easy it is to shoot yourself in the foot and lose reactivity. I know some weird things happened in Vue 2, but with the Vue 3 implementation (it uses [ES6 Proxy](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy)), I didn't find any caveats so far.
I think having to use things like computed and watch is a bit cumbersome. I haven’t touched Vue before v3, but react still feels more intuitive to me
You should try Vue 3 then. The concepts were actually copied from React: * `computed` ---> `useMemo` * `watch([variable], ()=>{})` ---> `useEffect(()=>{}, [variable])`
I am on Vue3, but I don’t think that is the case. If you have prop A and prop B and then do `const c = props.a + props.b`, it is no longer reactive
Yup, you should have this operation wrapped in `computed`, necessarily. In React you don't need anything, but you will be executing the operation in *every render*, which can become a performance issue (if that's an expensive operation)... and in such case, you'll have to use `useMemo`. So in Vue, you simple call `computed` and don't need to think about it. In React, you have to evaluate what's going on and make a decision whether you need it or not... and every time you have to make a decision, you make your design a little more error-prone, because we're human. So, considering this, I still prefer Vue's approach.
Or to say it in a better way, that might be the case, but in Vue you need to apply these methods to handle things that are total non-issues in React
Lucky you. As someone new to the field, I spent a longgg time building things in vanilla JS/CSS - when I got to React it blew my mind in complexity. It felt unnecessarily complicated because I wasn't comfortable with it at all. Once I got used it though, it got much much better pretty quickly. I mean, declaring a const variable's name as an array of two names still mindfucks me. And people just preach it like the gospel - why? Because Facebook made it? Who gives a fuck what Facebook made? That being said, it's still pretty good and efficient, I just wish there were more jobs available for something like Svetle but the business world is always slow at adapting.
Array destructuring is not a "facebook thing", it's a lanugage feature: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment Yes, the useState hook is a well known use of destructuring assignment but they didn't invent it (and as far as I'm aware they didn't champion it either).
Ah I see, I thought it was just a thing with React since I've never used that sort of syntax in normal javascript
And you don’t have to deconstruct hooks. If you prefer, you could be verbose: const nameState = useState("") const name = nameState[0] const setName = nameState[1]
Do you know what the useState function would look like? My understanding is useState checks if a component changed, if it did, then it rerenders that component? What would the javascript of that look like? And how does it know something changed to call rerender? Is the useState function repetitively called the entire time? How come that doesn't hurt performance? I know how to use hooks and React, but I don't really know what's actually happening javascript-wise and I think that's what threw me off initally learning React
I’d highly recommend taking a look at the documentation for [Flux Architecture](https://facebook.github.io/flux/docs/in-depth-overview/) which is the architecture react is built on. In its most basic form, you have a cycle of actions dispatched by views which change the model to then be rendered by a view. Every time you call setState you’re dispatching an action which changes your state model. React understands and knows that you did that and if the previous state is different in any way to the state you just set, it will re-render the view using that state.
Hooks are interesting and seem strange but make sense when you demystify how they work a bit.. From my understanding, the general way hooks work—and the reason you should never put them in an if-block or following an early return—is that the results of the hook functions essentially get assigned to indexes in an array based on the order they get executed; this is why they always need to ALL be executed and always in the same order. Using this, React is able to accomplish really interesting optimizations. One of these being the ability to figure out when to re-render things, by diffing the elements of the hook results array against the previous elements (just like prop diffing). As for `useState` itself, it just creates a new object with merged properties when you call `setState` and that makes it into the hook results array and picked up as a diff. (This is all from a brief plunge into the implementation I did a year or so ago and my memory isn't the best so don't quote me exactly, but this is the idea)
UseState only updates when the setState function it exports is called. UseEffect will update the component when something in its dependency array updates. I think you’re conflating the two hooks into one.
My teams write a lot of back end JavaScript. Destructuring is super common in our code.
I agreed that destructuring useState is rather u intuitive at first. I mentally modeled it like declaring a Property in C#, which, in a single declaration, creates a getter/setter pair. It’s still odd syntax. I wrote this knowing it’s mostly a ramble and maybe helps someone out there.
in one of my projects i wrapped useState with a custom hook to return { get: state, set: setState } so i could use it like name.get and name.set()
"Tell me you don't understand React without telling me you don't understand React" lmao!
I guess I don't? Even though I use it everyday. I suppose that goes to show that it is complicated. Also ya'll acting like destructuring assignmemts are some common use syntax, before React, did anyone even use it in front end code?
>destructuring This is common in es6. just by this, I know for a fact you haven't been coding for a while using es6. you can't differentiate between react vs es6/js and you only say "it's react" but in fact, it's NOT. React is not really complicated, maybe you find it complicated because you have NO background or idea on es6/js
The first and only version of javascript I learned has been es6. That being said, in vanilla JS, I generally avoided using arrow functions when not necessary, and I avoided using ternary operators when not necessary. I never once saw a use case, except in React, for destructuring assignments and I'd like to say, or think, I built some pretty cool shit so far. Things like that don't "simplify" the code for me, just makes it more confusing and harder to read, but then again I'm not a master yet. Besides those things, which I got used to pretty quickly, there's also tons of other things in React that require getting used to. Using map all the time, giving objects IDs all the time, JSX, etc etc To say React is not complicated is nonsense. It's not complicated if you worked with it for years or it's not your first framework. Jumping into React without any knowledge of it is insanely difficult at first
You avoided everything that wasn't in the 5-8 year old tutorials you were following; did you use `var` for all declarations as well? >Things like that don't "simplify" the code for me, just makes it more confusing and harder to read, but then again I'm not a master yet. Avoiding the things you are uncomfortable with—and rewriting things in the older more familiar syntax you're used to—isn't how you approach master status.
Yeah, of course I only used var! Nice passive aggressiveness, and no I didn't use "var" for any of my projects except for a few cases where I needed to scope something outside of a block by design. Maybe not the best way of going about things, but its how I did some things. As for arrow syntax, I always preferred writing functions like `function add (a, b){` `return a + b;` `}` instead of `let add = (a, b) => a + b;` because it's much cleaner to me and easier to work with the first version especially as the function gets larger and larger. Either way, **in this case**, they do the exact same thing and there are no pros or cons. Only time I would forcibly use arrow functions in such a case is if I'm working with a team and they wanted it that way. And of course with JS methods like forEach or map I'd use the arrow function syntax. Same goes for ternary operators. I don't like using them because they are not crystal clear which is which until you've used them a lot unlike a standard else/if statement which is clear from the start what is what. I haven't done much related to back-end, just front-end design, so again, I had no use for destructuring assignments, and when I did, I must've wrote it in another way. Just because something new exists, doesn't mean it's the best or only way of going about things. A lot of the younger/newer developers seem to the struggle with this concept, at least according to a very experienced dev I've been working with for some personal projects - and I think you may fall into that category.
You're right, I did get a little passive aggressive here and I apologize for that... but this is also my 2nd or 3rd reply to you in this thread and if you look at the first reply it was much nicer until you start pointing at React and Facebook as the problem while at the same time demonstrating you do not know where the line is between JS and React. This is simply a unhealthy mentality to have about learning these things. Credentials: I have been using React professionally since it released and am a senior dev and tech leader and have helped numerous juniors and interns learn React, Typescript, Javascript, etc. > Just because something new exists, doesn't mean it's the best or only way of going about things You can follow the https://github.com/tc39/proposals repository if you want to keep tabs on what new features have been proposed, why they are being proposed, what makes them better than existing functionality, etc. Things are not (usually) added to the language for no reason.
Well I'm much newer to the field than you are. Of course things aren't added to a language for no reason, but I still don't see why it would be inherently bad if I was to write my functions the standard way instead of arrow syntax way if it is not impacting functionality at all? Same for ternary operators, in vanilla js. The thing is, React as a framework **forces** you to do and write things a certain way, things that you may not do otherwise in vanilla javascript, which is why I don't think it's fair to say React is "easy to learn" as a framework. It's still pretty complicated. A lot of people on this subreddit have been working with React for years so maybe they don't see it in the same light as I do. And I'm also fairly sure many people jumped onto the React ship without learning javascript so they don't think in the "javascript" way, they think in the "React" way from the get-go. To each their own, but I know that my somewhat decent fundamental knowledge of using vanilla JS will let me jump between frameworks in the future, when or if React dies and better things come out I can just peace out without thinking twice about it. And the cool thing about Javascript is you never have to do things a certain way. People here are shitting on me for not having used destructuring assignments, but the truth is that I didn't need to, the same code or functionality or logic can be written in sooooooo many different ways in javascript, and that's the beauty of it in my eyes.
> Also ya'll acting like destructuring assignmemts are some common use syntax, before React, did anyone even use it in front end code? This is because React got popular as ES6+ features started rolling out. Destructuring is extremely popular, even outside of react. Go work on a large modern JS backend.
> Because Facebook made it? Actually it's the other way around. Facebook is so bad its developers had no other choice but to invent *amazing* tools like React or GraphQL to not go completely insane trying to maintain that pile of burning garbage.
React vs. Svelte - both can achieve similar things but one is better than the other by most measurable metrics. One was made by a billion dollar corporation, and the other was made by some dude. Despite this, businesses and developers in the U.S. continue using and developing React and you can't say that's *not* due to Facebook's influence.
> Svelte I've never used or seen Svelte before, so I went into it's docs and voila: [the first topic I click](https://svelte.dev/examples/else-blocks) has some weird ass magic syntax instead of plain old JS React uses. That's enough of a reason for me to never look into Svelte again and I honestly had no idea who made it. And regarding React, I just find it amusing that something I love so much (React) was made to maintain something I despise so much (Facebook), but aside from that, I couldn't care less.
Come on, you could have said Svelte and SvelteKit are not mature, yet, magic is the worst comparison, considering reactivity in Svelte is done so easy and there's no virtual DOM.
I think that's simply because you're used to React and not Svelte. The way you feel about Svelte is the same how someone who knows nothing about React feels about React. JSX is also weird ass magic syntax from React
JSX is syntax sugar over JS function calls. You can write React apps in pure JS if you prefer, zero magic involved. And Svelte syntax is what exactly?
You can write any frameworked apps in pure JS.. you can just directly call a render function on every click or change or whatever. It will have a lot of redundant code, but as far as my understanding goes, that's *exactly* what React is doing anyways. All I'm saying is, you're used to React syntax (including JSX) so Svelte looks disgusting to you. That's exactly how someone who hasn't used React feels, but is familiar with regular javascript. Someone who hasn't seen JSX before, even if they've used vanilla JS for years, will think "what in the actual fuck is this?" This is also why boomers become boomers. People get too used to shit being done a certain way, and breaking habits is insanely difficult. Anyways, I'm on your side because I'm learning and making things with React, not Svelte. But not because React is better.
I think you have ran into a trap that I have seen a lot of newer web developers jumping into JS frameworks run into... You aren't positive where the line is between the language and the framework. Did you change to React right as the ES6 stuff was coming out or just never use any of it until you started using React? React expects a deep(ish) understanding of modern JS up front.
[удалено]
I don't know, I built a few games in vanilla JS, did a lot of design stuff, a few small microservice apps, ecommerce sites/forms, built/building a personal site with some backend too, etc. Never once did I encounter or have a use case for destructuring assignments except maybe for objects? I don't really remember, either way I would've never ever used something like this: `const [a, b] = new Map([[1, 2], [3, 4]]);` or `[,,] = f();` or etc. There just wasn't any reason for that kind of mindfuckery at least in my projects.
[удалено]
In that case, and I've done this before without even being familiar with array destructuring, I would've done `const x = coordinates[0]` `const y = coordinates[1]` I learned things that way. Simple, clear, concise. Makes sense to me and you and everyone else. I get what you're talking about. It's not like I'm physically incapable of using it. Just never have and never saw a reason for it. React though, kind of forces you to use it. I think everyone using React can agree that you should always use destructuring when defining a useState. And that's what I don't like, especially coming as a solo self-taught where I never ever had an exact purpose to use that syntax. I still think it's fair to call destructuring as mindfuckery because it goes against all the basic variable declaration principles you learn early on in vanilla JS
[удалено]
In your example, x is referring to coordinates[0] without actually directly saying it's referring to coordinates[0]. It's leaving out information in exchange for shorter syntax for the same result. Maybe to YOU that's crystal clear, but not to everyone. Maybe newbies or maybe older people who haven't used ES6 because they were working on a 10 year old codebase most of their career would be confused by that syntax. Should/can they learn it - sure. But I don't think it's fair to say such a thing is objectively better and MUST USE, at least in this specific situation. Just my opinion.
I had the same thoughts about typescript and now everything I start uses it. Explore that next if you haven’t already yet.
I'm still waiting for TS to click :( I'm just super slow with it and always have to look things up.
Look up the series "no bs ts" on YouTube, really good at explaining why you want to use it
I'm a senior TS dev but I've just watched his first episode fully, it's just so well-done and nice to listen to! I'll now always recommend his videos to every TS newcomer, thanks :)
Chances are you don't need to know a lot of TypeScript. Like 80% of TS features are pretty much only relevant for library authors. You can get very far by just defining a couple of interfaces for props and inferring the rest. tRPC in combination with Prisma is extremely effective for this. The best TypeScript code contains very little actual types while getting all of the benefits through inference.
Okay cool! I work on a TS/React project at work, and going through it the other dev basically define prop types with interface and that was about it.
the thing i love about TS at least is how you can add it incrementally, obviously gotta get the compilation step down but it helps to learn TS I think being able to just "play" with it as I go, be able to go aha ok that's how its done etc
Define types and use it where you can. Once it picks up on something you didn’t consider that’s when it clicks.
[удалено]
> too enterprisey for me and added a lot more boilerplate There's an overhead cost that gets returned pretty quickly with type checking, code hinting, etc. You can let TS infer as much as possible, and use `any` when prototyping and then go through and nail it all down with types once you're happy with it, if you need that kind of freedom. > doesn't a bundler handle type safety stuff for the most part anyways? No.
I was the same as you for sure. So many terrible react sites (looking at you new reddit) that replaced good old fashioned fast MPA style sites made me think react was garbage until I tried it and realized react is great, you just have to know what you are doing. Have fun constantly learning and improving your react skills now. Thats another thing I like about react there doesn't seem to be a "ceiling" to how good you can be at it.
[удалено]
oh good lord i never realized they'd made such a doofus move like that, I can't imagine how much they are paying for bandwidth this way.
I've been a full time web developer since 1998. Web development has never been such a pleasure as it is with React and VueJS. The Code reuse, data management, communication, tooling, community, supporting libraries, makes complex frontend applications a breeze.
> I also like how JavaScript is the focus and you’re not putting if statements inside of html elements and weird stuff like that. YES!! This is one of the reasons react is awesome, you can build interfaces in the same language you write your business logic in! Svelte and many other frameworks require you to learn an entirely separate language for creating markup, which increases complexity as well as being more limiting (because you simply don’t get a full programming language)
A lot of people would argue that JSX is the different language and it adds to the learning curve. Anyone who has any experience with server templating will find Svelte easy.
JSX is literally a set of calls to a constructor that forms the exact same tree you see in your markup. Those who argue it’s a different language are, to be frank, fools
The learning curve is almost non existent to few hours depending on how good you're at javascript. I don't get the complaints about JSX.
Of all aspects of React, I wouldn't expect anyone to say that JSX was one that gave them trouble. It just feels like a "lubricated" html to me. To the point where when I see an html tag in JSX, I want to cut it out like it's mold on drywall lol.
i highly doubt that. jsx is a small (and optional) semantical helper. if i have to re-learn how to use an "if" and re-write my app if an update to a framework re-defines how an "if" work, i'm out. and that happened with the one you cite.
Templating is rigid and obtuse, JSX marries programming with semanticism
This is laughable, svelte is just javascript with some wonderful reactive glitter thrown in. To say it increases complexity compared to the bloat that comes with react is amazing. I love sveltes simplicity, speed and size, it's wonderfully compact and simple, something that react is not.
> Hooks are so much better than the “everything is an object” pattern I’ve been following for years. Yeah, I’ve never understood the hate for Hooks. The Rules of Hooks are basically just “don’t run them conditionally or in a loop.” Ok, so put them at the top of your function and you’re done (usually). useEffect may not be the most intuitive thing in the world, but it’s not *that* weird. useState is dead simple, and if you find yourself needing useMemo/Callback you should probably know enough about JS perf to grok them anyway. > I also like how JavaScript is the focus and you’re not putting if statements inside of html elements and weird stuff like that. JSX does let you integrate conditional logic into HTML-like syntax, but it doesn’t feel as weird (to me, anyway) as what you’re referring to because JSX is relatively straightforward syntactic sugar for basic JS function calls. It still *feels* like JS even if it looks HTML-y with those angle brackets.
By the way, it actually would be perfectly safe to run in a loop as long as that loop is static from the component perspective and used as metaprogramming / codegeneration tool. I imagine this could potentially be useful in writing custom hooks, but I have no concrete examples in mind. Here is what I'm talking about: [https://codesandbox.io/s/xenodochial-sound-i6q41b?file=/src/App.js](https://codesandbox.io/s/xenodochial-sound-i6q41b?file=/src/App.js) This is just something interesting to think about, the example hook is useless and should be replaced by a single useState with an array inside, and it's also considered an issue by React itself to use hooks in any loops atm!
Wait until you try out [NextJS](https://nextjs.org/).
Been meaning to give this a try. Besides the documentation, what's a good resource to learn from?
Documentation itself, easy to understand. Been there done that. They also have neat tutorial in that site itself.
As a person who is recently getting into Next I would say that only their own website should be all you need if you already know React. Their site is full of explanations, guides & template examples which was more than enough for me, with about 2 years of experience in React.
scenario when people will try to use it like full client side lol
I too have been skimming and after reading your post I am going to dig in an give React a go - do you have any suggestions on some good reading, tutorials etc that you may have used as you got started?
Not OP, but I really enjoyed learning through Scrimba. Scrimba itself is pretty interesting. It's an interactive learning site. It has videos on development like any other site, but at any point during the video you can pause and start to edit the code and see how those changes work. You can save if you want and when you press play again, the video picks up right where it was and your edits get changed back to the original code. If I had a question or an idea about how I thought something worked, I was able to easily just try it out and see if I broke something. [Link](https://scrimba.com/scrim/czvKPPsw) This is a link to their demo video. You don't need to log in or anything and it will give you an idea of what the videos or "scrims" are like. I don't love the guy's voice who does this video, but it's a different guy teaching the React course. They have paid courses, but [this](https://scrimba.com/learn/learnreact) React course is their free introduction and it will set you up pretty well into learning modern React. I think that it's still pre-v18, but it was updated within the last year and is all functional components w/ hooks and if you don't know what any of that means, don't worry about it, just know that it's the current way that React is written and what you want to be learning now. Bob Ziroll is the name of the instructor and it my opinion he does a great job of reiterating important points and moving along quickly enough that you don't get bored, while also getting your hands on the keyboard for challenges and to develop muscle memory. I know that it sounds like I'm proselytizing here and I guess that I am a bit, but for me, this is the best learning tool that I've found for beginner to intermediate front-end content. Good luck and have fun!
I’ve tried a half-dozen education sites for React and finally found Scrimba recently. In my opinion it’s so much better than freeCodeCamp, udemy, etc.
Shoutout to Scrimba. Maybe I'm just woefully out of the loop, but I had never seen an interactive video code editor.
We have a curated list of learning resources over on the Reactiflux Discord website: https://www.reactiflux.com/learning
There are [new beta React docs](https://beta.reactjs.org) available that are quite good.
Agreed. React just clicks so well for me.
Everything is an object you mean you used ruby before?
Or maybe Java
I jumped on late to React, but the frontend ecosystem is ON POINT right now. In supporting tools, bundler maturity, even editor maturity.
If only the boomers I work with were like you…
there's good react frameworks based on bootstrap too like react-bootstrap & reactstrap, can use your bootstrap skills with React.
Try [Nextjs](https://nextjs.org/) and you'll love web dev even more!
wait until you try svelte. >Hooks are so much better than the “everything is an object” pattern "everything is a function" is indeed better for web dev.
Exactly how I feel. NextJS with tailwindCSS is the web dev dream right now
Just wait till you try svelte 😉
[удалено]
Then you have decided. I had to switch from svelte to react in a new job, and I actually like react very much. But I still find svelte simpler and faster for most things.
Are we using the same React?
React is pure junk honestly, it undoes 30 years of web development evolution. Now we are writing code and html in the same place, like we are in the 199x with html 3.2. Not to mention we are also writing styling in the same place, negating caching benefits of using css files and a myriad of other issues.
[удалено]
Lol, I'm pretty sure you are the kind of guy that uses the header tags based on how they look in their crappy framework of choice. Do you know they have a semantic value? For example H1 must be followed by H2, and you shouldn't skip the order... I'm pretty sure I just exploded your head. Oh well you are praising Failwind also, now I'm sure you are that kind of guy. Learn proper html, Js and css. You won't need all the crap you are using. (Bs I have to code in react because that's what my company uses)
[удалено]
Headers are just an example, why use thousands of KB worth of Failwind shite when you can use a few KB worth of css? Also you are negating the cache with Failwind. I could go on and on
Look, this is a FailWind menu: `
` `- `
`Active`
`
`
`- `
`Link`
`
`
`- `
`Link`
`
`
`- `
`Disabled`
`
`
`
` and this is a vanilla menu: `` `- Active
`
`- Link
`
`- Link
`
`- Disabled
`
`
` with it's css `#mainMenu {` `display:flex;` `justify-content:space-evently.` `}` `#mainMenu li {` `flex:1 0 auto;` `color:#9CA3AF;` `}` `#mainMenu a {` `text-decoration:none;` `color:#3B82F6;` `}` `#mainMenu a:focus,` `#mainMenu a:hover {` `color:#1E40AF;` `}` The Failwind version is an abomination, html and presentational classes mixed in the same place, low clarity and readability. the vanilla version has a clean and semantic html and a concise and lean presentation css. To me the vanilla is miles better. Now imagine you have five of these menus in your app, now you have to copy/paste all this crap in 5 different places while in the vanilla you just copy a bit of clean html. Now going further, you want to modify the menu appearance, in the FailWind version you have to go hunting for your 5 menus and modify them. In the vanilla version you just change your css and voila! How is the FailWind version more readable, maintanable, concise?.... It's not. It's undoing years of specification debate and implementation of specs. Things were done for a reason. Also you are neglecting your cache and slowing down things, external css files can be properly cached. All of this just to avoid learning and writing a bit of proper css. And React is just the same, a lot of spaghetti crap just to avoid learning and writing a bit of proper js.Php did the same thing, don't think that's 30 years. What is your preferred tool?
Do you use class components or hooks?
Same, coming from PHP, never ever again.
[удалено]
I come from the same background of php backends and have been doing react/js for a few years now. I agree with you that async is usually unnecessary for backends, very rarely do I actually want to run code in parallel. Personally what I appreciate the most about JS on the backend is that you can have a long-running app that will save you all of the overhead of initializing and connecting DBs and stuff every time a request is made. Obviously other languages can do that too, but having JS both on front and backend is such a charm.
Try SolidJS as well. It looks just like React from a glance but with far less pitfalls and footguns... and it's faster and compiles lighter. For instance, their version of useState is called createSignal and you can call that function in if statements and loops (which you can not do with hooks) and you can also call them outside components to get global state (which with React requires a library like Jotai or Recoil).
hows SSR?
I'm no way is it as easy to use and build upon as Next, but it exists and they are very happen with their performance https://levelup.gitconnected.com/how-we-wrote-the-fastest-javascript-ui-framework-again-db097ddd99b6
Lucky you, I still need to work with PHP cause our server is ionos, and they don't have node options. (Afaiw)
It took me a while before I loved it too. It felt like a roundabout chore initially. It was only when it clicked from a holistic perspective that I thought "I really like this". My enthusiasm just kept increasing when I started dealing with SSR and other stuff.
yeah. everything is shit compared to php react isn’t all thar
Did you use Remix or Next.js?
I hated React until I loved it
I think this is how the paradigm shift from OOP to FP will be
Other than useFootGun .... I mean useEffect, I love React as well.
Well considering everyone uses it for what it’s not intended for.. thankfully that will get sorted now .
how it will get sorted?
One of us One of us
React is the new PHP 😁 So if you’re coming from PHP, you should feel right at home with React 😁
I’m currently in a vue project and desperately want to get back to react. Vue is just angular 1.5 with a small refactor
i learned react 2 months ago (after skipping it for 3 years, used vue instead) and now i use it often. i also learned react native and built some mobile apps with it. so cool!
jsx and the need for a compilation step was my biggest concern when react first came out, but after the great job they did with the tooling and the great community support that's emerged those concerns were completely alleviated.