221–229 of 229 posts
That's cool, but until I see it coming to smartphones, that won't really be useful, except for gaming. In theory this could really be the universal vm for the web everyone needed, but it's still lacking real sockets and dom support.
It's available on android now...
Earlier quoted context omitted.
There isn't anything about Electron that I feel it is simple over Delphi, WinForms, JavaFX, Android, Cocoa, Qt, XAML, other than being easier for those that grew with HTML/CSS.
Caveat: It's been a long time since I've used GUI toolkits like Gtk+ and QT, so this may be an out-of-date perspective. What I think of GUI toolkits, I think of lots of imperative code to build out an interface, e.g., "Create a window. Add a vertical box layout. Create button1. Change button1.font to xxx. Change button1.style to bold. Set the minimum height of button1 to 20px. Add button1 to the box. Create button2.…
I'm not a frontend whiz by any means, but I've always found the widget-centric (GUI) approach fit my mental model better than the HTML centric one.
SPA architectures help, but I find most HTML designers tend to prefer raw HTML to any composed/widget approaches.
CSS (as a concept) is actually quite great, which is why you've seen the older GUI approaches adopt it. Qt itself is also leading more towards a reactive approach where you interact with an abstract data model, and the UI reflects the updates.
Earlier quoted context omitted.
That's for max frequency on a given process node. Power scales with voltage squared. But that doesn't say anything about wasted power. And dynamic scaling screws that up in modern chips. I believe I could summarize things by saying the only way you can really save energy* doing the same work+ is by using a different semiconductor process (either power/leakage-reduction-focused or smaller). * For serious values of "en…
Can you explain the voltage squared thing? To me, power = voltage * current.
Earlier quoted context omitted.
> That isn't a problem. innerHTML is lazily computed from the tree structure: if you don't use it, you don't pay for it. I'm not paying for it, the DOM implementation is - with increased complexity. (E.g., HTML parsing suddenly becomes a time-critical operation because some wiseguy decided to implement animations for his website using setTimeout and innerHTML.) And they can't drop it because a lot of sites rely on it…
> I'm not paying for it, the DOM implementation is - with increased complexity. (E.g., HTML parsing suddenly becomes a time-critical operation because some wiseguy decided to implement animations for his website using setTimeout and innerHTML.) We're talking about performance here, not implementation complexity. Besides, it's not a win in terms of complexity if sites ship a limited subset of the Web stack to run on t…
My point is that writing custom UI renderers using canvas and WASM might become a reasonable thing to do. For that you don't need to stick to the web stack at all, you can invent whatever language, API and data model fits your needs. Those can be a lot simpler than the DOM and therefore easier to implement with good performance.
Earlier quoted context omitted.
Downloading a bigger executable wouldn't necessarily be faster actually, it depends on the size difference and the client bandwidth.[1] Additionnally, it wouldn't be portable (executable compiled for desktop wouldn't run on mobile). [1] See this comment : https://news.ycombinator.com/item?id=16171133
What you are saying is that source code is less in size than compiled native code which is nonsense.
And if you compare the size of the binary output with the size of the source code, the binary is bigger in many cases because of optimizations (and runtime size, for small programs). Additionally, the source code can be gziped with a good compression factor whereas the binary cannot. Then 99% of the time, the source code is lighter to send over the internet than the compiled binary.
Earlier quoted context omitted.
As far as not making sense goes, sorry but your post doesn't make any to me, either. Why would we possibly return to a manual memory management, raw pointer oriented, assembly language level of abstraction from the much richer and safer abstraction that JS already has? Wasm doesn't even have any notion of Characters or Strings! You really want to return to the days of each project having their own String libraries, b…
They’re adding all those things to wasm. I think you’re mistaken about the future.
Earlier quoted context omitted.
This whole reply doesn't pass the smell test. > Web Assembly targets C and C++ as source languages, unlike the JVM. So wasm (and hence JavaScript if you translating js into wasm) are closer c/c++ than to java? Considering all the UB in C, this cannot possibly be true. > Because JS and Java semantics are different, and emulating JS semantics on top of the JVM is slow. Given javas JavaScript implementation is pretty co…
> So wasm…are closer c/c++ than to java? Yes. For example, Web Assembly has unsigned integer arithmetic and explicit memory allocation/deallocation, neither of which the JVM has. > Considering all the UB in C, this cannot possibly be true. Undefined behavior is a concern of the compiler of the source language. Web Assembly doesn't compile C or C++. It simply interprets a VM, the semantics of which are designed to be…
> Web Assembly has unsigned integer arithmetic
This is your idea of a major difference that affects implementation so much that is separate VM needs to be written? Many Java programs already do essentially manual memory management already too. Those aren't the big differences. Things like safe-memory access are bigger issues. And once wasm gets gc, it will even be closer to Java and JS.
I hope Graal outperforms everything else, so we can stop pretending like WASM is something different than what Java has been trying to do.
Earlier quoted context omitted.
>You can import C (and many others) libraries This means compiling the lib to wasm, right? At first I was thinking of running JS clientside that imports some C lib somehow, which confused me.
Yes. The C lib will be compiled into wasm. You can use the wasm-compiled code in a browser through JS wrappers. So you can say importing C lib on JS client side anyway. Note that wasm's main objective is to run non-JS code on browsers, not for a faster JS. Here is the best overview and tutorial I've ever seen in HN , if you are interested: https://news.ycombinator.com/item?id=15958827
Earlier quoted context omitted.
Yes. The C lib will be compiled into wasm. You can use the wasm-compiled code in a browser through JS wrappers. So you can say importing C lib on JS client side anyway. Note that wasm's main objective is to run non-JS code on browsers, not for a faster JS. Here is the best overview and tutorial I've ever seen in HN , if you are interested: https://news.ycombinator.com/item?id=15958827
So you could do the same with Cython then, too? Interesting.