Facebook wrote a language just for React (it's pretty cool)
2024 ж. 8 Сәу.
74 332 Рет қаралды
I know Flow isn't exactly cool, but these changes absolutely are. TypeScript may not adopt them but let a dev have some hope.
SOURCES
/ announcing-component-s...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
Why don't you guys write a browser and even a new OS for React? That would be so Meta...
A browser that truly, fully doesn't cache anything when you disable caching would be great. There have been many instances when you save, and no changes are reflected
@@ArcticPrimal Probably not happening soon, maybe a "VDOM is dead" article instead?
But there's ReactOS already...
@@kanbekan and it looks good
its all fun and games until some one does it
We have put a bandaid on the bandaid that was supposed to stop the bleeding from the previous bandaid so that you don't have to put more baindaids yourself over the bandaids you already have put.
this is how engineering works in every industry
Meta is the only company I know that thinks that you can fix a decapitation with bandaids.
hater detected
Prime is foaming at the mouth right now
I don't know how to react
go with the flow
@@theblackquill5921 am sure TypeScript will "render" flow useless
@@theblackquill5921 not my type
just don't get too hooked on it
Let's all remix!
Btw there is rescript, that has the same type system as Flow (H-M type inference, sound)
Exactly!
hindley-milner my beloved
It’s not the same type system. It’s a Hindley-Milner type system. It’s safer but also much more constrained. No true unions for example.
Rescript was the thing that convinced me to try react (when it was ReasonML+ReasonReact), it's just a javascript skin for OCaml with nice react bindings, was enjoyable to write but I don't know why they didn't go in on it harder. I remember reading they were refactoring the messenger frontend into it, but then not much since then.
Typescript is a general purpose language that transpiles to JS. It's not made (nor should it) obey the whims of a specific community or the perceived needs of any library, however popular it is. Also also, "I want this, I want this now", sure, move fast and break things but we are now past a certain point of maturity in frontend development, where React and Typescript are the Java of frontend. You have to move carefully in very small very unobtrusive steps.
Then, Typescript is not React... flow yes....
The latter point is more true of TypeScript than React. React is very replaceable, TypeScript (currently) has no real competition.
What would you think about upstreaming something like ts-patch to allow frameworks to move fast and add the language features they need on top of typescript without impacting TS?
It's so nice to have this information explained quickly, concisely, without too much decoration. I've been in front end over a decade now, and I'm annoyed I haven't found this channel sooner.
All he's doing is reading the article lol
@@happyjohn1656 and talking around the points of the article with context.
I personally think that Typescript helped React have more momentum, and the nice thing about React is (was?) that you could use a "normal" language you already know to work with it. If it goes with the route of a custom language, then it becomes a burden to work with it.
React already heavily relies on JSX, which is either a different language, or an extension to JS, depending on how you look at it. Facebook experimenting with JS syntax is not new
It just gives you better linting. The new syntax is like two extra keywords
@@deadchannel8431 plus new rules for how you call and use the function… you now have to context and know that this component keyword pre-processes your props and turns it into an object. I am not sure *another* way to call functions is a good idea, especially when it is not clear that this component keyword is doing all that magic.
Jsx is just like html@@eldarshamukhamedov4521
GOOD! Fewer people will use this crap.
When your framework is *so* convoluted and requires *so* much code to get working that you end up creating *two whole languages* to make it more palatable. 🤦
asm & C?
this is such a weird thing to complain about. most frameworks have some kind of dsl
@@saintgalgo That's fair, but not all frameworks that introduce a DSL do so in a way that requires an intermediate transpilation step. Many just leverage the already existing syntax to create helpers and/or abstractions without turning your code into something else entirely.
Didn't they already do that before with ReasonML or ReScript don't remember, might have just been the guy who made React not sure
seeing as Facebook tabs regularly take >2gigs of RAM I shall skip this video. thanks.
and it freezes every time until you decide to reload the page, huge downfall since they introduced e2e encrypted messages
How is it 2GB? I haven't opened facebook in a while but it only takes 36.7MB even after opening multiple chat and scrolling down a bit. A fresh youtube page use 219MB and this youtube as of this writing takes 500+ MB
Facebook uses PHP
WhatsApp web is shit
@@cherviliousyeah, he's either getting hacked, or exaggerating.
I've been working for a 5 years now, on a front end it seems like we have 10 new different ways to do the same fucking thing each year. That's why I work as a backend engineer now, I'm tired to learn new framework every half a year.
you mean learn new framework every two months
literally every industry has this "issue". you will not escape this "problem" by switching to backend. it's not even a problem. nobody's asking you to learn every new framework. employers to this day are still asking for php and python experience.
Unless you work at Facebook you don't need to learn this.
That's called competition and it's a part of life no matter the industry. Without it we wouldn't have a choice and would be stuck with one really bad product to choose from. I've been programming since 1986, and know that it can be frustrating having so many choices, but we're not forced into using all of them. Just pick one and stick with it.
Do you, just know you were never forced into it.
5:50 ->, thats y you always define an interface so that you can break it out like this "export default function HomeScreen({var1, var2, var3}: INTERFACE)" and make it so much nicer
Big problem with Flow is searching up anything about it. What a horrible name for SEO.
I'm constantly amazed at the poor names chosen re searchability for all software and libs etc. surprising how little thought people seem to put into that. "Go" was especially ridiculous, given it came from a Google employee.
@@HappyCheeryChap at least Go you can search Golang and get good results.
@@HappyCheeryChap Only makes it worse that a Go language had already existed before they created theirs too. The first Go developer tried to sue Google and because his was more of a DSL he lost, but I wish he had won and they'd used another name.
Someone in your chat log said "What if you want to use prop type as a whole?".. Your response was, but it's not something you do a lot.. But it's still very handy-> things like -> `ColorProp`, `DatasourceProps`, very handy to keep components consistent. eg. props: ColorProps & DatasourceProps. For very large apps having consistent prop types & names is very useful. I just destructure the props on the first line, const {color, datasource} = props; to save doing "props.color" etc, also having props is handy for prop drilling anyway, (but I try to avoid, if they get deep).
I think that props.color is more readable, because in longer components you know that props.color is from parent
@@untlsn It shouldn't be necessary to know whether `color` comes from parent, or from somewhere else (like a data fetch), or it's a local variable. The code of the component should behave the same regardless of the source of its value. It's also much easier to refactor when you want to change the source.
@@adtc I tell it from my experience. When I see wrong data on page and >{props.someValue}< in code, I know that issue is not in this component but in parent immediately
@@untlsn Object destructuring , or any other code shortcuts do indeed need to be used with care. Sometimes like you say that extra dot notation can give extra context, as a coder that's something you need to decide.
Are ts compiler plugins (a la babeljs) a thing in current timeline? I remember there was couple issues about it. Mostly because of stalled Ecmascript committee features. This would fit like a glove.
funny thing is that the recommended way of starting with react is by using a framework built on top of it like nextjs, yet there's not a word about flow in next's docs
Pretty cool. Certainly cuts down on the excess syntax and is clearer. The `renders` keyword is something sorely missing. Though the rest of it is pretty much already handled by the rules of React ESLint package elsewhere
The props thing is more tedious than you imagine, in Nrwl Nx, for some tools like StoryBook you need the props to be named "props", otherwise the tools can't find it and extract the props interface to generate StoryBook boilerplate based on that component, so in Nrwl Nx you need to destructure props inside the function body.
7:39 it looks like comparing function that takes object as only parametr vs function that takes multiple parameters. What if I want to pass 3 parameters that are all strings? Imo the first one is always easier to work with because when invoking the function (or rendering the component) I just open curly braces and see autocomplete and see what qre the props names instead of thinking "should I put userId, transactionId or other string first?"
one of the advantages of the prop-based methods was that order does not matter. now, it looks like order might matter, so that kind of sucks
From what I can tell, the order still doesn't matter, but the fact that things are basically the same just isn't obvious When you have a component declaration, you pass the arguments in like traditional order-based arguments for functions, but that gets compiled down to an object and name-based arguments/props I think it's a really bad idea. React devs are already used to doing things one way, so to not only break from that, but also add ambiguity around how the declaration even works isn't worth saving a handful of characters
Every framework could use domain specific language extension features. Expecially fullstack, something like TS extensions for NextJS.
we should have stop at two way binding.
I don't think TypeScript should include it BUT it would be cool if you could "extend" the compiler with these features
agreed; that'd also be immensely helpful for other frameworks that may want to introduce convenient syntax. TypeScript itself should remain general-purpose
It would be cool. But that sounds extremely difficult if not impossible
@@collinoly babel exists
I think that native named args would be nice in typescript itself
yeah and we will get React TS, Vue TS, Angular TS which will be different languages
9:20 it is very common when building stuff like a ui kit for example
Fun fact. No matter how many frameworks or languages are created for writing clean code and easy to read code most of the startups I worked for write shitty code that is disgusting and very hard to understand. Doing stupid things such aa declaring multiple components in one fuckin componets, creating context with fuckin createElement , no seperation of concerns putting everything in one big fuckin .js file , not following proper folder structure , horrible variable naming, hooks, components and the list goes on. Frontend is pain in the ass especially if you work for a shitty company that pays bare minimum to survive. 😪
I agree buddy i accidentally opened the js file in my office it's larger than 30k lines(angular) ...
Many components in one file is not bad when components are small and connected (e.g component and it's wrapper) But yes when file have over 200 lines we should split it
@@untlsn That's acceptable but they put all related components in one place making it big and hard to understand.
the issue is that there are too many ways to do things in javascript. i'm not a fan of elm, but we need a new language like that. where the language is designed around a specific pattern and also specifically designed to be used to build ui's. there are also too many dependencies and tooling you need to do anything in javascript. typescript is closer to a linter than a statically typed language. the whole ecosystem is like a band aid that's barely holding together. you can feel the clunkiness.
@@joeportnoy-qh9en Yes. But the ecosystem is too vast to get replaced. So many are dependent on js and we cannot simply replace it soon. Typescript is more like a linter , you are definitely correct on this one. But companies can simply implement good practices and avoid writing shitty code , which I think even if we create a new language they wont implement, they just want to get things done.
I want this now!
If you're at the level of creating new language just for React, there's already ClojureScript, Elm, PureScript, and ReasonML. Creating another JavaScript-but-not-exactly just for React is silly. It also shows that Reacts' model, while cool, has the issue of JavaScript not being the best language to implement it.
I wouldn't say JS is not the best language for React despite the many pitfalls in the language, it's more that React seems to be doing too much. Originally it was great to have HTML and JS in one file (and if you use Tailwind you get the whole package), now it's bastardised itself with great additions in theory that provide far too much mental overhead even when adjusting to it incrementally, and all forbid you do any of this in a large project. The problem seems to be less with the language and more with the framework, JS is already fast and React was fine since function components. Additions to this simply haevn't been helpful, though what this video covers is definitely implicitly useful for the ecosystem.
@@cyrus01337 Well, I still think it's not the bet language for React model and that's why React is fighting with JS. JS doesn't have immutable data (while Elm, ClojureScript, ReasonML, and PureScript do) so whole VDOM comparison process is not as performant as it could be with immutable data. JS doesn't have Algebraic Effects (or similar advanced flow-control primitives), so hooks are implemented in a "hacky" way, with special "rules of hooks" that you need to adhere to if you don't want to blow up your application. They look like functions but they're not functions. They work only in the React world. They're implemented via functions only because JS lacks better primitives for them. That's why React team is building compiler that is supposed to work out where to put useMemo and useCallback, etc... That's a sign that language they're using is not giving them tools they need.
Sure. Javascript is not the best. THats why we have typesscripy and its pretty good
Buy javascript is still better than some languages like java php... plenty good
More code rewrite? no thanks
And no one still fixed issue, when you open fb at mobile safari, through the some app, it throws an alert at your face.
Facebook is slower everyday 😅
im now interested in flow
sorry htmx pilled here
"I want this in typescript and I want it in typescript now"
also just convince them by giving them a cookie :)
can we have a typescript syntax plugins just like babel had with js
One can do crazy (read nonsense) stuff when unlimited resources are available.
Lets replace export default function !! Okay .. what about .. export default component ? Yeah we really needed to keep that public static void main(String[] args) type of stuff
exp def fn!
Ugh, you got me with the "clickbait" again. lol I was hoping it was something like Reason ML.
This kinda feels like Meta Build Systems (or Build System Generators) like CMake or Meson. Trying to solve the problem at the wrong level.
React is all about hype every quarter. We should name react as Hype Framework
I don’t think TypeScript should be adding React specific syntax. However, it would be really interesting to see if something like ts-patch could be upstreamed into TS. Technically this isn’t meant to support new syntax, but in practice as long as it can be parsed into an AST, it would be possible to do so. This would also allow implementing “real” typescript diagnostics for react (or any other framework) errors. The issue here though is that it leaves behind alternative compilers, as they all use different AST representations under the hood so it would be very difficult to implement this.
I just want these features to come to TypeScript
i could see like an swc plugin or an esbuild plugin to do this
Has anyone tried Flow and Rescript in recent months and can you compare?
What do you think of ReasonML?
I haven't used React in a while. Every time I hear something about React it sounds like the "meta" changed, which makes it very unappealing.
I hope this never gets into TypeScript, it’s too framework-specific. It would be great if there’d be some sort of more web standards based alternative in TS though
we ain't beating the allegations buds
Can you just use @hook and @component in TS if that's what you want?
Given that the whole JS ecosystem is transpilers, you can create a new language variant that has this and transpiles to standard TS.
Want it in TS and I want it NOW! lol.
I haven't looked into this at all, so take what I say with a grain of salt. It appears that Flow is different to ReScript due to the render types, but is otherwise mostly the same idea as ReScript, but with additional React Linting and a new syntax. Correct me if I am wrong in the comments.
This is the equivalent of seeing a todo app then recreating it from scratch just to add a small improvement on top.
Export default const?
it could be done in the same way svelte handles TS perhaps?
I'm kind of tired of the youtube thumbnail face, I guess on paper it does boost engagement though
It honestly makes me not want to watch it lol
Shouldn’t it be possible to implement this via annotations? I know typescript supports annotations eg in angular
How many frameworks and layers of abstraction can you possibly need just to create the same UI/UX that other websites already have? Frontend is such a deadweight sector.
How many layers of abstraction and rules will the meta add before it admits that React is a framework
@untlsn Show me a Web fronted that is not written in Javascript HTML and CSS. React is a framework, as is anything which takes away the ability to actually produce the end result without the intermediate tools.
@@GrumpyGrebo i know, but many peoples say that react is just a library
@untlsn It's a fun argument, and a trick. React is a domain specific language distributed as a library, with best practices and use patterns that make it more of a framework than comparable libraries. But it is not a full framework and can be integrated into full frameworks ie Next.js. You can just use React in a basic standalone HTML file, so it is technically a library. But you will be almost definitely be carving out the presentation layer of your application and building components which consume props using JSX, data bound to providers, component hooks, etc. React is a library, building in React makes it a framework. Infinite argument.
What about stuff that's not props, like forwardRef? How would you pass that in?
JavaScript should add a component keyword as syntactic sugar to web components, maybe that would reduce the clunky nature and improve adoption.
wow, writing a domain specific language looks nicer than adapting to an existing standard. shocker.
7:03 something on your mind Theo?
Flutter is taking Theos mind lol
Theo, are you saying even authors of the blog do not understand what some eslint rules are doing in React? What? They supposed to be the authors? No? They are the source of truth?
13:33 "Refs are getting an overhaul soon" I'm out of the loop, what's the overhaul?
React 19 (not yet released) removes the need for forwardref, and just makes ref a regular prop
@@hmerritt Oh that's neat, thanks for the info!
React should embrace own files like .vue, .svelte at this point
Mandatory XKCD comic strip number 927 :D (looks like a full link auto delete the comments :( ) edit: before anyone gets buthurt, that's a joke, it just made me think of the meme of the "new shiny js tooling of the week"
I don't see how anyone could disagree. It really is what they do with JavaScript and every offshoot thereof.
I think it would be unwise to add react specific features to typescript. If a framework wants its own DSL it should take ownership of that DSL and/or compiler, like solidsj or svelte
If you use flow, I am sorry for you.
Which is Theo's VSCode theme?
sooo... basically, flow is a DSL-ish on top of JS for React? just like Vala is built on top of GObject
honestly that props thing is kinda wierd. In normal fns params are positional, but here they are not. Would have preferred to keep the curly braces to keep those semantics
I'm in favour of this. I didn't think i would be because generally I'm pro "just copying the files onto a server and calling it a build process", but I think if you've already got JSX then you might as well commit to the bit and make a whole new language, and this seems nice. But yes, not switching to flow over this 🙃
For the love of all that is holy can we please please please use dark mode for reading web pages like this... you light mode users are destroying the eyes of so many of us night dwellers..
FR
it looks like compose .-.
Leave Javascript folks, it would be for the best
Will decorator be a good option?
Decorators don’t support functions other than methods at present. But yeah, they could be used as annotations to help a linter understand your code. They won’t add new syntax though so only would help with a very narrow subset of what was discussed here.
The only wish that React have is to get rid imports, it have only one job but it doesn't mean it should pile up on your source files.
"get rid import", what do you mean here?, if it's just `import * as React from "react"` , that's already possible, if you mean for all other imports, then no that's not a good idea.
Um, why are you looking to the side and not at the camera? Lol
Why not implement it in React? use_ for hooks, comp_ for components...
I don’t want typescript to bang on react features… typescript isn’t about react, but javascript. React already influences the js world enough so devs dunk on classes, mutable data structures and so on
Why not just reserve this syntax to tsx only?
What about instead fixing React to not have those restrictions in the first place? Then you'd not need any language features to enforce them.
shows how well reasonml went :/
React is wild these days
is this the new java….
O god
sorry so we don't need to learn Typescript anymore ya?
yeah, they have the same issue as Svelte with TS adoption. But I suppose Svelte anyway much simpler and better than React.
React becomes Flutter ... jk, that'd be the wrong take. Or would it? 👀
React HAD a great idea that UI = f(state), but somewhere FB took a wrong turn. Will vote for Vue.
Great idea in theory, bad in practice. It's too difficult to make immutability performant
@@omri9325Immutability is fine - proper functional programming languages handle it no problem, and can have really good performance The problem is enforcing immutability in a cross-paradigm language that wasn't built for immutability from the beginning (JavaScript). JS can't do any fancy optimizations or provide any niceties around structural sharing because it can't safely make any assumptions about what will or won't happen to the data
Prevously: UI = f(state) Now: UI = f(state) { backend_stuff, user interaction, forms_control }
woah i was fast
Ngl, I hate this. Adding more and more layers of abstraction and compile steps is getting ridiculous at this point. If it's so difficult to write react that you need to write a whole new language to deal with it better maybe react isn't a good abstraction in the first place.
guy talk about a language about react but does not talk about rescript are you serious
Dogfooding the rules of react
I'm glad I don't use react, lol
Glad I do, I have a job 😎
who tf uses flow? I'm sad that somewhere a dev is working on developing flow features.
Yet another devchan not using dark... How do you guys even see?
oh yeah it's awesome just keep creating new languages keep making shit up to keep your job. ridiculous.
... or you just could Angular and have something that allows clean code out of the box?