131–140 of 156 posts
Earlier quoted context omitted.
Given that Mozilla has done tons of WASM work, and that one of the earliest implementors was Rust, comparing WASM to Oracle's iron fist over the JVM doesn't seem to jive with reality...
I didn’t say Mozilla, I said Google. I didn’t say iron fist, I said disproportionately affected.
Earlier quoted context omitted.
Actually there was an Office like suite written in Java, e.g. Corel Office for Java. JVM separation between computation and IO can be managed via classloaders and JAAS.
OpenOffice / staroffice were also partially Java based for a while if I remember correctly
Earlier quoted context omitted.
.NET ecosystem is fantastic right now. .NET Core is fast and efficient, asp.net is better, faster and more full-featured than ever, and MS is ahead of everyone with Blazor Components that finally provide a real alternative to JS frontend frameworks and can run either server-side or as WASM modules.
I agree largely from a development perspective, but the client-side javascript frameworks are ultimately more performant, particularly on mobile, and are not as bad as they used to be. Neither server-side nor WASM are ideal for mobile devices. Downloading many megabytes of .NET dependencies for a WASM app is obscene compared to like 30 kilobytes for React.
As far as performant, I agree it wont matter in most trivial interactions but large datasets with computations already see an impact (for example we have million row datatables to show sometimes).
Earlier quoted context omitted.
.NET ecosystem is fantastic right now. .NET Core is fast and efficient, asp.net is better, faster and more full-featured than ever, and MS is ahead of everyone with Blazor Components that finally provide a real alternative to JS frontend frameworks and can run either server-side or as WASM modules.
IMO, server-side Blazor is a non-starter, basically just a proof-of-concept to get something up and running before the WASM version is usable, but definitely not something I would use in production.
I think the biggest issue is sending every interaction over the wire but there are ideas to separate the event handling or even split which components run server vs client-side. That would allow highly responsive inputs with no lag while the parent component can run all its logic on the server.
Earlier quoted context omitted.
I am not surprised. As someone who cut his programming teeth on Java and .Net, modern web development feels really out of touch with reality. I really don't get why the community is hell bent on reinventing the wheel, especially when the main defense of npm is that you don't have to reinvent the wheel. It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same o…
> It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same old things instead of trying to improve upon the existing systems. I hear that often in regard of programming languages. But I see a lot of value in remixing a lot of existing ideas in a new package. A wheel can only be so round and its interaction with the road is quite simple, but tech is different.…
Null removal is completely compile-time anyway so it's complicated to compile but relatively simple to implement as a language upgrade at a certain version, and in this case it's also opt-in.
Earlier quoted context omitted.
I agree largely from a development perspective, but the client-side javascript frameworks are ultimately more performant, particularly on mobile, and are not as bad as they used to be. Neither server-side nor WASM are ideal for mobile devices. Downloading many megabytes of .NET dependencies for a WASM app is obscene compared to like 30 kilobytes for React.
It won't be megabytes, that's only in the experimental phase. Binaries can shrink dramatically once run through a linker and trimmed down to only used APIs. As far as performant, I agree it wont matter in most trivial interactions but large datasets with computations already see an impact (for example we have million row datatables to show sometimes).
It's worth pointing out that .NET Core has an assembly/executable generator that can package only the .NET libraries that are actually used.
Earlier quoted context omitted.
> ...why don't I have Go and Rust compile targets for the JVM, with JVM browser code running my JVM targets and etc? The JVM is not a true VM. It's heavily coupled to the Java object model and the Java GC.
And yet so many posts here cry of history repeating itself and seem to imply we should just be using the JVM. I'm honestly puzzled. Am I the one missing something? Why is the JVM crowd seemingly upset here?
Nobody is upset, really. Java web client lost a very long time ago to Flash.
But imagine, if 25 years ago you poured your heart and soul years ago into a project because it promised to be a particular kind of great (but later failed), it can sort of drive the knife deeper and throw extra salt in the wound when your project's ugly red-headed stepchild (i.e. JavaScript) grows up into something great and gives birth years later to a beautiful standard (asm.js, later WebAssembly) that becomes what your project thought it would be, and much more. Or something like that.
Java certainly has a well-established place in software, no doubt about that. But its original promises had it (combined with AWT/Swing, applets, and XML, ... umm yeah) becoming the ultimate "write once run everywhere" platform that could scale up to massive servers and down to tiny embedded chips, and every client platform in between. In retrospect, C# and .NET would have done well not to attempt to emulate Java's initial scope.
Earlier quoted context omitted.
> Javascript/WASM is not controlled by any one large company or organization It’s disproportionally affected by Google.
Given that Mozilla has done tons of WASM work, and that one of the earliest implementors was Rust, comparing WASM to Oracle's iron fist over the JVM doesn't seem to jive with reality...
Still doesn't compare to the Sun God and his silicon fist.
(With apologies to Steve Yegge.)
Earlier quoted context omitted.
I feel like the world of computer programming is caught in a very fast iteration of the old adage, "Those who cannot remember the past are condemned to repeat it." Which oddly, I was curious about that quote's origins, so I just went and looked it up. The full quote in context is: "Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direc…
You realize that the people behind Web Assembly, for example Dan Gohman, are some of the foremost world experts in compilers who have worked for literally decades in the field?
Earlier quoted context omitted.
IMO, server-side Blazor is a non-starter, basically just a proof-of-concept to get something up and running before the WASM version is usable, but definitely not something I would use in production.
Why not? Works fine in our tests, and a large part of .NET apps are internal apps that work great with this kind of framework. I think the biggest issue is sending every interaction over the wire but there are ideas to separate the event handling or even split which components run server vs client-side. That would allow highly responsive inputs with no lag while the parent component can run all its logic on the serve…