3 ms·

> In all seriousness, anything that spits out canvas for a simple textbox is completely misguided about what the web is. I suspect the goal is a way to bring J

> In all seriousness, anything that spits out canvas for a simple textbox is completely misguided about what the web is. I suspect the goal is a way to bring Java desktop applications into the browser without rewriting the application from scratch. Personally, as a fan of Blazor, I thought this was going to be a Java-based analog of Blazor; or a modernized replacement for GWT. (One flavor of Blazor compiles C# to WASM, and uses a C# templating engine to generate HTML.)

knome 4y ago
>as a fan of Blazor I really dislike this stuff. It's easy-ish to write, but it's like the authors of it hate everything about the web. SPAs do a lot of annoying stuff, and blazor encourages all of it. I really hope things swing back away from this grotesque tight binding between the server and the client.
- gwbas1c 4y ago
  One of the nice things about SPAs is that they allow navigation without the latency needed to re-load all assets. You can get there the old-fashioned way if all your assets are cached in the browser with long timeouts; but that implies that you're doing something like putting hashes in the asset URL and hashing them as part of your build process. (This, is why loading JavaScript and CSS from CDNs helps with performance.) Otherwise, every time you navigate to a new page on a non-SPA, the browser still needs to send an IF-CHANGED-SINCE request to the server. As a developer, though, the BIG drawback of SPAs is that they require building much stricter APIs for everything. In a traditional server-side HTML page, you can quickly prototype something where the code that's putting together the HTML has access to privileged data that you can't expose through an API. (IE, if you just need to prototype something, server-side HTML rendering code can directly talk to the database.)
  - ptx 4y ago
    > One of the nice things about SPAs is that they allow navigation without the latency needed to re-load all assets. [...] You can get there the old-fashioned way if [...] you're doing something like putting hashes in the asset URL and hashing them as part of your build process. But that solves the problem, doesn't it? And it seems a lot simpler than implementing an SPA. Django has this feature built-in. You just have to enable ManifestStaticFilesStorage: https://docs.djangoproject.com/en/4.2/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage https://docs.djangoproject.com/en/4.2/ref/contrib/staticfile...
    - gwbas1c 4y ago
      > And it seems a lot simpler than implementing an SPA Depends on your design goals. BTW, I'm not pro/against SPAs. It's just a tool, and like all tools, they have their advantages and disadvantages. In general, the fact that you can update the page without a server-side round trip is a major advantage. Granted, you can also do that with server-side rendering; but then your rendering logic is defined in two places.
- dagaci 4y ago
  I think you’re a little misconceived, WebAssembly runs entirely in the client and have no bindings to the server, as far as the server is concerned such apps may as well be static HTML. This is Blazor WebAssembly. It will be just as trivial to run such on Mac, Linux or Windows server or any other plain web servers. TeaVM seems to be the same except it compiles Java to JavaScript which means has fast startup times. Web browsers and their fundamental development foundations are best described as a set of mostly well meaning compromises, and so even modern browsers have been updated to support all the other disagreeable things you have mentioned, even having the ability to navigate the browser history within an SPA
  - knome 4y ago
    Ah, sure, for whatever WASM variant you're referring to. Whichever form of blazor I use pretty obviously makes calls back to the server to interact with client state on a per-event basis. If the backend has to restart, the clients all lose connection and die. I won't pretend to be an expert in the framework, or even C#. I had avoided both until recently, and this introduction hasn't made me particularly fond of either.
    - gwbas1c 4y ago
      Server-side or WASM is an option when you create a Blazor project in Visual Studio. You can write libraries and either approach can use the same library. Server-side Blazor keeps a websocket open to send messages back and forth. If you can tolerate the latency, it allows your UI code to be able to handle data that needs to remain secret on the server.
    - dagaci 4y ago
      Its pretty fundamental stuff to know the difference between what is server side and what is client side. I think you will have a lot of trouble undertanding a framework without this. Blazor WebAssemly requires you make explicity Ajax-like Calls to external web services in order to interact with a server and data. There is no server side framework in WebAssembly for maintaining state. State is entirely client side. Blazor Server basically uses Web Sockets (with fallbacks) to communicate changes between client and server, this is far more efficient than using http request calls. State here is server side. But differs from all other frameworks in that state is trasmitted over sockets not http requests. I'm not convinced you have actually used any kind blazor tbh
TeaVMFan 4y ago
Agreed that many people will want to build true web single-page apps, not port Swing to the web in a Canvas. A Java option for modern web apps exists, and it's called Flavour: https://flavour.sourceforge.io/ https://flavour.sourceforge.io/ * Build SPAs in Java with HTML templates and components * Fast build times and batteries-included build framework * Easy calls to Java web services, just invoke a method and Flavour handles marshalling and unmarshalling, you just see/use Java objects. * Full-stack refactoring * Built on TeaVM, so you get the all the benefits of a mature, performant framework with support for threads and multiple JVM languages (bytecode-based transpilation). TeaVM vs Blazor comparison chart: https://frequal.com/java/TeaVmVsBlazorChart.html https://frequal.com/java/TeaVmVsBlazorChart.html TeaVM longer comparison with Blazor: https://frequal.com/java/TeaVmVsBlazorWasm1-0.html https://frequal.com/java/TeaVmVsBlazorWasm1-0.html Java Magazine article on Flavour and TeaVM: https://blogs.oracle.com/javamagazine/post/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
- gwbas1c 4y ago
  > TeaVM vs Blazor comparison chart Blazor has the full task API. Asynchronous tasks run just like Javascript promises. Does TeaVM have true threading, or is it emulating threads via some higher-level concept? (IE, if I have a multicore CPU, will TeaVM take advantage of multiple cores?) Unless you're trying to do true CPU-intense parallel computing inside the browser, where you need the power of real CPU-level concurrency, "real threads" in the browser has no gain over the task API.
NBJack 4y ago
I think the real killer of Java in the browser was Flash. It was still terrible, but Flash was way more accessible.

knome 4y ago

>as a fan of Blazor I really dislike this stuff. It's easy-ish to write, but it's like the authors of it hate everything about the web. SPAs do a lot of annoying stuff, and blazor encourages all of it. I really hope things swing back away from this grotesque tight binding between the server and the client.

gwbas1c 4y ago
One of the nice things about SPAs is that they allow navigation without the latency needed to re-load all assets. You can get there the old-fashioned way if all your assets are cached in the browser with long timeouts; but that implies that you're doing something like putting hashes in the asset URL and hashing them as part of your build process. (This, is why loading JavaScript and CSS from CDNs helps with performance.) Otherwise, every time you navigate to a new page on a non-SPA, the browser still needs to send an IF-CHANGED-SINCE request to the server. As a developer, though, the BIG drawback of SPAs is that they require building much stricter APIs for everything. In a traditional server-side HTML page, you can quickly prototype something where the code that's putting together the HTML has access to privileged data that you can't expose through an API. (IE, if you just need to prototype something, server-side HTML rendering code can directly talk to the database.)
- ptx 4y ago
  > One of the nice things about SPAs is that they allow navigation without the latency needed to re-load all assets. [...] You can get there the old-fashioned way if [...] you're doing something like putting hashes in the asset URL and hashing them as part of your build process. But that solves the problem, doesn't it? And it seems a lot simpler than implementing an SPA. Django has this feature built-in. You just have to enable ManifestStaticFilesStorage: https://docs.djangoproject.com/en/4.2/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage https://docs.djangoproject.com/en/4.2/ref/contrib/staticfile...
  - gwbas1c 4y ago
    > And it seems a lot simpler than implementing an SPA Depends on your design goals. BTW, I'm not pro/against SPAs. It's just a tool, and like all tools, they have their advantages and disadvantages. In general, the fact that you can update the page without a server-side round trip is a major advantage. Granted, you can also do that with server-side rendering; but then your rendering logic is defined in two places.
dagaci 4y ago
I think you’re a little misconceived, WebAssembly runs entirely in the client and have no bindings to the server, as far as the server is concerned such apps may as well be static HTML. This is Blazor WebAssembly. It will be just as trivial to run such on Mac, Linux or Windows server or any other plain web servers. TeaVM seems to be the same except it compiles Java to JavaScript which means has fast startup times. Web browsers and their fundamental development foundations are best described as a set of mostly well meaning compromises, and so even modern browsers have been updated to support all the other disagreeable things you have mentioned, even having the ability to navigate the browser history within an SPA
- knome 4y ago
  Ah, sure, for whatever WASM variant you're referring to. Whichever form of blazor I use pretty obviously makes calls back to the server to interact with client state on a per-event basis. If the backend has to restart, the clients all lose connection and die. I won't pretend to be an expert in the framework, or even C#. I had avoided both until recently, and this introduction hasn't made me particularly fond of either.
  - gwbas1c 4y ago
    Server-side or WASM is an option when you create a Blazor project in Visual Studio. You can write libraries and either approach can use the same library. Server-side Blazor keeps a websocket open to send messages back and forth. If you can tolerate the latency, it allows your UI code to be able to handle data that needs to remain secret on the server.
  - dagaci 4y ago
    Its pretty fundamental stuff to know the difference between what is server side and what is client side. I think you will have a lot of trouble undertanding a framework without this. Blazor WebAssemly requires you make explicity Ajax-like Calls to external web services in order to interact with a server and data. There is no server side framework in WebAssembly for maintaining state. State is entirely client side. Blazor Server basically uses Web Sockets (with fallbacks) to communicate changes between client and server, this is far more efficient than using http request calls. State here is server side. But differs from all other frameworks in that state is trasmitted over sockets not http requests. I'm not convinced you have actually used any kind blazor tbh

TeaVMFan 4y ago

Agreed that many people will want to build true web single-page apps, not port Swing to the web in a Canvas. A Java option for modern web apps exists, and it's called Flavour: https://flavour.sourceforge.io/ https://flavour.sourceforge.io/ * Build SPAs in Java with HTML templates and components * Fast build times and batteries-included build framework * Easy calls to Java web services, just invoke a method and Flavour handles marshalling and unmarshalling, you just see/use Java objects. * Full-stack refactoring * Built on TeaVM, so you get the all the benefits of a mature, performant framework with support for threads and multiple JVM languages (bytecode-based transpilation). TeaVM vs Blazor comparison chart: https://frequal.com/java/TeaVmVsBlazorChart.html https://frequal.com/java/TeaVmVsBlazorChart.html TeaVM longer comparison with Blazor: https://frequal.com/java/TeaVmVsBlazorWasm1-0.html https://frequal.com/java/TeaVmVsBlazorWasm1-0.html Java Magazine article on Flavour and TeaVM: https://blogs.oracle.com/javamagazine/post/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/post/java-in-the-brows...

gwbas1c 4y ago
> TeaVM vs Blazor comparison chart Blazor has the full task API. Asynchronous tasks run just like Javascript promises. Does TeaVM have true threading, or is it emulating threads via some higher-level concept? (IE, if I have a multicore CPU, will TeaVM take advantage of multiple cores?) Unless you're trying to do true CPU-intense parallel computing inside the browser, where you need the power of real CPU-level concurrency, "real threads" in the browser has no gain over the task API.

NBJack 4y ago

I think the real killer of Java in the browser was Flash. It was still terrible, but Flash was way more accessible.