> Luau is a fast, small, safe, gradually typed embeddable scripting language derived from Lua.
> Around 2006, Roblox started using Lua 5.1 as a scripting language for games. Over the years the runtime had to be tweaked to provide a safe, secure sandboxed environment; we gradually started accumulating small library changes and tweaks.
Unfortunately not, it is the whole Compiler and VM. I'm not super familiar with embedding Luau only having messed around with it for a bit, but I highly doubt it'd be too difficult to drop in Luau over top an existing Lua implementation
Mostly that Lua datatypes don’t always have great analogs in TS (particularly tables) and you have to be pretty cognizant of what’s going on under the hood.
So hang on. "We had to customize Lua, but didn't contribute all those changes back upstream"? Or "We tried to contribute those changes upstream but Lua didn't want to take them onboard"?
PUC Lua uses a closed development model. They have a small team, and that team both decides what goes into the language, and writes the implementation themselves.
There are a great many implementations of Lua at this point, I'm aware of at least six. But Roblox upstreaming their semantic changes was never an option.
Of course it was: there is nothing preventing a company from contacting the dev team and going "we've one quite a bit of work, are you interested in getting any of that upstreamed". Getting changes upstreamed is in no way the exclusive domain of fully open source projects, it just requires reaching out.
Just because there's a closed development model doesn't automatically imply the devs team lives and breathes "not-invented-here"-ism and are no interested in discussing improvements that make a difference to actual people using Lua in (extremely) large real world products.
It was not a general statement, but rather, a specific one.
> Lua is not "open developed". The development is done exclusively by the
Lua team, at PUC-Rio. So, we do not need a SVN repository. Currently,
we keep Lua with the good old RCS.
Yes, I know, that was my point too: it's closed development and so you can talk to the dev team to get changes worked into Lua itself. You don't get to just open a PR and start thigns that way, you have to talk to people. And going "well we didn't contact them" when you're the size of Roblox would be incredible.
Any upstreaming was unlikely to ever be acceptable to the PUC-Rio folks.
PUC-Rio Lua uses C (with a tiny bit of C++ for stack unwinding on errors if folks don't want to use `longjmp()`,) Luau is strictly C++. Luau rewrites quite a lot of the core structures, and they aren't compatible. Further, Luau is a fork of PUC-Rio Lua _5.1_ (the current is 5.4 I think?) and intentionally picks and chooses features from later Lua versions. Even things like improvements to the core VM interpreter loop wouldn't be upstreamable, because Lua 5.2+ has a fundamentally different model to allow for yielding in metamethods. PUC-Rio would not accept changes other than fixes for critical bugs in Lua 5.1.
I like both PUC-Rio Lua and Luau, but a hard fork with no upstreaming was the only option here. The architectural differences of the VMs are so large now that it would amount to PUC-Rio adopting Luau. Supposing there is some tiny bit that PUC-Rio is interested in, they can cherry-pick it out of Luau, since they use the same license.
What a ridiculous thing to say. If you ran, or were part of, an academically run project, "you'd get mad" if a huge industry player went "hey we did some stuff with your project, some of it might be interesting to you, want to chat about potential upstreaming?"
Yes, because that is more burden to ensure that it still fits my purpose, the intended goals, and that whoever it is, is doing it properly.
Which would be the whole reason I would put such a statement there, in the first place.
What are you even trying to argue with now? That I'm not allowed to get angry in the hypothetical that I made up? Do you see why it's fruitless to continue arguing?
Or are you going to pick out some prior wording and analyse it further, because you just can't comprehend that corporations don't have best interests at heart, and some people prefer to just put things up and not deal with other people's improvements
PUC's Lua is, however, open source (https://www.lua.org/license.html), even if they don't solicit contributions, and they do accept happily accept financial support. It doesn't look like they release new versions very frequently at all (the last release was in over a year ago). Still, it appears they do accept financial contributions, so it seems like Roblox, whose market cap is $22 billion and whose offerings are at present entirely dependent on Lua, should probably consider offering at least token support (https://www.lua.org/thanks.html).
Why does the market cap allow you to decide about other people's projects? Lua is used in many places, and its users aren't all employees of Roblox. Lua is popular because it works in a way that sometimes breaks backward compatibility, making the language as easy and lean as it is. If there's a disagreement on how it should be used, just fork it like Roblox did.
More specifically, I know that Roblox uses lua(u) but I assumed this was all for scripting. React is a tool for building UI.
How do you use React inside Roblox? You can build UI? I'm trying to wrap my head around my clearly mistaken assumption that what was possible in Roblox was writing lua-ish scripts that handle events in Roblox and then alter the game flow. That's very different from a full UI element that manages state and presentation, which is why React was so exciting (ten years ago).
You can build UI in roblox, quite a fundamental piece of the puzzle, but you aren't forced into using react-lua, you can use whatever you want. The Roblox team uses react-lua for their roblox studio program, the desktop/mobile roblox app, and most plugins [1].
So to answer OP's question - yes, this port of React APIs in Lua is intended to be (and is being) used to render UI elements -- things like text boxes, windows, titles, buttons, etc.
> what was possible in Roblox was writing lua-ish scripts that handle events in Roblox and then alter the game flow.
Roblox is a game engine, like unity or unreal or godot, that produces games which run within their proprietary platform. But you still have to code the games from an empty starting point.
That's backwards. React is a tool for writing declarative UI (or declarative anything really) that can handle state updates. Probably they're using it because it's the best tool around for that job.
Well it depends if you're talking about React the UI library or React the increasingly popular underlying architecture. The former is vastly more popular by usage (I mean.. I assume) but the underlying approach to declarative-in-imperative turns out to work in other settings and seems to be gaining traction.
Sure but the essence of it, the reason that it works, is that it shims a declarative architecture into JS. It works because it turns out UI programming works better in a declarative style.The fact that that involves managing state is secondary.
I expect that in fifty years all programming will look declarative, either like HTML (which is sorta 'natively declarative') or more like React (which shims it into an imperative language).
That is a silly way to phrase it. It's secondary in the sense that of course a UI framework has to manage state. They all do that if they're complex at all. The state management is not what distinguishes React from other frameworks; it is distinguished by the (pseudo-)declarative API that it presents to the programmer.
In react's model, all state is owned by a particular component instance. Most react devs opt for a 3rd party tool for shared state. I would not say that react is good at this.
This hasn't really been true for a while, most React projects that I encounter nowadays don't opt for things like Redux or MobX, they just use React Contexts. Which isn't a third party thing anymore
When context first came out, there was a buzz about it was going to obsolete Redux. Then it was actually "no it's not". I haven't followed it much since then. I haven't seen a code base that used a context for shared state that could be updated from descendant nodes. But I guess it pretty much has to be an improvement over redux.
Still though, the boilerplate required to do it doesn't make it seem like React is particularly good at it, even though it's technically capable.
Context is not an "improvement" over Redux, because they are different tools with different purposes. (This is the primary misunderstanding people have when they try to compare Context and Redux.)
Context is a Dependency Injection tool for a single value, used to avoid prop drilling.
Redux is a tool for predictable global state management, with the state stored outside React.
Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state you are managing, or whatever other value you're passing through it (event emitter, etc).
I wrote an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them - I'd recommend reading through this:
Thanks for the info. I'd say you're speaking from some position of authority about what redux is and isn't. And to some degree, what react context is and isn't. I vaguely recall seeing this blog post before, maybe.
So redux is for "managing and updating" shared state. And context is for "sharing values". All this seems to suggest that react actually isn't that good at shared state, at least when it can change.
React is based on the core concepts of encapsulated components, with the ability to manage state on a per-component-instance basis, and for parent components to pass _any_ values they want to their children as props, forming a "one-way data flow" approach.
This is _good_, because it both enables predictable behavior and React's overall rendering model.
It's _limiting_, because it means that React's own state management is inherently tree-shaped. If two widely separated components need to access the same data, you have to hoist the ownership of that state up to the nearest common ancestor, which could easily be the root `<App>` component. To put it another way, not all state is inherently tree-shaped, so there's often a mismatch.
Context is essentially "props at a distance". Put a value in a `<MyContext.Provider>` component somewhere in your tree, then any deeply nested component can read it via `useContext(MyContext)` without having to explicitly pass the value as a prop through however many intervening levels of components.
This simplifies making values accessible to that subtree, but doesn't solve the tree-vs-nontree-shaped state management question.
You _can_ build an entire app out of nothing but React component state. Plenty of folks have done it, but it's limited in what tools you have available and how you can structure things.
That's a large part of why there have been so many different state management libraries created for React, to provide alternative approaches that don't have the tree-shaped issue.
> I haven't seen a code base that used a context for shared state that could be updated from descendant nodes.
I use this pattern commonly. You put a state-update callback into the context.
It's my favorite go-to when I don't want to bother writing all that Redux boilerplate (state description plus accessors plus reducers feels... Half-baked).
Note that Redux usage patterns have changed significantly since 2019. Modern Redux with our official Redux Toolkit package is drastically simpler and easier to use than the original legacy hand-written patterns:
You could write react in Lua for a while, for example for Roblox. And, it's very cool. There's also another project that compiles typescript to Lua: https://roblox-ts.com
And that one supports writing pretty much actual React tsx but with Roblox primitives.
One of my clients asked me to make a Roblox plugin, it was my first time, and I was very pleasantly surprised with this workflow. There are also tools to enable really high iteration speed. It felt nicer than Unity at some moments. I didn't really need to write or know any Lua at all!
> When possible, upstream flowtype and definitely-typed types have been translated into Luau type annotations.
> This repository is a fork of roblox/react-lua with the intention of being the Roblox and global Lua community go-to for React in Lua. Roblox's repository is a read-only mirror of their internal project, and as such cannot be contributed to by the community.
It’s all tongue-in-cheek references to stereotypes around what would now be called toxic masculinity/gatekeeping.
Of the Fortran programmers (real, manly programmers in this story) it says:
> Besides, the determined Real Programmer can write FORTRAN programs in any language.
In this vein there’s also the story of Mel the Programmer, a “Real Programmer” who would never stoop so low as to use so abstract a programming language as FORTRAN. Funny how perspectives change over time.
When I started to learn to code, we were supposed to be dismissive of the Java wimps, but now I think it is Python that is too convenient to be cool. It’s all very silly and anyone that takes it seriously should be regarded with suspicion I think.
Looking at it's parity list its missing quite a lot, that's not the issue as this seems to be a for fun project (or masochism) but at what point is it considered react? It's unclear to me.
Poorly written React (which is a lot of it) has terrible performance. Properly written React (just like properly written anything) has great performance.
The reason you experience it as terrible is because it's today's visual basic: it's so easy to start with that everyone does, without needing to understand programming or specifically how React works. You can just throw shit together and it'll work. It's empowered an entire generation of web and app makers, with the cost being "and they're not good at that, through no fault of their own, but they are just good enough to be dangerous".
It isn't even that new, in terms of approach... a LOT of game and simulation would work with state driven rendering... each frame is rendered against the current state. Similar workflows to React+Redux were in pretty broad use, the tools just brought it to web development... from there, React as a model for UI abstraction became more popular for other applications outside web use. It makes a lot of sense.
If you already understand the idea behind state driven updates, you're already writing better React than the majority of folks using it. React made it easy enough to write working UIs without having a clue what's actually happening, when, and why. (which is also why there's a never-ending stream of stackoverflow questions about why obvious state mutations don't immediately kick in)
Roblox client does as much as possible in Lua(u). It's somewhat well known that Luau is the language Roblox games are scripted in, but even before you enter a game, for the sake of portability everything is written as much as possible in Luau.
Avatar selection screens, groups, settings etc. all make for a huge number of different screens, so I'm assuming they want React to better coordinate making all that GUI between the huge number of internal devs they must have.
Just my guess, I've personally never used React and am not 100% on whether the Roblox app uses React-lua internally or not.
No one cares of complexity if it’s hidden behind a reasonable interface. RDBMS and the async coroutine module in your language runtime are the examples of insane complexity done right. Most of these frameworks contain a very reasonable interface, at least compared to r-nonsense. So glad that people start to awaken from this fever dream.
But that is exactly the issue with React imo.
In React needless complexity isn't hidden away, its front and center.
Frameworks like Svelte do a far better job hiding and managing actual complexity.
This question seems misaligned(?). The idea is that it's easier to work with and harder to fail when complexity is hidden beyond a good interface. The complexity of a good UI framework's interface is low by definition. React exposes way too many moving parts and has way too many breakable rules to be called good. All UI frameworks may be as complex as they want, the interface is what matters for an end-developer.
Svelte's interface is basically "I will re-execute top-level statements starting with $:".
Vue's interface is "I bound your data to html, feel free to update it, but beware of []-nuances".
React's interface is "You have to use state and effect wrappers, but don't effect in non-effect blocks (and read what an effect is!), also always make copies of everything, and we can run your code twice, and if you if (), then make sure you don't if () in an inappropriate place, anyway, imagine you're in a pure functional language, but you aren't really, so do that by hand and don't mess it up, we warned you".
Out of React, Vue & Svelte I much prefer Svelte's approach since its the closest you can get to vanilla javascript. But I suppose we're getting pretty off topic at this point.
When I want to do two tabs on a UI that share state (but provide two wildly different views on it), how does one do that in Svelte?
Just add all the components, hide / show the tabs with styling when one or the other should be visible, and accept that state updates will be firing to attempt to re-render invisible components in the other tab?
(This isn't a criticism; I'm trying to wrap my head around the pros and cons of Svelte vs. React. React's approach would be that only one or the other tab renders, so you don't burn cycles updating state on the invisible tab because it doesn't exist in the DOM).
It's React who taught a whole new generation of developers that invisible can be re-rendered (also that generating vdom nodes is called "render" for some reason).
First, invisible things, both d-none or v-hidden, usually don't even have any sort of a graphical context to re-render themselves in, and when they do, it just gets invalidated. Sizing nuances apply to v-hidden, but if you chose it over d-none, it's reasonably consequential.
Second, you don't have to worry about it at all, unless it's quadratic+ for some reason or is covered by performance requirements as unacceptable.
I was thinking more about all the computation to decide what the properties should be of hidden elements, not the actual render state as in "pixels on a screen." (It is unfortunate that React kind of disrupted the terminology around this!).
IIUC unless I'm missing something, if I'm using Vue to drive, say, a list of thirty elements on the page from a JavaScript array somewhere, then when I update the array I'm still going to want to do all the text slicing, splicing, element creation, &c even if the entire list of thirty elements is hidden (and this won't be as expensive as it'd be if the list were visible - cost deferred until the object is actually visible and needs layout and render - but the JavaScript to set up its state is still running). Whereas in React, the fact the component that's parent to the list isn't in the DOM at all means the update logic for the list state wouldn't fire at all, no matter how many change events occurred.
(I'm sure you can do something similar in Vue, by detaching listeners when a given element is hidden).
Vue uses a similar (well, now ubiquitous) vdom technology, which can be used directly instead of templates, which simply transpile to it. I think this idea (afaiu) that vue has to do more work than react due to hierarchy etc isn’t correct. If there’s no dom bound to data.a[b].c, then nothing happens. If you think that vue templates still have to be regenerated, resliced and so on, then that also happens only once and results in a function which can be called to “render” vdom. https://codedamn.com/news/vuejs/exploring-vuejs-compiler-tem...
Sorry if I got you wrong. But it’s not the first time I think I see these wrong ideas about how “React is better”. I blame React itself, cause not only it redefined the terms, but also pushed this vague “compared to a regular detergent” agenda everywhere. It’s much less of a library than of pure religious movement with strawmen and fallacies.
Svelte will work here the same way that React does. If a component/element isn't mounted it will not render or update.
Where Svelte has an advantage is that:
1. A lot of stuff is built in, but extendable/replaceable. Styling, animations, basic state management, ...
2. It's update model makes it easier to use vanilla libraries without the need for any react-x wrappers.
3. The update model is also easier to use in general. The amount of stale closures and referential equality issues I have to fight every time I do something in react is insane.
Of what commercial use are the funny, animating widgets?
At this point frameworks like React exist just to generate employment for software developers, like the Federal reserve exists for economists.
I've had enough experience with 10-person teams trying to synchronize code for a large UI to think otherwise.
Trying to do that with "just HTML, CSS & JS" either dooms the project or ends up with the team implementing their own flavor of React (or something else) to standardized complicated state update in a modular fashion that allows sharing code.
Not everyone needs React, but when you do, it's nice not to have to reinvent the wheel.
Facebook is one. So is Google Cloud's dashboard. Basically anything where a single UI will be serving multiple separable concerns (that could be handed to multiple separate teams in a large org).
Because it is cool to hate on React on hn. Write something in Rust and watch everyone swoon, but mention anything that uses React and the comments will be filled with people hating all over it. As is the way on hn.
You're right about the disproportionate hate for React, but your information about Rust is out of date. These days it's 50-50 whether you'll get a lot of love or hate for a Rust project, and several of the top-upvoted Rust posts of the past year are disenchanted ones.
Lua is a great language, I happen to be a lot productive with it, its simplicity reminds me that of C. You don’t fight the language, you actually implement things
> You don’t fight the language, you actually implement things
roflcopter. While in general one could say that about basically any language, this is RICH for Lua.
You implement things...
Over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over.
Because every person writing Lua thinks they’re gods gift to Lua. Only their bespoke implementation of THING is correct. Often due to some pedantic definition of “performance”. The ecosystem blows chunks; Luarocks is an unfunny joke.
I’m not sure why a language born to be embedded should have such an ecosystem, the C environment you embed it in is the ecosystem. For example I use it mostly with love2d for games and tools development, love2d is my ecosystem, sure I can look for libraries on GitHub, but I feel like it’s pretty much the same I would do for C header only libraries for example. LuaRocks is ok, imo still better than the gigantic mess NPM is, that’s not an ecosystem that’s a landfill
I think that was sort of their point argument. You could say the same thing about Python too.
The insinuation that you can’t be serious with those languages is silly though. I mean, Instagram runs on Python and a lot of really awesome applications still run on JavaScript. So while you can do terrible things with the freedom of dynamic languages, you aren’t forced to be a maniac by them either.
It's a hard comment to parse but I think the advocacy is to set a conceptual intellectual ceiling to keep it gentle and approachable to a wide younger audience kinda like Bill Kendrick's TuxPaint.
Some background for anyone interested: The project is a fork of `roblox/react-lua` to basically open it up for community engagement and it uses Luau
Roblox's Luau: https://luau-lang.org/
> Luau is a fast, small, safe, gradually typed embeddable scripting language derived from Lua.
> Around 2006, Roblox started using Lua 5.1 as a scripting language for games. Over the years the runtime had to be tweaked to provide a safe, secure sandboxed environment; we gradually started accumulating small library changes and tweaks.
Interesting.
I'd love to have type annotations in Lua.
But this doesn't compile to Lua, right?
Unfortunately not, it is the whole Compiler and VM. I'm not super familiar with embedding Luau only having messed around with it for a bit, but I highly doubt it'd be too difficult to drop in Luau over top an existing Lua implementation
Thanks!
I found Teal, which seems to Lua what TypeScript is to JavaScript
There's also a Typescript to Lua transpiler https://typescripttolua.github.io/
I've used it successfully with Love2d projects (albeit with some quirks)
Lol, that's great.
What are the quirks?
Mostly that Lua datatypes don’t always have great analogs in TS (particularly tables) and you have to be pretty cognizant of what’s going on under the hood.
All of these, too: https://typescripttolua.github.io/docs/caveats
I use Teal for Pico8 game development. It's great.
Interesting, what do they do about missing type info? Is there some repo of types for popular libraries?
There's the official teal-types[1] project that aims to fill that gap only for standard Lua. I've used the LÖVE types[2] in the past.
1: https://github.com/teal-language/teal-types/tree/master/type... 2: https://github.com/MikuAuahDark/love2d-tl
No idea, probably nothing.
No, Luau is a new programming language that's based on Lua.
So hang on. "We had to customize Lua, but didn't contribute all those changes back upstream"? Or "We tried to contribute those changes upstream but Lua didn't want to take them onboard"?
PUC Lua uses a closed development model. They have a small team, and that team both decides what goes into the language, and writes the implementation themselves.
There are a great many implementations of Lua at this point, I'm aware of at least six. But Roblox upstreaming their semantic changes was never an option.
Of course it was: there is nothing preventing a company from contacting the dev team and going "we've one quite a bit of work, are you interested in getting any of that upstreamed". Getting changes upstreamed is in no way the exclusive domain of fully open source projects, it just requires reaching out.
Just because there's a closed development model doesn't automatically imply the devs team lives and breathes "not-invented-here"-ism and are no interested in discussing improvements that make a difference to actual people using Lua in (extremely) large real world products.
It was not a general statement, but rather, a specific one.
> Lua is not "open developed". The development is done exclusively by the Lua team, at PUC-Rio. So, we do not need a SVN repository. Currently, we keep Lua with the good old RCS.
- Roberto Ierusalimschy
http://lua-users.org/lists/lua-l/2007-09/msg00476.html
Yes, I know, that was my point too: it's closed development and so you can talk to the dev team to get changes worked into Lua itself. You don't get to just open a PR and start thigns that way, you have to talk to people. And going "well we didn't contact them" when you're the size of Roblox would be incredible.
Any upstreaming was unlikely to ever be acceptable to the PUC-Rio folks.
PUC-Rio Lua uses C (with a tiny bit of C++ for stack unwinding on errors if folks don't want to use `longjmp()`,) Luau is strictly C++. Luau rewrites quite a lot of the core structures, and they aren't compatible. Further, Luau is a fork of PUC-Rio Lua _5.1_ (the current is 5.4 I think?) and intentionally picks and chooses features from later Lua versions. Even things like improvements to the core VM interpreter loop wouldn't be upstreamable, because Lua 5.2+ has a fundamentally different model to allow for yielding in metamethods. PUC-Rio would not accept changes other than fixes for critical bugs in Lua 5.1.
I like both PUC-Rio Lua and Luau, but a hard fork with no upstreaming was the only option here. The architectural differences of the VMs are so large now that it would amount to PUC-Rio adopting Luau. Supposing there is some tiny bit that PUC-Rio is interested in, they can cherry-pick it out of Luau, since they use the same license.
> The development is done exclusively by the Lua team, at PUC-Rio. So, we do not need a SVN repository.
If I had this as my message, and someone asked to ship changes, I would be more than mad.
just take the L dude.
What a ridiculous thing to say. If you ran, or were part of, an academically run project, "you'd get mad" if a huge industry player went "hey we did some stuff with your project, some of it might be interesting to you, want to chat about potential upstreaming?"
really, dude?
Yes, because that is more burden to ensure that it still fits my purpose, the intended goals, and that whoever it is, is doing it properly.
Which would be the whole reason I would put such a statement there, in the first place.
What are you even trying to argue with now? That I'm not allowed to get angry in the hypothetical that I made up? Do you see why it's fruitless to continue arguing?
Or are you going to pick out some prior wording and analyse it further, because you just can't comprehend that corporations don't have best interests at heart, and some people prefer to just put things up and not deal with other people's improvements
PUC's Lua is, however, open source (https://www.lua.org/license.html), even if they don't solicit contributions, and they do accept happily accept financial support. It doesn't look like they release new versions very frequently at all (the last release was in over a year ago). Still, it appears they do accept financial contributions, so it seems like Roblox, whose market cap is $22 billion and whose offerings are at present entirely dependent on Lua, should probably consider offering at least token support (https://www.lua.org/thanks.html).
Why does the market cap allow you to decide about other people's projects? Lua is used in many places, and its users aren't all employees of Roblox. Lua is popular because it works in a way that sometimes breaks backward compatibility, making the language as easy and lean as it is. If there's a disagreement on how it should be used, just fork it like Roblox did.
-
Wouldn't this let you run a front end on the edge with Nginx??? Sounds fun!
I wrote Vleam[0], which is the equivalent to this, but for Vue and Gleam.
The more options like this, the better. Especially for existing ecosystems.
[0] https://github.com/vleam/vleam
I think the equivalent would be if you ported Vue to the beam, but impressive work nonetheless!
As others here have mentioned, why React?
More specifically, I know that Roblox uses lua(u) but I assumed this was all for scripting. React is a tool for building UI.
How do you use React inside Roblox? You can build UI? I'm trying to wrap my head around my clearly mistaken assumption that what was possible in Roblox was writing lua-ish scripts that handle events in Roblox and then alter the game flow. That's very different from a full UI element that manages state and presentation, which is why React was so exciting (ten years ago).
You can build UI in roblox, quite a fundamental piece of the puzzle, but you aren't forced into using react-lua, you can use whatever you want. The Roblox team uses react-lua for their roblox studio program, the desktop/mobile roblox app, and most plugins [1].
[1]: https://devforum.roblox.com/t/how-to-react-roblox/2964543
So to answer OP's question - yes, this port of React APIs in Lua is intended to be (and is being) used to render UI elements -- things like text boxes, windows, titles, buttons, etc.
> what was possible in Roblox was writing lua-ish scripts that handle events in Roblox and then alter the game flow.
Roblox is a game engine, like unity or unreal or godot, that produces games which run within their proprietary platform. But you still have to code the games from an empty starting point.
Seems to be the React/DOM conceptual model that has been "ported". Here is an example from the Robolox repo - https://github.com/Roblox/react-lua/blob/main/examples/chang...
React is a tool for managing state. The UI component is somewhat secondary.
That's backwards. React is a tool for writing declarative UI (or declarative anything really) that can handle state updates. Probably they're using it because it's the best tool around for that job.
That parenthetical “or anything declarative really” is doing a lot of work, given that:
React is a tool for writing 3D scenes that can handle state updates: https://github.com/pmndrs/react-three-fiber
React is a tool for writing music that can handle state updates: https://github.com/FormidableLabs/react-music
React is a tool for writing infrastructure-as-code templates that… um… could with some additional work handle state updates: https://www.linkedin.com/pulse/aws-terraform-generator-using...
Well it depends if you're talking about React the UI library or React the increasingly popular underlying architecture. The former is vastly more popular by usage (I mean.. I assume) but the underlying approach to declarative-in-imperative turns out to work in other settings and seems to be gaining traction.
React manages the state of the UI, all the props and the virtual DOM counts as state.
The declarative part is that the UI is recomputed from the state sorta-ex-novo at each update
Sure but the essence of it, the reason that it works, is that it shims a declarative architecture into JS. It works because it turns out UI programming works better in a declarative style.The fact that that involves managing state is secondary.
I expect that in fifty years all programming will look declarative, either like HTML (which is sorta 'natively declarative') or more like React (which shims it into an imperative language).
State management is not secondary, it is how it can implement the declarative UI with declarative updates.
That is a silly way to phrase it. It's secondary in the sense that of course a UI framework has to manage state. They all do that if they're complex at all. The state management is not what distinguishes React from other frameworks; it is distinguished by the (pseudo-)declarative API that it presents to the programmer.
New Shimmer is a Floor Wax AND a Desert Topping!
https://www.tiktok.com/@user2571420815968/video/720501112959...
But both the JavaScript and Lua versions of React are full of high fructose corn syrup, anyway.
https://www.youtube.com/watch?v=H_zsZMn5Efk
I'd prefer a low-calorie high-performance port of Svelte to Lua.
https://www.youtube.com/watch?v=T6EVgwMfzb0
when htmx.lua
React is one tool for managing state. Still doesn't answer why
It's a good tool for managing state, especially state that, well, reacts to messages about changes in shared state.
In react's model, all state is owned by a particular component instance. Most react devs opt for a 3rd party tool for shared state. I would not say that react is good at this.
This hasn't really been true for a while, most React projects that I encounter nowadays don't opt for things like Redux or MobX, they just use React Contexts. Which isn't a third party thing anymore
When context first came out, there was a buzz about it was going to obsolete Redux. Then it was actually "no it's not". I haven't followed it much since then. I haven't seen a code base that used a context for shared state that could be updated from descendant nodes. But I guess it pretty much has to be an improvement over redux.
Still though, the boilerplate required to do it doesn't make it seem like React is particularly good at it, even though it's technically capable.
Hi, I'm a Redux maintainer.
Context is not an "improvement" over Redux, because they are different tools with different purposes. (This is the primary misunderstanding people have when they try to compare Context and Redux.)
Context is a Dependency Injection tool for a single value, used to avoid prop drilling.
Redux is a tool for predictable global state management, with the state stored outside React.
Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state you are managing, or whatever other value you're passing through it (event emitter, etc).
I wrote an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them - I'd recommend reading through this:
- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
Thanks for the info. I'd say you're speaking from some position of authority about what redux is and isn't. And to some degree, what react context is and isn't. I vaguely recall seeing this blog post before, maybe.
So redux is for "managing and updating" shared state. And context is for "sharing values". All this seems to suggest that react actually isn't that good at shared state, at least when it can change.
I'd both agree and disagree with that.
React is based on the core concepts of encapsulated components, with the ability to manage state on a per-component-instance basis, and for parent components to pass _any_ values they want to their children as props, forming a "one-way data flow" approach.
This is _good_, because it both enables predictable behavior and React's overall rendering model.
It's _limiting_, because it means that React's own state management is inherently tree-shaped. If two widely separated components need to access the same data, you have to hoist the ownership of that state up to the nearest common ancestor, which could easily be the root `<App>` component. To put it another way, not all state is inherently tree-shaped, so there's often a mismatch.
Context is essentially "props at a distance". Put a value in a `<MyContext.Provider>` component somewhere in your tree, then any deeply nested component can read it via `useContext(MyContext)` without having to explicitly pass the value as a prop through however many intervening levels of components.
This simplifies making values accessible to that subtree, but doesn't solve the tree-vs-nontree-shaped state management question.
You _can_ build an entire app out of nothing but React component state. Plenty of folks have done it, but it's limited in what tools you have available and how you can structure things.
That's a large part of why there have been so many different state management libraries created for React, to provide alternative approaches that don't have the tree-shaped issue.
> I haven't seen a code base that used a context for shared state that could be updated from descendant nodes.
I use this pattern commonly. You put a state-update callback into the context.
It's my favorite go-to when I don't want to bother writing all that Redux boilerplate (state description plus accessors plus reducers feels... Half-baked).
Note that Redux usage patterns have changed significantly since 2019. Modern Redux with our official Redux Toolkit package is drastically simpler and easier to use than the original legacy hand-written patterns:
- https://redux.js.org/tutorials/essentials/part-2-app-structu...
- https://redux.js.org/introduction/why-rtk-is-redux-today
How did you come to this conclusion?
You could write react in Lua for a while, for example for Roblox. And, it's very cool. There's also another project that compiles typescript to Lua: https://roblox-ts.com
And that one supports writing pretty much actual React tsx but with Roblox primitives.
One of my clients asked me to make a Roblox plugin, it was my first time, and I was very pleasantly surprised with this workflow. There are also tools to enable really high iteration speed. It felt nicer than Unity at some moments. I didn't really need to write or know any Lua at all!
I'm reading the docs and it's very unclear if this project is for Lua or Luau (the Roblox derivative).
Luau and Roblox..
> When possible, upstream flowtype and definitely-typed types have been translated into Luau type annotations.
> This repository is a fork of roblox/react-lua with the intention of being the Roblox and global Lua community go-to for React in Lua. Roblox's repository is a read-only mirror of their internal project, and as such cannot be contributed to by the community.
I read tfa. If we sit here and quote all lines that say "Lua" we'll be in for a long list as well.. including the project NAME no less.
Ancient quiche eater wisdom has it that you can write Fortran in any language. In that vein, React in Lua is not too much of a surprise.
I'm curious about what "quiche eater" means in this context. I have not run into that before.
It’s a reference to:
https://en.m.wikipedia.org/wiki/Real_Programmers_Don't_Use_P...
Which is itself a reference to:
https://en.m.wikipedia.org/wiki/Real_Men_Don%27t_Eat_Quiche
It’s all tongue-in-cheek references to stereotypes around what would now be called toxic masculinity/gatekeeping.
Of the Fortran programmers (real, manly programmers in this story) it says:
> Besides, the determined Real Programmer can write FORTRAN programs in any language.
In this vein there’s also the story of Mel the Programmer, a “Real Programmer” who would never stoop so low as to use so abstract a programming language as FORTRAN. Funny how perspectives change over time.
Fascinating. Haven't heard of these despite coding for 30 years. Probably because I started with Pascal.
When I started to learn to code, we were supposed to be dismissive of the Java wimps, but now I think it is Python that is too convenient to be cool. It’s all very silly and anyone that takes it seriously should be regarded with suspicion I think.
Python is the new VBA
Primagen mentioned.
Looking at it's parity list its missing quite a lot, that's not the issue as this seems to be a for fun project (or masochism) but at what point is it considered react? It's unclear to me.
I bet they exploited child labor to develop it.
https://www.youtube.com/watch?v=n6PYj93SGxc
This is unholy and cursed
Another library/documentation that commits the sin of not showing any examples
I don't even like writing React in Javascript
React has terrible performance
Poorly written React (which is a lot of it) has terrible performance. Properly written React (just like properly written anything) has great performance.
The reason you experience it as terrible is because it's today's visual basic: it's so easy to start with that everyone does, without needing to understand programming or specifically how React works. You can just throw shit together and it'll work. It's empowered an entire generation of web and app makers, with the cost being "and they're not good at that, through no fault of their own, but they are just good enough to be dangerous".
It isn't even that new, in terms of approach... a LOT of game and simulation would work with state driven rendering... each frame is rendered against the current state. Similar workflows to React+Redux were in pretty broad use, the tools just brought it to web development... from there, React as a model for UI abstraction became more popular for other applications outside web use. It makes a lot of sense.
If you already understand the idea behind state driven updates, you're already writing better React than the majority of folks using it. React made it easy enough to write working UIs without having a clue what's actually happening, when, and why. (which is also why there's a never-ending stream of stackoverflow questions about why obvious state mutations don't immediately kick in)
In fact, afair react was made to make the page faster. (as dom manipulation was WAY slower back then)
It has adequate performance and the ease of development is worth it not being the most performant way to do things.
React is eating the world
...like lung cancer and we keep smoking
[dead]
[flagged]
Roblox client does as much as possible in Lua(u). It's somewhat well known that Luau is the language Roblox games are scripted in, but even before you enter a game, for the sake of portability everything is written as much as possible in Luau.
Avatar selection screens, groups, settings etc. all make for a huge number of different screens, so I'm assuming they want React to better coordinate making all that GUI between the huge number of internal devs they must have.
Just my guess, I've personally never used React and am not 100% on whether the Roblox app uses React-lua internally or not.
I'm just lightly poking fun. React is not something I personally like working with.
[flagged]
[flagged]
What should replace it? As the mainstream standard for boilerplate UI lifecycle code and a bit of component stuff
Oh idk let me think.. off the top of my head: - Vue - Svelte - Solid - Qwik - Alpine - Lit Or better yet HTMX
Vue, Svetle, etc. is roughly same level of shit complexity as react; htmx is interesting actually.
No one cares of complexity if it’s hidden behind a reasonable interface. RDBMS and the async coroutine module in your language runtime are the examples of insane complexity done right. Most of these frameworks contain a very reasonable interface, at least compared to r-nonsense. So glad that people start to awaken from this fever dream.
But that is exactly the issue with React imo. In React needless complexity isn't hidden away, its front and center. Frameworks like Svelte do a far better job hiding and managing actual complexity.
How is Svetle complexity is different and why is JS-vanilla-like Svetle complexity is better than React-like complexity?
This question seems misaligned(?). The idea is that it's easier to work with and harder to fail when complexity is hidden beyond a good interface. The complexity of a good UI framework's interface is low by definition. React exposes way too many moving parts and has way too many breakable rules to be called good. All UI frameworks may be as complex as they want, the interface is what matters for an end-developer.
Svelte's interface is basically "I will re-execute top-level statements starting with $:".
Vue's interface is "I bound your data to html, feel free to update it, but beware of []-nuances".
React's interface is "You have to use state and effect wrappers, but don't effect in non-effect blocks (and read what an effect is!), also always make copies of everything, and we can run your code twice, and if you if (), then make sure you don't if () in an inappropriate place, anyway, imagine you're in a pure functional language, but you aren't really, so do that by hand and don't mess it up, we warned you".
Agree completely, but if you "need" that level of complexity, I'd rather be working with Vue or Svelte.
Idk, does the same thing, but aestetically looks different. I guess I'm bigger fan of JSX than whatever Svelte approach is named.
But then, if I'd had a choice to work with next.js or pile of cow crap, I'd prefer crap.
Out of React, Vue & Svelte I much prefer Svelte's approach since its the closest you can get to vanilla javascript. But I suppose we're getting pretty off topic at this point.
When I want to do two tabs on a UI that share state (but provide two wildly different views on it), how does one do that in Svelte?
Just add all the components, hide / show the tabs with styling when one or the other should be visible, and accept that state updates will be firing to attempt to re-render invisible components in the other tab?
(This isn't a criticism; I'm trying to wrap my head around the pros and cons of Svelte vs. React. React's approach would be that only one or the other tab renders, so you don't burn cycles updating state on the invisible tab because it doesn't exist in the DOM).
It's React who taught a whole new generation of developers that invisible can be re-rendered (also that generating vdom nodes is called "render" for some reason).
First, invisible things, both d-none or v-hidden, usually don't even have any sort of a graphical context to re-render themselves in, and when they do, it just gets invalidated. Sizing nuances apply to v-hidden, but if you chose it over d-none, it's reasonably consequential.
Second, you don't have to worry about it at all, unless it's quadratic+ for some reason or is covered by performance requirements as unacceptable.
I was thinking more about all the computation to decide what the properties should be of hidden elements, not the actual render state as in "pixels on a screen." (It is unfortunate that React kind of disrupted the terminology around this!).
IIUC unless I'm missing something, if I'm using Vue to drive, say, a list of thirty elements on the page from a JavaScript array somewhere, then when I update the array I'm still going to want to do all the text slicing, splicing, element creation, &c even if the entire list of thirty elements is hidden (and this won't be as expensive as it'd be if the list were visible - cost deferred until the object is actually visible and needs layout and render - but the JavaScript to set up its state is still running). Whereas in React, the fact the component that's parent to the list isn't in the DOM at all means the update logic for the list state wouldn't fire at all, no matter how many change events occurred.
(I'm sure you can do something similar in Vue, by detaching listeners when a given element is hidden).
Vue uses a similar (well, now ubiquitous) vdom technology, which can be used directly instead of templates, which simply transpile to it. I think this idea (afaiu) that vue has to do more work than react due to hierarchy etc isn’t correct. If there’s no dom bound to data.a[b].c, then nothing happens. If you think that vue templates still have to be regenerated, resliced and so on, then that also happens only once and results in a function which can be called to “render” vdom. https://codedamn.com/news/vuejs/exploring-vuejs-compiler-tem...
Sorry if I got you wrong. But it’s not the first time I think I see these wrong ideas about how “React is better”. I blame React itself, cause not only it redefined the terms, but also pushed this vague “compared to a regular detergent” agenda everywhere. It’s much less of a library than of pure religious movement with strawmen and fallacies.
Thank you for that. My apologies; said "Vue" meant "Svelte."
AFAICT, Svelte doesn't have a vdom? Maybe I'm just missing it.
Svelte will work here the same way that React does. If a component/element isn't mounted it will not render or update.
Where Svelte has an advantage is that:
1. A lot of stuff is built in, but extendable/replaceable. Styling, animations, basic state management, ...
2. It's update model makes it easier to use vanilla libraries without the need for any react-x wrappers.
3. The update model is also easier to use in general. The amount of stale closures and referential equality issues I have to fight every time I do something in react is insane.
Vue vs React is splitting hairs, honestly. DX wise they feel the same, whereas JQuery and Vue are worlds apart.
Not to me. React's insistence on immutability can be difficult to work around.
Just HTML, CSS & JS?
Of what commercial use are the funny, animating widgets? At this point frameworks like React exist just to generate employment for software developers, like the Federal reserve exists for economists.
I've had enough experience with 10-person teams trying to synchronize code for a large UI to think otherwise.
Trying to do that with "just HTML, CSS & JS" either dooms the project or ends up with the team implementing their own flavor of React (or something else) to standardized complicated state update in a modular fashion that allows sharing code.
Not everyone needs React, but when you do, it's nice not to have to reinvent the wheel.
What do you think is a large UI? Can you give me an example?
Facebook is one. So is Google Cloud's dashboard. Basically anything where a single UI will be serving multiple separable concerns (that could be handed to multiple separate teams in a large org).
soon, everything will be in react. Your browser? React. OS? React. Car operating system? React.
I thought I was making a joke and then googled some and here it is:
https://github.com/shirakaba/react-native-web-browser-app
https://reactos.org/
https://star.global/posts/react-native-for-automotive/
They were so preoccupied with whether or not they could that they didn't stop to think if they should
ReactOS has nothing to do with the ineptly named ReactJS
Why do you think React is named ineptly?
Because it is cool to hate on React on hn. Write something in Rust and watch everyone swoon, but mention anything that uses React and the comments will be filled with people hating all over it. As is the way on hn.
You're right about the disproportionate hate for React, but your information about Rust is out of date. These days it's 50-50 whether you'll get a lot of love or hate for a Rust project, and several of the top-upvoted Rust posts of the past year are disenchanted ones.
ReactOs only shares the name with JS library called React
> ReactOS
One of these things is not like the others.
Say no to chemical reactions! They clearly use React /s
[flagged]
Lua is a great language, I happen to be a lot productive with it, its simplicity reminds me that of C. You don’t fight the language, you actually implement things
> You don’t fight the language, you actually implement things
roflcopter. While in general one could say that about basically any language, this is RICH for Lua.
You implement things... Over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over. And over.
Because every person writing Lua thinks they’re gods gift to Lua. Only their bespoke implementation of THING is correct. Often due to some pedantic definition of “performance”. The ecosystem blows chunks; Luarocks is an unfunny joke.
If NIH was condensed to a language, it’d be Lua
I’m not sure why a language born to be embedded should have such an ecosystem, the C environment you embed it in is the ecosystem. For example I use it mostly with love2d for games and tools development, love2d is my ecosystem, sure I can look for libraries on GitHub, but I feel like it’s pretty much the same I would do for C header only libraries for example. LuaRocks is ok, imo still better than the gigantic mess NPM is, that’s not an ecosystem that’s a landfill
This is actually written for lua with gradual types (luau) that roblox is already using
Thought you were talking about React initially.
I think that was sort of their point argument. You could say the same thing about Python too.
The insinuation that you can’t be serious with those languages is silly though. I mean, Instagram runs on Python and a lot of really awesome applications still run on JavaScript. So while you can do terrible things with the freedom of dynamic languages, you aren’t forced to be a maniac by them either.
It's a hard comment to parse but I think the advocacy is to set a conceptual intellectual ceiling to keep it gentle and approachable to a wide younger audience kinda like Bill Kendrick's TuxPaint.