https://zenn.dev/koduki/articles/c07db4179bb7b86086a1
I shared it.
Introduction
I saw an article buzzing that " Maybe Rust is next to Typescript ".
It's quite interesting, and it's an article comparing WASM and Rust as PA. Just recently, as I wrote in " Uncle Legacy, I started SPA. And I know the limits ", I recently tried out SPA, but when I try to do various things, I need Backend for Frontend (BFF) etc. for SSR. I knew that, and I felt "Isn't it necessary to do this with JS?", So it was just right.
When you see this kind of thing, you can see various technologies such as technologies that are obsolete with similar approaches like RIA and GWT, Meteor that appeared too early, and Blazor of MS that is still working hard. So, in order to get a bird's eye view of history, I would like to consider the history of the conflict between HTML + JavaScript and other technologies, and approaches using Webassembly such as MS Blazor and Rust's yet.
In addition, since the history of the battle has become longer than I expected, people who said, "I don't care about the story of the past, is it important now !?" " Does Webassembly (WASM) dream of Web UI? " Jump up to!
Champion JavaScript, history of battle
Since its introduction, HTML + JavaScript has repeatedly threatened its status as a UI standard for the Web. And we have won all of them.
It started with Java Applet
HTML first appeared in 1993, but at that time it was intended to publish papers and dynamic actions were not possible. This kind of interactive operation on the Web is from Java Applet, which appeared in 1996. JavaScript came out at about the same time, and at that time it seems that Netscape and Sun strategically gave the misleading name JavaScript as a complement to Applet by forming a business alliance.
The story around here was just recently talked about in Misreading Chat and it was very interesting.
MS also created ActiveX (and VBScript / JScript) against it, but eventually they failed. It can't be helped because the security standards are different from those of today. Now it's still in the Legacy, and it's about collecting grudges.
Then, with the advent of DOM in 1998, Dynamic HTML (DHTML) made JavaScript + HTML eradicate Applet and ActiveX and became the standard UI for the Web.
ASP.NET and JSF, thugs called components from the server side
Microsoft's ASP.NET , which appeared in 2002, was the first thug to break HTML + JS from an "application front end" perspective .
At that time, AJAX was not established yet, but it was an era when it was possible to make DHTML behave richer.
JavaScript was a less powerful language than it is now, and above all, the ecosystem and libraries for development were incomparably poor.
Therefore, it was not an environment that could be said to be highly productive to compliment in order to build a rich UI.
In addition, the Web UI was positioned as a "bonus attached to the server-side system" rather than the API as the center as in modern times. Therefore, it is a feeling that the engineer on the server side will port the screen of Photoshop made by the designer and HTML to the template engine if you are lucky. "I don't want to touch a language different from JS or the server side in the first place."
Meanwhile, ASP.NET has been brought up by MS, which has the strongest GUI development platform Visual Studio and .NET Framework.
This was a dream-like technology that allows you to create web pages graphically like VB or C # with a GUI editor and write the front end in C #.
Assembling GUI parts as components, realizing component-oriented and event-driven like React / Vue now. Even if you can write it in C #, you do not write the code that is executed directly in the browser, but you write the component calls etc. and these components are converted to HTML and JS and executed in the browser.
For better or for worse, it was a good technology to realize "development of desktop-like applications by abstracting HTML knowledge, HTTP communication mechanism, data exchange between browser and server, etc."
ref: https://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp05/entwebapp05_01.html
However, despite the abstraction, browser specifications are limited, so I had to be aware of it as a result, and I couldn't really say that it was a "dreamy technology."
By the way, JSF (JavaServer Faces) 1.0 also appeared from Java. This is the Java version of ASP.NET. I changed the route from 2.0 series.
Component-oriented, event-driven, powerful language and ecosystems seem to be the right direction, but as a result, they're virtually obsolete.
Well, ASP.NET is alive normally, but now I think I've changed the direction with a GUI editor. I'm a little unsure. That said, it's definitely not the mainstream of web development.
I think there are several reasons, but my personal opinion is that it wasn't vendor-neutral, so it was slow to spread, and as a result, it became difficult to integrate with the Web ecosystem.
The advent of AJAX and the return to a simple template engine
Introducing AJAX
A major web revolution comparable to the advent of JavaScript is the advent of AJAX in 2005.
There has been DHTML since that time, but it had the aspect of "toy-like production" such as "★ chases behind the mouse cursor" or "petals fall when you open a web page". .. For the time being, there was a way to use it by incorporating it into a proper UI, but it is a fairly rare case.
"Google Map" has renewed that recognition and made JS a real tool from a toy. Since the basic UI hasn't changed from now, dragging the screen from the time of its appearance allowed you to change the scale and coordinates infinitely "without reloading".
It's a natural behavior nowadays, but until then, the map application has buttons on all sides and the top of the screen, and when you press it, it "draws the entire screen" and displays the map of the destination. It was.
The idea of calling the API asynchronously without reloading these screens was revolutionary. After that, the boom of using AJAX in every part begins.
Despite the transient boom, the interactive Web that connects to the present age was born from here. Nowadays, I feel that I don't dare to use the word AJAX, and above all, the debate about whether it's DHTML or AJAX is a long time ago.
Introducing Ruby on Rails, jQuery, Bootstrap
Around this time, what happened at the same time was the breakthrough of LL represented by Ruby on Rails and the accompanying simplification of the template engine.
As a result, ASP.NET and JSF have expanded beyond the so-called Web neighborhood, and even the enterprise domain, which is the main battlefield, has been eroded by the LL language, mainly in the front-end system.
Also, I don't know the detailed reason for these FWs, but as a result, they are not component-oriented, but adopt simple MVC Model 2, and the template engine is simple enough to bind loops, conditional branches, variables, and create layouts. It is a thing and does not adopt event driven. Some of them used Click and Wicket, but aren't they popular?
This is an imagination, but the specifications such as Post Back were too abstract and unfamiliar with Web development, and above all, plain HTML to support AJAX, which has just appeared and is rapidly evolving. It's probably because it was easier to handle if it was closer to HTTP. In the old days, Rails also had a mysterious specification to convert Ruby to JS, but it disappeared in the middle. I don't really like Post Back because the URL is messed up. .. .. I think this is the reason why the template engine has simply returned.
With the advent of Prototype.js and jQuery, cross-browser support, which was difficult, has been improved, and CSS frameworks such as Bootstrap have become widespread in terms of UI design, creating a common ecosystem on the front end regardless of server-side technology. It's starting to be done gradually.
Personally, I don't think there was an independent role as a front engineer yet, but it is also the emergence of a language-independent "front end" area.
RIA Hyakka Ryoran
There is a technology called RIA (Rich Interface Application) or [Rich Client].
This is a general term for technologies that provide an interface that is more sophisticated than traditional HTML and that looks like a desktop application.
There are various things such as those based on plugins such as Curl and Flash, and those that are finally converted to HTML + JS such as GWT, but the common thing is that "do not write plain JS or HTML directly". ..
In a broad sense, it may include HTML5, and even with the above definition, Vue.js + TypeScript seems to fit the definition of RIA for the time being, but I will not consider it here.
Eventually it became HTML5 and its expressive power improved, and it became obsolete as a result of the evolution of the JS ecosystem and language described later, but it will be a great reference when thinking about the Web front end using WASM. ..
It's also important to note that although many RIAs have appeared and were popular, they haven't been on the Web UI throne for a second. Both individual products and site successes have failed in that they have not become mainstream.
Flash-based favorite RIA-Adobe Flex
Flex is Adobe's platform that made it possible for RIA to create UIs for full-scale business applications in 2004, based on Flash, which had an overwhelming share at the time.
Traditional Flash is for creating animations and game-like interactions, so it's not suitable for writing regular applications.
That's why Adobe introduced MXML, a unique XML-based UI description language, and JavaScript2 (ECMAScript4) -compliant ActionScript3, a version of the lost language, as the RIA platform.ECMAScript4 was a Java-like writing language with types, full-fledged classes, and above all, modules and namespaces, unlike JavaScript today or at the time. Even though it has a type, it was not a JS spar set like TypeScript, but a completely different one. It may be popular now, but at that time the language specifications were too different to accept it , and it was destroyed even though Tamarin was released as OSS as the execution engine of JS2.
I even made a desktop environment called Adobe Air, but it ended without spreading. Since Flash itself is finally obsolete, there will be no resurrection.
It should be noted that Flex, which has a virtually 100% share of plug-ins called "Flash plug-ins" and has no introduction barrier, which is a weak point of plug-in type RIA, has not spread.
Microsoft's Liver-Silverlight
Silverlight is a RIA developed by Microsoft in 2007. It is a subset of WPF (Windows Presentation Foundation)
, a technology for the Windows desktop . As a UI description language, XAML is supported like WPF, and .NET can be used as it is, so it is possible to run major LL such as JavaScript (JScript .NET), Ruby (IronRuby), Python (IronPython) as well as C #. Also supported strong architectural patterns such as MVVM.
Functionally, it strongly supports DRM and video playback functions, and I feel that I have lived for quite a long time in the position of a video player. In addition to IE, it should have provided plugins for major browsers at the time such as Chrome, Firefox, and Opera. I think smartphones weren't supported, but that's probably because they didn't become popular as a result. It was destroyed because MS itself focused on HTML5.
It has nothing to do with the main story, but for some reason it has been anthropomorphized by Microsoft Taiwan. Well, it's MS, isn't it?
Notably, even with a strong ecosystem that supports multiple languages called the ".NET Framework", we couldn't win.
AJAX was made by me-Google Web Toolkit (GWT)
GWT is a RIA environment created by Google in 2006.
The biggest feature is that unlike the above two, it is not a plug-in type.
Speaking of Google, it is a key player who effectively used AJAX with Gogole Map and GMail and spread it to the world, but at the same time, I think that the difficulty of developing AJAX with JS was also ingrained in the body.
So, in GWT, Java is converted to JavaScript and the appearance as SPA is also arranged. It's an AltJS-like idea now. It can be said that it is very close to a configuration like TypeScript + Vue.js, including the point of supporting SPA.
Since it is Java, not its own language, it can be used with NetBeans and Eclipse, so I think that it was attracting attention as it was, but Java at that time was not so modern, so I think that it can be said that it has become very popular. increase.
I can write RPC simply, and I can write powerful IDE and UT using JUnit, so I think it was a powerful option when the JS ecosystem was not in place.
At that time, the idea of transpiling to JS and optimizing at the time of transpiling was rare, so I think that the results of this area have probably been taken over by Google Closure Tools .
By the way, such GWT did not overthrow HTML + JS.
The predecessor of HTML5? Introducing Google Gears
RIA is driven out by HTML5, but Google Gears , which appeared in 2007, was born before that HTML5 .
Google Gears is characterized by the enhancement of the browser itself such as the offline operation function of the web application and the support of Geolocation, and the API can be called from JS. The following functions have been added.
- Database module (using SQLite). Data can be stored locally
- WorkerPool module. Provides parallel execution of JavaScript code
- LocalServer module. Cache and provide application resources (HTML, JavaScript, images, etc.)
- Desktop module. Allow web applications to interact more naturally with the desktop
- Geolocation module. Allow web applications to detect a user's geographic location
People who think they have seen it somewhere have a sharp intuition. Yes, these features have already been incorporated into HTML5. As a result, Gears also ended properly in the sense of migrating to HTML5. In that sense, Gears has been taken into the mainstream and is a little different from being "obsolete".
At that time, it was a winter era when the evolution of JavaScript and HTML itself was stagnant, but it seems that Google Gears has made a hole in it. These features were used not only in Google products such as GMail and Google Docs, but also in other applications. It wasn't as widespread as it was, but it wasn't just Google's. Plugins were provided in addition to Chrome.
Since getting Chrome, Google has been fond of this process of "pre-implementing the APIs needed for its services in Chrome and then incorporating them into the standard." SPDY => HTTP2, QUIC => HTTP3. This area is different from Mozilla, which does not have a major product.
If you are accused of what is different from the original extension of IE in the past, it will be difficult to comment, but it is the difference of the times and the attitude of bringing it to standardization properly. maybe. Speaking of MS's famous proprietary extension, ActiveX-based XHTTPRequest would not have appeared without AJAX, but it was not standardized, but rather IE and others. .. .. That is a waste.
* I was pointed out by @tadsan and remembered the existence of Gears. Thank you!
Spread of smartphones, HTML5, nodejs-Completion of ecosystem
While RIA is likely to be popular and not popular, a major change will occur on the JS side.
It is the spread of smartphones, the release of HTML5 and the spread of node.js.
First, with the spread of smartphones, the number of "client applications" called Android apps / iOS apps will increase in large numbers.
This has brought us back from the era of web-based applications to the era of client-server. Therefore, the final output on the server side has been switched to API-based APIs such as XML and JSON instead of HTML templates. Originally there was API I / F for server-to-server communication and AJAX, but this became the main rather than the auxiliary.
Then, preparing a template engine for the Web would be confusing because the server side would have to support two paradigms. So, better yet, the idea of creating all fronts with static pages and calling dynamic functions only with Ajax is SPA.
This clarifies the responsibilities of the front end and back end, and simplifies the server-side technology by sharing it with smartphones.
At the same time, on the server side as well, the flow of building a system based on APIs in the form of "microservices" became a movement, so it met the need to make the final I / F of the server an API.
Next is the introduction of HTML5. This has greatly improved the expressiveness of HTML. Functions that were previously said to require external plug-ins such as Flash can now be performed with standard HTML functions. At the same time, ECMAScript has resumed evolution, and especially in ES6, various modern functions have been incorporated, so the weakness of the language itself has been greatly improved.
And finally, the spread of nodejs is important. This isn't directly related to JavaScript as a front end, but I think it's huge in terms of accelerating the JS ecosystem. like npm. With nodejs, JS has built an ecosystem that is suitable for business use as well as other languages, and it has become possible to achieve high productivity along with the evolution of the language itself.
With the expressive power of HTML5 and the improvement of productivity due to the spread of nodejs, we completely overthrew various RIA.
Meteor too early
Do you know a framework called Meteor ? It is an integrated FW that develops client-side, server-side, and DB as one, advocating the Isomorphic JavaScript web framework. It's SPA + BFF + mBaaS.
It appeared in the very early era of 2012, but at that time I think that the point that it was a server-side DB that can be reactively used from the client side like Firebase was emphasized. The Fireabase Real-time Database was also released in 2012, so it is a terrifying advance.
I didn't ask my name recently, but I still lived normally.
Well, this is JS + HTML itself, so it doesn't conflict with the current flow, but I thought it would have a big impact on "Universal" in Next.js / Nuxt.js, so I mentioned it. I don't know if the direction has changed since then because I haven't looked at the details, but I will talk about the image of Meteor at the time of 2012-2014.
Spread of SPA and advance to server side
JS has completely taken the front end position from the server side, but this time it will attack the server side.
Well, I was driven by the need to attack. .. .. I feel like that.
SSR and SSG are required for performance and SEO (including OGP tag optimization), and BFF (Backend for Frontend) is required as a platform to execute them.
Regarding BFF, the following explanation was easy to understand.
Also, it seems that FW that also covers the server side for SSR like Nuxt.js and Next.js has appeared. It seems that you call it "universal" or "isomorphic".
Meteor comes to mind when I say "isomorphic," but I think it's a little different.
Meteor is completely All in One and is the ultimate monolith. Even if you reach out to the same server side from the client side, that is not the case. Meteor should be a basic approach to write business logic other than presentation in Meteor.
On the other hand, I can't say for sure because I haven't used Nuxt.js etc. yet, but I think that BFF exists as an aid to supplement the restrictions of SPA. In other words, from the perspective of the entire system, BFF is a service that SSR is responsible for, which is extremely microservice-like. It's just a smart CDN. So there should be no business logic there. Business logic should be written on the server side and called by API as the basic configuration.
Well, in the present age when the client layer is thick, it may be small, or if security is not important, business logic may be written to the client, but that is it.
Anyway, it's been about 20 years since HTML + JS got the front end position. HTML + JS is now the front-end champion after defeating all the RIA players.
What is WASM?
At the end of the history of JS and front ends, next is WASM.
What is WASM ? A binary format that can be executed in a browser. A low-level language on the web. Although it is such a standing position, it is still necessary to study history a little in order to know it properly. When did IT become a liberal arts subject? .. ..
To ActiveX, NaCl, asm.js, and WASM
The first to appear is the ActiveX control that appeared in 1995-96. This is a specification created by Microsoft and is based on Object Linking and Embedding (OLE). Very roughly speaking, code written in C language other than JS can be executed natively, and the file system and hardware can be hit beyond the limits of the browser, so high-performance and high-speed ones can be created. However, since the browser does not become a sandbox, security problems have increased and it has become obsolete.
And in 2009, Google developed NaCl . This can execute native code compiled with C etc. with the Google version of ActiveX. At the same time, we enhanced the security that was mentioned as a problem with ActiveX and provided a sandbox that made it impossible to directly access the hardware and fill system. Now that we have WASM, we have finished development.
Meanwhile, Mozilla has blamed Google's approach for developing asm.js. This is not a native code execution platform, but a subset of JS that can be implemented at high speed and is easy to maintain compatibility with C language. The biggest achievement is to convert the LLVM binary generated from C / C ++ called Emscripten to asm.js and execute it.
The game engine has been ported quite a bit with this guy. However, since it is essentially alt.js, it was said that I wanted a more fundamental solution.
That's where Webassembly (WASM) came out in 2017.
It is a low-level language based on binary, unlike high-level languages such as JS, which was developed based on asm.js and NaCl.
ref: https://ukyo.github.io/wasm-usui-book/webroot/what-is-webassembly.html
In other words, WASM can be said to be native (like) code executed by the browser, as if the browser were an OS / virtual machine.
Various language implementations can execute any code by compiling for WASM as well as compiling for Linux on x86. Rust / C ++ (LLVM) / Go / Kotlin is a well-known language that supports WASM, but in theory it works fine if other languages are also supported.
JavaScript and WASM
Regarding the relationship between JavaScript and WASM, JS is basically the main, and it is currently positioned when WASM is partially used where performance is required.
In particular, WASM has restrictions on DOM access, so it cannot be simply replaced. Also, JS is by far the most tuned language in LL as a result of the browser wars, so WASM doesn't always seem to be faster. This area will be solved if the WASM processing system matures.
AltJS and WASM
Attempts to run languages other than JavaScript in browsers have been made for many years, most of which are transpilers called AltJS. In rare cases, there is also a type that writes a VM in JS and processes it in a language.
The most famous is TypeScript, and the first one to make it famous is CoffeeScript, isn't it?
Since these are JS to the last, there is no problem if they are simply syntactic sugar level, but for those that greatly exceed the functions of JS, it is necessary to implement VM with JS in some cases. must. Maybe Opal or Scala.js implements a VM? I haven't read the code or documentation, so I'm not sure. Both Opal (Ruby) and Scala.js (Scala) are like transpilers. Mr. todesking pointed out in the comments.
Since it is a low-level language, WASM is easy to handle in this area. Since it is relatively easy to create by applying the know-how of creating a normal VM or compiler, it is easy to create a language that is not compatible with JS.
Does Webassembly (WASM) dream of a Web UI?
Now, contrary to the schedule, the history part has become long, but let's think about WASM + Rust, which is also included in the title.
If you've read this far, you'll have a good grasp of the historical background.
Why did RIA die in the first place?
First, let's learn from the failure of RIA, which is a close story. I think there are many reasons for this, but if you take the background of the times by chance, the following two points are important.
- Difficulty in spreading your own ecosystem
- Integration with standard web technology
Flex, which had cleared enough points in terms of popularity, also died. There are many things, but it is still difficult for Adobe at that time to create a new ecosystem of its own. Simply creating a development language or IDE is not enough. Many libraries and communities, including OSS. And the appeal of just migrating from an existing platform. Imagine it's not easy to make all this.
In the case of Silverlight, there is a big thing called .NET in the sense of the development ecosystem, but MS at that time was quite closed and the corporate color was too strong and I did not feel like using it for anything other than MS related. I think. There was no atmosphere to use in combination with the LAMP environment and Rails that were popular at that time, and it seemed like a part when solidifying with MS products, which may have hindered its spread.
Also, the important point is that the plug-in type RIA is completely different from the existing Web, so it is not possible to exchange data, integrate the layout well, incorporate Web parts into the RIA side, and vice versa, so such a seamless transition. The reason why he died is that he couldn't do it. Integration with these standard web technologies tends to be a challenge. At least I found it difficult to use.
GWT seems to be good in that sense, but it's simply because Java is disliked more than it is now, or because it's hard to play with the code converted to AJAX and it tends to be a unique world. I feel like. It doesn't mean that it's going to be popular because it doesn't meet the conditions for dying.
In this regard, WASM can incorporate an ecosystem of existing languages, and since it is a member of Web standards in the first place, it is a big advantage that it does not have a different world view.
It is supported in most environments including smartphones, and I think there is a "soil" that does not repeat the failure of RIA in the past.
Benefits of WASM + non-JS languages
Ultimately, this is only one point that "languages other than JS can be used", but what makes me happy is that the same language as the server-side language can be used. After that, when you want to develop an isomorphic and monolithic Web like Meteor or GWT instead of the direction of BFF like Next.js.
The former is useful when there are few engineers such as startups and individual projects. In the case of the Web, it is a model that can be taken only when the server side is node.js, but I think that there is a big part that will be easier if this restriction is removed.
In this case, what is important is that it can be well integrated with existing mechanisms such as JS and HTML. There aren't many libraries for the web front in most languages, so you'll want to use JS there. It's really important that you can use what you find on the Web. At the same time, if it is an existing language, such as Ruby, I feel that it is okay to migrate if I can use Gem or the library I made in the past.
The absolute condition to achieve this is to maintain the HTML even if the component is imported. I think the front-end ecosystem is already too mature to add proprietary syntax like XAML or FXML now.
Next is Isomorphic and monolithic Web development, which goes against the current flow of microservices, but not everything can be made into microservices. If you can create a SPA-like application with a single language / single framework with SEO in a batch, it is the best for prototype development and startup.
I feel that this area is absorbed by NoCode / LowCode in terms of business, but I personally want it.
WASM compatible front end framework
I would like to take a look at some WASM-enabled web frameworks.
Yew
This is Rust-based Yew, which was also introduced in the original article.
It advocates JavaScript interoperability on a component basis. It's good to say that it's interoperable with JS.
The sample code looks like this. At first glance, it looks like React.
Click here for other samples.
use js_sys::Date;
use yew::services::ConsoleService;
use yew::{html, Component, ComponentLink, Html, ShouldRender};
pub enum Msg {
Increment,
Decrement,
}
pub struct Model {
link: ComponentLink<Self>,
value: i64,
}
impl Component for Model {
type Message = Msg;
type Properties = ();
fn create(_props: Self::Properties, link: ComponentLink<Self>) -> Self {
Self { link, value: 0 }
}
fn update(&mut self, msg: Self::Message) -> ShouldRender {
match msg {
Msg::Increment => {
self.value += 1;
ConsoleService::log("plus one");
true
}
Msg::Decrement => {
self.value -= 1;
ConsoleService::log("minus one");
true
}
}
}
fn change(&mut self, _props: Self::Properties) -> ShouldRender {
false
}
fn view(&self) -> Html {
html! {
<div>
<nav class="menu">
<button onclick=self.link.callback(|_| Msg::Increment)>
{ "Increment" }
</button>
<button onclick=self.link.callback(|_| Msg::Decrement)>
{ "Decrement" }
</button>
<button onclick=self.link.batch_callback(|_| vec![Msg::Increment, Msg::Increment])>
{ "Increment Twice" }
</button>
</nav>
<p>
<b>{ "Current value: " }</b>
{ self.value }
</p>
<p>
<b>{ "Rendered at: " }</b>
{ String::from(Date::new_0().to_string()) }
</p>
</div>
}
}
}
fn main() {
yew::start_app::<Model>();
}
Blazor WebAssembly
Microsoft's Blazor WebAssembly. It's great to make it properly every time without being disappointed with ASP.NET. Originally Blazor running on the server side was released first, but Blazor WebAssembly was recently released and since this is WASM, it can even be deployed to a CDN.
When I go to an MS conference, the venue is full, and MS engineers are paying close attention to it, right?
It can be developed with C # etc., but it is quite interesting in terms of architecture, and instead of converting C # to WASM, .NET Core implemented with WASM is executed on the browser and C # and Razor components are run there. .. Are you serious.
You can write the code like this and it feels like Vue.js. Take a quick look.
@page "/todo"
<h3>Todo</h3>
<ul>
@foreach (var todo in todos)
{
<li>@todo.Title</li>
}
</ul>
<input placeholder="Something todo" @bind="newTodo" />
<button @onclick="AddTodo">Add todo</button>
@code {
private IList<TodoItem> todos = new List<TodoItem>();
private string newTodo;
private void AddTodo()
{
if (!string.IsNullOrWhiteSpace(newTodo))
{
todos.Add(new TodoItem { Title = newTodo });
newTodo = string.Empty;
}
}
}
The following articles are also helpful, so you may want to read them.
TeaVM
WASM front end made by Java.
Strictly speaking, it is converted not only to WASM but also to JS, and it seems to be the main one now. Unlike GWT, it converts Java bytecode, so it seems to be compatible with Scala and Kotlin.
@BindTemplate("templates/fibonacci.html")
public class Fibonacci {
private List<Integer> values = new ArrayList<>();
public Fibonacci() {
values.add(0);
values.add(1);
}
public List<Integer> getValues() {
return values;
}
public void next() {
values.add(values.get(values.size() - 2) + values.get(values.size() - 1));
}
}
<ul>
<std:foreach var="fib" in="values">
<li>
<html:text value="fib"/>
</li>
</std:foreach>
<li>
<button type="button" event:click="next()">Show next</button>
</li>
</ul>
Vugu
A framework for writing front ends in Go.
The sample code is as follows. It seems fun to be able to write Go as if you were writing HTML normally. Looking at the code, the server side is also included and is it a universal system rather than a pure SPA?
<div>
<main role="main" class="container text-center">
<div class="mt-5">
<h1>Welcome to Vugu</h1>
<p class="lead">This page is being rendered via
<a @click='event.PreventDefault();c.ShowWasm=!c.ShowWasm' href="https://webassembly.org/">WebAssembly</a>...
</p>
<div vg-if='c.ShowWasm' class="alert alert-primary" role="alert">
<strong>WebAssembly</strong> (abbreviated Wasm) is a
binary instruction format...
</div>
</div>
</main>
</div>
<script type="application/x-go"> type Root struct { ShowWasm bool `vugu:"data"` } </script>
package main
import (
"log"
"net/http"
"github.com/vugu/vugu/devutil"
)
func main() {
l := "127.0.0.1:8844"
log.Printf("Starting HTTP Server at %q", l)
wc := devutil.NewWasmCompiler().SetDir(".")
mux := devutil.NewMux()
mux.Match(devutil.NoFileExt, devutil.DefaultAutoReloadIndex.Replace(
`<!-- styles -->`,
`<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css">`))
mux.Exact("/main.wasm", devutil.NewMainWasmHandler(wc))
mux.Exact("/wasm_exec.js", devutil.NewWasmExecJSHandler(wc))
mux.Default(devutil.NewFileServer().SetDir("."))
log.Fatal(http.ListenAndServe(l, mux))
}
summary
There was a story about WASM front end in the article "Maybe Rust next to Typescript", so I wrote this article to compare it with RIA at that time, but the introduction to explain RIA at that time is very It has become long.
Well, as a result, I was able to dig up something like the history of the Web and organize it within myself.
I searched for some WASM front ends of the main subject and picked them up, but it seems that the direction is not bad because of the nature of RIA's reflection and above all, React / Vue.js as a model. Impression that there are many products.
In terms of the degree of perfection at the moment, I feel that the atmosphere is not good except for Blazor WebAssembly where MS is working hard, and above all, there is a strong luck factor when it is not popular, but this area will evolve aiming for a more convenient tool. I'm looking forward to it. Probably not in the mainstream, but if you can have a standing position like a sub with a strong presence, it will be practical enough.
Then Happy Hacking!
0 コメント:
コメントを投稿