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

101–110 of 145 posts

Re: Fengari – Lua for the Browser

#101

Post by gwbas1c »

capableweb wrote: post #75
gwbas1c wrote: post #64

Earlier quoted context omitted.

I have no problem interoperating with the DOM in WASM. Granted, reusing a GC is a good reason to use JavaScript.

> I have no problem interoperating with the DOM in WASM. What? How? Was a year or two ago I dived into WASM last time, but at that point there was no direct DOM access, and all the talk around it was pointing to it maybe existing far into the future, not anytime soon. How are you accessing the DOM from WASM without using any of the JS host? You're not talking about just sending messages from WASM to JS and "manipulat…

I've been calling into the Javascript runtime from C# in Blazor. (C# compiles to WASM.)

Blazor's built-in framework appears to send HTML (as a string) to the DOM. It also automatically sets up callbacks from DOM events into C#.

For code that I've written, I've mostly done simple stuff, like calling window.alert. I suspect I could call window.getelementbyid using the same techniques, but I haven't done that yet.

I did try manipulating the DOM from Rust (via WASM) in the summer of 2020. That was an exercise in frustration, but I point my finger equally at the language and the runtime. Granted, a lot can change since then!

Re: Fengari – Lua for the Browser

#102

Post by MobiusHorizons »

zamadatix wrote: post #95
BiteCode_dev wrote: post #68

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 o…

57k post Brotli. Measuring the decompressed size of your page's static text content is like measuring your static image content by the size of the decompressed bitmap the browser generates instead of the size of the PNG (or whatever format). Server side both examples should be precompressed as they are static assets.

Uncompressed size matters for parse time. Although you are correct about network latency.

Re: Fengari – Lua for the Browser

#103

Post by tzot »

notorandit wrote: post #92

I knew "selene" meant "moon" in Greek! Maybe I missed some updates...

Σελήνη/Selene (the ancient name) is Luna: our moon. Lowercase φεγγάρι/feggari/fengari is moon: you would say «δίδυμα φεγγάρια του Άρη» for “Mars' twin moons”.¹ In the same vein, capitalized Ήλιος/Helios is Sol: our sun. Lowercase ήλιος means any sun.

¹ Trivia: “satellite” is «δορυφόρος» = spear bearer; from the protectors of kings or powerful men in general, who typically encircled their protectees.

Re: Fengari – Lua for the Browser

#104

Post by djur »

user3939382 wrote: post #59
zkldi wrote: post #43

Earlier quoted context omitted.

> 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,…

I’ve used JavaScript for about 25 years, sometimes more seriously, and always hated it. I’ve always found it unpredictable, I don’t like the turtles-all-the-way-down thing going on with its objects. I’d like to leverage my experience with regular class definitions and instantiation from Java workalikes. I’m sure many people love JS’s take on OO but I find it annoying. A perfect example: I read hey there’s a cool simp…

> A perfect example: I read hey there’s a cool simpler way to write small anonymous functions called arrow syntax. Nice let me try it, hm it’s not working —> google —> arrow functions have no access to ‘this’.

If you try to use a new language feature without reading the documentation first, you will probably run into difficulties. This is not a unique problem to JS.

Re: Fengari – Lua for the Browser

#105

Post by samatman »

DonHopkins wrote: post #40
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.

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…

I share a similar vague desire, but the specifics are all off.

If Netscape had even heard of an obscure two-year-old scripting language from Brazil, and chosen to use it, we wouldn't have gotten the Lua we know and love in the bargain. 1995 Lua wasn't the obviously superior Javascript alternative that it's been since the early 200s.

Re: Fengari – Lua for the Browser

#106

Post by pull_my_finger »

upofadown wrote: post #96
shakna wrote: post #49

Earlier quoted context omitted.

I'm not entirely sure what you mean by "language fork", but all versions of Lua have incompatibilities. 5.1, 5.2, 5.3, and 5.4 are all major versions, with features that aren't completely compatible with any of the others. For example, 5.2 brought in major changes for how environments were handled, and 5.3 brought in integers, and 5.4 brought in changes to how number overflow is handled.

At 5.3 the behaviour of the basic arithmetic operations were changed in a fundamental and non-backwards compatible way to bring in those integers. That certainly counts as a language fork, as opposed to the other two examples.

It definitely is the mainstream continuation of that language by the original authors. Changing the API, or the implementation, or making other breaking changes does not automatically (or otherwise exclusively) make it a "language fork". Lua has the luxury of making breaking changes, and most Lua users both accept and appreciate that. Lua is continuously refined while languages like JavaScript and PHP are stuck with their (sometimes dubious) decisions forever or _break the web_.

Re: Fengari – Lua for the Browser

#107

Post by DonHopkins »

Banana699 wrote: post #77
DonHopkins wrote: post #50

Earlier quoted context omitted.

Decades later you may believe that "everybody" uses "===", but actually "==" is still there, and many people still use that regardless of what you choose to believe, simply because it's there and 33% shorter and looks like C and Stackoverflow is full of examples of it, and it STILL commonly causes many subtle hard-to-find bugs. People like Roberto Ierusalimschy, Luiz Henrique de Figueiredo, and Waldemar Celes, James…

>the bigoted designer of JavaScript is about equality when it comes to human beings Zero relevance to programming language design, makes your argument look very weak and emotionally-motivated. If you have to sink to bringing up the personal views of the language designer you're criticizing on an entirely unrelated matter to make a point, you don't really have a point. >his own reputation and legacy His legacy is quit…

I would have used Lua in 10 days. That's the point.

My reasons for not using brave have nothing to do with the author, and everything to do with not wanting to participate in cryptocurrency bullshit.

Re: Fengari – Lua for the Browser

#108

Post by zkldi »

cardanome wrote: post #83
zkldi wrote: post #43

Earlier quoted context omitted.

> 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 syntax is dead simple It really annoys me that people confuse ease of use due to familiarity with simplicity. Many programmers will be familiar with the typical curly-braced C-style syntax many mainstream programming languages have and so find JS syntax easy to get into but that has nothing to do with simplicity. Building a parser for JS is not exactly simple nor is teaching new programmers the syntax. Lua is v…

I don't personally think there's anything complicates about arrow functions. They're syntactic sugar for `function() {}`, with the exception that they have sensible binding of `this`.

I do agree that Lua is simpler, but I don't think this is an area where JS is that bad.

Re: Fengari – Lua for the Browser

#109

Post by zkldi »

jamil7 wrote: post #54
zkldi wrote: post #43

Earlier quoted context omitted.

> 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,…

I think your answer just solidifies their point since your proposed solutions are to avoid parts of the language and bolt two pieces of tooling on top.

Fair enough -- Like I said, I think somewhere under the cruft of JS is a good language, but I don't think it's as bad as OP implies.

Re: Fengari – Lua for the Browser

#110

Post by zamadatix »

MobiusHorizons wrote: post #102
zamadatix wrote: post #95

Earlier quoted context omitted.

57k post Brotli. Measuring the decompressed size of your page's static text content is like measuring your static image content by the size of the decompressed bitmap the browser generates instead of the size of the PNG (or whatever format). Server side both examples should be precompressed as they are static assets.

Uncompressed size matters for parse time. Although you are correct about network latency.

If the goal is strictly to keep things low on bandwidth compressed size is all that matters. If the goal is strictly to keep things fast time to various user events is all that matters. If the goal is a balance of both then both will matter. In none of these is uncompressed asset wire size Barring any other information whatsoever while knowing a script is 10 MB vs 10 KB should give you a strong hint on "parse time" it's not actually telling you what the metric is named for which should be a red flag. What you actually want to know is what the parse time was regardless of what the file size was or, more likely in the bigger picture, how using the resource changes time to certain user noticeable events. Perceived slower pages much smaller than 1 MB are certainly easy to generate by optimizing for the wrong things as are perceived faster pages with much bigger payloads.

On the other hand if you're just using 1 MB as a quick and simple yardstick you probably don't intend to measure some of your assets compressed and some others uncompressed, particularly when picking which to axe.

Post reply on HN