<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: abuldauskas</title><link>https://news.ycombinator.com/user?id=abuldauskas</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 23 Apr 2026 06:19:13 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=abuldauskas" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by abuldauskas in "Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)"]]></title><description><![CDATA[
<p>I also noticed it. On million-points. MacBook Pro M2 on Firefox Nightly 148.0a1 (2026-01-09) (aarch64)</p>
]]></description><pubDate>Wed, 21 Jan 2026 15:43:02 +0000</pubDate><link>https://news.ycombinator.com/item?id=46707259</link><dc:creator>abuldauskas</dc:creator><comments>https://news.ycombinator.com/item?id=46707259</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46707259</guid></item><item><title><![CDATA[New comment by abuldauskas in "A Critique of React Hooks"]]></title><description><![CDATA[
<p>I don't really understand how this approach breaks what you are describing.<p>All I'm saying is that instead of hooks API being imported from React at global scope it could be provided as inputs into the components directly. They would still exist in the function body as you put it.</p>
]]></description><pubDate>Mon, 27 Apr 2020 16:26:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=22997304</link><dc:creator>abuldauskas</dc:creator><comments>https://news.ycombinator.com/item?id=22997304</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=22997304</guid></item><item><title><![CDATA[New comment by abuldauskas in "A Critique of React Hooks"]]></title><description><![CDATA[
<p>My only issue with Hooks has been that they are not inputs into the component. It's a step in the right direction of making React more functional I would just preferred less magic, personally.<p><pre><code>  function Component(props, { useState, useContext }) { ... }
</code></pre>
Of course that would break backwards compatibility with the old 2nd argument being context, so I get why they did it.</p>
]]></description><pubDate>Mon, 27 Apr 2020 15:56:27 +0000</pubDate><link>https://news.ycombinator.com/item?id=22997020</link><dc:creator>abuldauskas</dc:creator><comments>https://news.ycombinator.com/item?id=22997020</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=22997020</guid></item><item><title><![CDATA[New comment by abuldauskas in "October Brings Node.js 10.x to LTS and Node.js 11 to Current"]]></title><description><![CDATA[
<p>Node 11 now comes with v8 v7.0, does this mean Webassembly threads are supported? Or are they behind a flag?</p>
]]></description><pubDate>Thu, 01 Nov 2018 13:20:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=18353597</link><dc:creator>abuldauskas</dc:creator><comments>https://news.ycombinator.com/item?id=18353597</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18353597</guid></item><item><title><![CDATA[New comment by abuldauskas in "Walt: JavaScript-like syntax for WebAssembly"]]></title><description><![CDATA[
<p>I have not, this has been requested quite a bit though. My focus is currently on making sure the toolchain is stable and performant itself. It's likely that the performance of the compiled code is on par with other wasm vs JS comparisons though.</p>
]]></description><pubDate>Thu, 11 Oct 2018 13:59:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=18193563</link><dc:creator>abuldauskas</dc:creator><comments>https://news.ycombinator.com/item?id=18193563</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18193563</guid></item><item><title><![CDATA[New comment by abuldauskas in "Walt: JavaScript-like syntax for WebAssembly"]]></title><description><![CDATA[
<p>That's the thing though. We are all "us" here. We can all compile whatever we want to WebAssembly, that's the point of WebAssembly. One way of doing things doesn't take away from another.</p>
]]></description><pubDate>Thu, 11 Oct 2018 02:29:12 +0000</pubDate><link>https://news.ycombinator.com/item?id=18190621</link><dc:creator>abuldauskas</dc:creator><comments>https://news.ycombinator.com/item?id=18190621</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18190621</guid></item><item><title><![CDATA[New comment by abuldauskas in "Walt: JavaScript-like syntax for WebAssembly"]]></title><description><![CDATA[
<p>Escaping JavaScript is not a perspective shared by all (most?), though.<p>It's has been a weird and interesting project, but that's not really a bad thing is it.</p>
]]></description><pubDate>Thu, 11 Oct 2018 00:41:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=18190175</link><dc:creator>abuldauskas</dc:creator><comments>https://news.ycombinator.com/item?id=18190175</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18190175</guid></item><item><title><![CDATA[New comment by abuldauskas in "Walt: JavaScript-like syntax for WebAssembly"]]></title><description><![CDATA[
<p>I wrote/maintain Walt. This question comes up a bunch.<p>The two projects are really similar no doubt. I can't speak for AssemblyScript, but my own motivation was simple. I wanted to learn WebAssembly and I wanted an accessible platform to do so with. At the time this wasn't really possible, tools like emscripten took forever to set up and were clunky to use. Plus I knew C already, I wanted to learn WebAssembly instead.<p>So where Walt is an attempt to write WebAssembly with a familiar syntax, AssemblyScript is an attempt to compile TypeScript to WebAssembly. To do so AssemblyScript comes with many more niceties/features out of the box IIRC, like optional(?) GC for example. Walt makes no such attempts and takes a more DIY approach.<p>Walt also has language extensions, via customizable syntax and compiler pipeline, where AssemblyScript is a TypeScript compiler more or less. My hope is that this allows for a babel-like situation for WebAssembly in the future via the tooling setup for Walt. I don't think this is a goal of AssemblyScript.</p>
]]></description><pubDate>Thu, 11 Oct 2018 00:17:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=18190075</link><dc:creator>abuldauskas</dc:creator><comments>https://news.ycombinator.com/item?id=18190075</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18190075</guid></item><item><title><![CDATA[New comment by abuldauskas in "GitLab Direction"]]></title><description><![CDATA[
<p>One of my major pain points with GitLab was its API. The lack of coherent API design ultimately made me lose hope in the product. For example I think it still lacks an ability to create threads on MRs. Until recently it wasn't possible to approve any MRs either, for 10+ versions of the product and 4+ versions of the api, but adding emoji was... The disjointed API made it nearly impossible to create quality tooling on top of GitLab, ultimately forcing us away from the product. It left a poor taste in my mouth, with a sense that there was no rhyme or reason to the direction of the platform, unfortunately.</p>
]]></description><pubDate>Mon, 23 Jul 2018 11:54:12 +0000</pubDate><link>https://news.ycombinator.com/item?id=17592061</link><dc:creator>abuldauskas</dc:creator><comments>https://news.ycombinator.com/item?id=17592061</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=17592061</guid></item></channel></rss>