4 ms·

If you have the ability to compile <insert your favorite language> to WASM, and a little glue in the form of an isomorphic application framework (something to g

If you have the ability to compile <insert your favorite language> to WASM, and a little glue in the form of an isomorphic application framework (something to glue together server-side with client-side processes), I'd say it's quite a compelling alternative to JS. If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one? I'm thinking, for example, something like this... write C#, use a framework (fictional "Isomorph#") that can determine whether code should run on the client or server, and if you have interfaces to UI, you have the full solution. C# (client/server) + WASM/JS + remoting/web services + HTML/CSS/SVG/etc UI = real "apps". And that could just as easily have been Python (client/server) + WASM/JS and the rest of the stack, or Go + WASM/JS.. etc. etc. I was shocked when I learned of Skulpt.org, which is a python interpreter running in the browser - so we can't be far off from the same thing running on WebAssembly.

austincheney 9y ago
> If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one? That is not necessarily a language oriented concept. JavaScript can run on the front-end and back-end having an MVC architecture at both points. A better question is why a developer should wish to impose MVC at all at either point? These concepts become easier to reason about when the software runs at a single location using an HTTP service (on localhost) to talk amongst its clusters. It is just a multiprocess application with the bits running asynchronously from each other. When one (or more) ends of the environment are distant factors change drastically. First, you don't control the remote environment. You are completely at the mercy of what the user is willing to execute and they may modify your application in ways you do not anticipate. Secondly, there is a delay between distant ends. Regardless of the application or language in question the environmental and security considerations at hand will continue to impose a separated JavaScript-like web application.

austincheney 9y ago

> If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one? That is not necessarily a language oriented concept. JavaScript can run on the front-end and back-end having an MVC architecture at both points. A better question is why a developer should wish to impose MVC at all at either point? These concepts become easier to reason about when the software runs at a single location using an HTTP service (on localhost) to talk amongst its clusters. It is just a multiprocess application with the bits running asynchronously from each other. When one (or more) ends of the environment are distant factors change drastically. First, you don't control the remote environment. You are completely at the mercy of what the user is willing to execute and they may modify your application in ways you do not anticipate. Secondly, there is a delay between distant ends. Regardless of the application or language in question the environmental and security considerations at hand will continue to impose a separated JavaScript-like web application.