Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fengari – Lua for the Browser

fengari.io

Post reply on HN
Print view View original

61–70 of 145 posts

Re: Fengari – Lua for the Browser

#61

Post by harpiaharpyja »

zkldi wrote: post #43
DonHopkins wrote: post #40

Earlier quoted context omitted.

I wish Netscape had chosen Lua instead of bothering to invent JavaScript. Python would have also been much better than JavaScript, but Lua would have been perfect. But at least they didn't choose TCL, as Sun was pushing before they switched gears to Java after the Great TCL War. And personally, I would have preferred PostScript (which was the basis of NeWS, with a Smalltalk-like OOP system) or ScriptX (which was like…

> People who are confused about equality shouldn't design programming languages: This is a very dull criticism of JavaScript, everybody uses ===. While it's definitely true the language has some poor decisions (`with`, `==`, etc.). You can write JS without using any of these features (and almost everyone does). Infact, just using a decently strict ESLint config will get you most of the way there. It's controversial,…

The point is that we wouldn't have needed decades of work on tooling to achieve what could have been done from that start with intelligent language design.

Re: Fengari – Lua for the Browser

#62

Post by DonHopkins »

webmobdev wrote: post #53
friedturkey wrote: post #34

Earlier quoted context omitted.

It has all the power of something like Python, but is much faster and with far less cruft and basically no confusing elements. You’re given a small set of tools and it’s incredibly easy to build off them.

Isn't it LuaJIT that's really fast? Last I remember reading about it, there was some version fragmentation going on with Lua advancing and LuaJIT stuck on an older version? (That was a long time ago, and I don't know what been happening since.)

And LuaJIT has historically been extremely fast (initially much faster than JavaScript's early JITs) because it didn't have nearly as many optimizer-busting design flaws to work around as JavaScript JITs did, because Lua's language design is so much simpler and cleaner than JavaScript's, which wasn't originally designed to be compiled (cough cough "with" cough "this"). But because JavaScript was the "Chosen Language", a whole lot of effort has been put into developing JITs that worked around JavaScript's flaws over the decades since. But all that effort could have been put to much better uses if it didn't have all those flaws in the first place.

Re: Fengari – Lua for the Browser

#63

Post by bayesian_horse »

Aeolun wrote: post #18
bayesian_horse wrote: post #10

For those looking for powerful async coroutines in the browser: The combination of typescript+redux+redux-saga is also quite powerful. Redux-saga uses generator coroutines to handle all sorts of asynchronous tasks.

I think you can do anything in Redux Saga without either Redux or React.

There is power in the combination. When you think about needing sagas, you probably need sophisticated state management. Redux is a popular and battle-tested choice. Just as React is a popular and battle tested choice.

Re: Fengari – Lua for the Browser

#64

Post by gwbas1c »

capableweb wrote: post #30
harvie wrote: post #28

No web assembly?

Not sure why'd you think this would have anything to do with WASM, the homepage is really clear what this is: > Fengari is the Lua VM written in JavaScript. It uses JavaScript's garbage collector so that interoperability with the DOM is non-leaky. WASM wouldn't use JS's GC, nor would provide interop with the DOM, so for the stated goals of this project, WASM would be a non-starter. There is prior art for Lua -> WASM…

I have no problem interoperating with the DOM in WASM.

Granted, reusing a GC is a good reason to use JavaScript.

Re: Fengari – Lua for the Browser

#65

Post by richardfey »

dummy_variable wrote: post #36
richardfey wrote: post #23

> Lua in the browser means you can use coroutines to write beautiful asynchronous code Is it beautiful, but also performant?

I wonder the same thing. Writing a scripting language on top of another scripting language makes me wonder, why add another layer? A common complaint I have seen with frontend JS apps is that people tend to unnecessarily bloat them. But I do appreciate the efforts and idea. Most probably the developers must have thought this through and have definitely kept the performance aspect in mind.

I was thinking: do Lua coroutines map well to Javascript's event loop?

Re: Fengari – Lua for the Browser

#66

Post by BiteCode_dev »

friedturkey wrote: post #34
Sebb767 wrote: post #29

Earlier quoted context omitted.

> Lua is the only language I can truly say I love Why? I've worked with Lua before and to me it's not a bad language, but nothing special either. I'm honestly wondering.

It has all the power of something like Python, but is much faster and with far less cruft and basically no confusing elements. You’re given a small set of tools and it’s incredibly easy to build off them.

Lua definitely does not have the power of something like Python.

That's usually what people like about Lua: it's barebone, yet high level and clean.

If one likes Python, then the chance of liking Lua are low.

E.G:

Both python and lua can open something (a file, a socket, a transaction...) in one line.

But only Python has the `with` construct that means it's easy to guaranty you close it in case of an error.

Lua is then easier to learn: one less concept to master. But the high level tool of Python, that you had to learn, make your life easier.

They have very different trade off.

Re: Fengari – Lua for the Browser

#67

Post by 2ion »

upofadown wrote: post #35

Lua did a language fork at version 5.3. I think this supports the 5.3 fork but it would be good to make this explicit.

Each Lua x.y is a "major" version. You can expect things to be stable and patched in versions x.y.z with variable z. Might be irritating but it has been this way for decades.

Re: Fengari – Lua for the Browser

#68

Post by BiteCode_dev »

I was pleasantly surprised it loaded so fast.

So I wanted to check the size of it.

I opened the firefox debugger, and it went blank O_o

Chrome was ok with it: it's about 220kb, which is not bad at all for a whole runtime + stdlib. Python pyiodide (https://pyodide.org/en/stable/) is several Mb.

220kb is still too much to pay upfront, since I usually want my webpages to be under 1Mb, and I can't justify burning 1/4 of the size budget.

As for the Firefox story, maybe it's a good obfuscation trick :)

Re: Fengari – Lua for the Browser

#69

Post by gilgad13 »

Sebb767 wrote: post #29
friedturkey wrote: post #26

Lua is the only language I can truly say I love. If more people used it (and used it responsibly, not letting it become a mess of odd libraries), the world would be a better place.

> Lua is the only language I can truly say I love Why? I've worked with Lua before and to me it's not a bad language, but nothing special either. I'm honestly wondering.

One aspect of Lua that stands out to me is how every feature is carefully designed both in isolation and in composition with the others. The language has relatively few features, but none of them are hanging off the side, the all lean on each other to make a cohesive whole.

I think Lua is a bit unique in this for two reasons. First, they have in intentional open-source but not open development model. Second, because of the way that Lua is embedded inside other projects, there is more willingness to implement backwards-incompatable changes. I'm sure this is a negative for some who want to build a larger, less fractured community, but it has advantages for language cohesiveness.

Re: Fengari – Lua for the Browser

#70

Post by babagabooj »

richardfey wrote: post #65
dummy_variable wrote: post #36

Earlier quoted context omitted.

I wonder the same thing. Writing a scripting language on top of another scripting language makes me wonder, why add another layer? A common complaint I have seen with frontend JS apps is that people tend to unnecessarily bloat them. But I do appreciate the efforts and idea. Most probably the developers must have thought this through and have definitely kept the performance aspect in mind.

I was thinking: do Lua coroutines map well to Javascript's event loop?

yes if they are using generators... that's the only viable way.
Post reply on HN