If only we could get a new version of Java for the browser. Something more of a scripting language that is not compiled but interpreted. Could probably knock out a proof of concept in a week, might call it Javascript or something...
In all seriousness, anything that spits out canvas for a simple textbox is completely misguided about what the web is.
>If only we could get a new version of Java for the browser. Something more of a scripting language that is not compiled but interpreted. Could probably knock out a proof of concept in a week, might call it Javascript or something...
I get the joke. It is sad though how Java didn't end up being the ubiquitous runtime for browsers... It started off so promising... Compiling source to byte code is really fast in Java (and modern browsers generally do much more work compiling JavaScript). Even if the browser downloaded source code (and why not? --byte code is so much more compact and faster to parse), you wouldn't even notice the compiling down to bytecode step.
> It's amazing how badly the Java ball got dropped.
It still boggles my mind that Sun Microsystems fully owned the tech for the only ubiquitous browser plugin for full fledged applications with > 95% deployment and somehow screwed it up and went out of business a few years later. Despite all their engineering prowess it seems like they just couldn't make Java work seamlessly and smoothly. I'd like to think it was just a hard engineering challenge, but as someone who went all in on Java WebStart for deployment at one point and then watched them take it from a highly attractive platform to actively ruining it within a few years, I have to attribute it more to incompetence.
I worked at Sun during that time period, and as much as they liked to pretend they were a software business, they were a hardware business whose primary feature was software, which is really, really not the same thing.
They never really figured out how to be in the software business if it wasn't in service of selling hardware. Such an amazing fail.
I recall those days. To be fair, it was asking a lot of the hardware at the time to run both a browser and Java itself. I also recall the JVM had painfully slow start times that weren't rectified for years. These were also largely the 1.x versions of the language to boot.
On top of it all, Java integration was really just an excuse to plop a grossly out of place app UI in the browser window. Would have been much better if we could have had deeper behind the scene integration with the DOM layer.
HotJava was pretty much proof that you could have Java well integrated into the browser. If you can do the browser entirely in Java and run applets smoothly, then there is no reason why a "better" browser runtime/implementation couldn't be even smoother.
The problem was that the browsers were busy loading up on every feature they could (including JavaScript) while also providing Java runtimes that would load after the fact (and the Java load times were often much better than the browser load times, but since the Java runtime load was deferred, it was a much more painful experience).
You could keep browsers lightweight by doing much of the stuff browsers were doing into Java, but the problem with that is that the browsers were in a race to differentiate from each other, and the whole point of Java was that the experience was uniform. So instead we got a rush of poorly considered browser capabilities that we were stuck with for an extremely long time.
I can't blame the browser makers... Sun never came up with a business proposition for them that encouraged focusing on a better Java experience.
I graduated college around that time. Microsoft held an event on campus that took two hours, explaining how great it is to work at Microsoft. A month later Sun came to campus and spent two hours telling us how awful Microsoft is and we shouldn't have anything to do with them. What they didn't do was tell us why we should want to work for Sun. On a larger scale, Sun did seem to lose focus and concentrate too much on getting Microsoft back for making a faster and more stable JVM. What they didn't do was come up with improvements that users wanted. At least not at the rate they should have.
Yeah, Sun stock really soared when they started going after Microsoft, but I kept pointing out that the valuation was from the distorted perception where they looked bigger because they were taking on a big foe. It was a sugar high that was obviously going to come crashing down if they weren't focused on delivering a better product.
* 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).
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.
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.)
> 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.
> 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.
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
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.
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.
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
At no point was I confused as to the server-side vs client-side nature of the software. I've been using what I assumed was the default of server-side blazor and was casually agreeing that, yes, a WASM compiled variant would obviously run fully in the browser.
>I'm not convinced you have actually used any kind blazor tbh
It's just a question of time before the containerized crowd discover that the exact version of Chrome they test their website with can be compiled to the WASM+canvas platform, bundled with the website, and solve all browser issues forever...
Then we would have a horrible culture of polyfills and transpilers. We would have code that gets shipped unmiminized and with comments that weren’t removed. Eventually, that language will get repurposed for other tasks such as server-side applications or even mobile-applications (imagine shipping a separate runtime for extra language in mobile apps, ugh) due to the growth of the web and the rise in the number of web developers.
That sounds like a horrible idea. I hope it never comes to fruition.
In all seriousness, anything that spits out canvas for a simple textbox is completely misguided about what the web is.