Maybe it’s just me, but I don’t think showing a string on screen requires React or any other view library. I’d probably paint it on canvas and then overlay an invisible plaintext node to allow selection.
4x Smaller, 50x Faster
31–40 of 205 posts
Re: 4x Smaller, 50x Faster
#32The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
Not to say that we shouldn't have "everything be performant" but drawing a bunch of stuff to screens is _the classic_ performance question. Whereas most "business apps" people here work on to a day-to-day have different performance issues.
Rewriting your CRUD frontend in Rust isn't going to make your DB queries faster
Re: 4x Smaller, 50x Faster
#33Re: 4x Smaller, 50x Faster
#34Went to https://asciinema.org/ and clicked the demo video. I'm a bit confused because it looks like future lines are being rendered after the cursor while lines are being typed. Is that...correct? It looks like either a blatant bug in their product (that they're displaying on their homescreen demo!) or on purpose for some reason I can't find.
Re: 4x Smaller, 50x Faster
#35Maybe it’s just me, but I don’t think showing a string on screen requires React or any other view library. I’d probably paint it on canvas and then overlay an invisible plaintext node to allow selection.
Re: 4x Smaller, 50x Faster
#36It's awesome to see performance-oriented projects to find their way to SolidJS( https://www.solidjs.com ). So satisfying to see success stories like this one. Great work.
Congrats! One nit I have about SolidJS documentation is that it doesn't have a clear path for "migrating from React" which I take it is probably actually important to you given how similar SolidJS looks to React and how much faster it claims to be. Also might be good to include a section on how to interop with existing React libraries -- even if the answer is that you can't. And it might be worth putting in your HN p…
And good point thank you about updating my profile.
Re: 4x Smaller, 50x Faster
#37Re: 4x Smaller, 50x Faster
#38Earlier quoted context omitted.
I fantasize about a future in which buying a faster computer means my software runs faster. I don’t spend thousands on computer hardware so that lazy devs can get lazier.
You may call functional programmers who prefer immutable data structures lazy because we want to actually understand what we create, but I don't see how the 10 billion layers of abstractions and state duplications somehow end up making better software.
Functional programming is great. What’s not great is loading the entire closure VM environment into my browser - resulting in the software running (in this case) 50x slower. FP is no excuse for making my computer crawl to a halt.
And there’s no essential reason FP needs to be slow. For example, look at how well llvm optimizes map/filter/fold in rust. In many cases they’re faster than their imperative counterparts! There are other ways to benefit from immutability that don’t involve burying a garbage collector in useless work. For example, React is a lovely example of immutable ideas, and a fast runtime.
I spent a few thousand dollars on a new Mac laptop recently. I wonder what percentage of my clock cycles are going to be wasted due to bad abstractions and inefficient code? Probably most of them. I wish I could take the money I spent on the machine and instead pay people to improve their software. I don’t have billions of cycles per second of actual work to do.
Re: 4x Smaller, 50x Faster
#39This always kills me. Clojure(script) is one of the neatest languages I've ever used, but it is just such a pain to work with. I spent hours getting NPM imports working in a project, when it ought to take seconds. It really makes it hard to recommend, even though the language itself is amazing.
Re: 4x Smaller, 50x Faster
#40The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
What is the connection between mutability and excessive hardware usage?