6 ms·

We are approaching the glorious day when we'll be able to write web frontends for web-based apps in real programming languages. Not there yet though. What I re

by api 7y ago

We are approaching the glorious day when we'll be able to write web frontends for web-based apps in real programming languages. Not there yet though. What I really want is something like an "old school" UI library and the ability to style it via well-documented straightforward CSS. For web apps I don't necessarily want to code my UI in HTML. I want to develop an app in a more Qt-like way but with a more modern API. The older versions of GWT actually kind of did this but it's Java and newer versions have decided to try to cater to people who want to do web sites rather than business apps with it.

pjmlp 7y ago
You can already do that today in C, C++, D, Rust, Java and .NET. I just wait for someone bored enough to bring Flash back.
- api 7y ago
  With what? I look periodically and I never find anything.
  - pjmlp 7y ago
    Qt has an experimental WebAssembly backend, already discussed at least twice on Qt's developer blog. Microsoft is busy pushing Blazor for .NET, and Unity is working on a 2D WebAssembly game engine already demoed multiple conferences. C and C++ can make use of Emscripten and even use SDL, POSIX subset and OpenGL mapped into browser APIs. D's LLVM based compiler, ldc, can target WebAssembly. Thus you can also write the logic in D, and do some mapping into browser APIs like canvas and WebGL. Unreal can also target WebAssembly. There is TeaVM for Java. Go compiler supports cross compiling for WebAssembly now. So plenty of information around.
    - api 7y ago
      Do any of those generate web apps that are accessible and browser-friendly? I am quite aware of the fact that you can run desktop apps in a web window. Will have to investigate Blazer and Qt.
      - maemilius 7y ago
        Could you elaborate on what you mean by "browser-friendly"? I would assume you actually meant "accessible and mobile-friendly", in which case the answer to that is generally "nothing does that". You need frameworks or libraries (not languages or compilers) if you want something that just does it for you.
      - m_fayer 7y ago
        Investigating Blazor now. It's very rough around the edges but is no less accessible and browser-friendly than React and friends.
      - Crinus 7y ago
        Well, the original comment was about bringing Flash back and Flash isn't exactly mobile friendly.
        pjmlp 7y ago
        Actually what many are unaware of is that for a couple of years Adobe still had Flash for mobile devices via an AOT compiler to native code, as means to address iOS as target.
      - haolez 7y ago
        Qt works really well with WebAssembly. However, you lose accessibility features and the browser's native text search won't work (as expected).
- fit2rule 7y ago
  MOAI had the ability to target WebAssembly, and that was about as Flash in the 21st Century as you could want ..
- Townley 7y ago
  Is this right? (Disclaimer: I'm about halfway through the Rust book, so I'm just a bit above useless when it comes to Rust) but my understanding was that since WASM can't do DOM manipulation, you still need JS and something like Emscripten to call WASM code. The data and business logic of your code can be written in a WASM-targeting language, but I don't think you could make a React/Vue/Angular-esque UI library (or even a jQuery clone) purely in Rust.
  - steveklabnik 7y ago
    While this is technically true, we have libraries (js-sys and web-sys) as well as tools (wasm-pack and wasm-bindgen) that handle creating that JS for you; you don't have to write any of it yourself. Additionally, they're implemented as polyfills for the eventual way to do this kind of thing without the JS, so once that lands in wasm proper, your code won't need to change, and things will just get faster.
  - pjmlp 7y ago
    On current WebAssembly version you still need to expose canvas or WebGL entry points to Rust code. However WebAssembly is not stuck in MVP v1.0, there is ongoing work to expose more of the underlying features to WebAssembly, like the DOM references proposal.
- pier25 7y ago
  Check Haxe and OpenFL. It can compile to JS/HTML5.
fastball 7y ago
You don't think TypeScript qualifies as a real programming language? I personally am very happy with the progress that has been made over the past 10 years with JS and associated technologies. Still excited about WebAssembly et al., but not nearly as excited as I would've been 10 years ago.
- pjmlp 7y ago
  TypeScript is already similar to WebIDL, what we are missing is having it as part of the browser engines, with more optimizations based on type information, instead of being yet another language with a JavaScript backend.
- superpermutat0r 7y ago
  Of course it is. So is JavaScript. I've done stuff in C, C++, Haskell, python and am now writing primarily in js. Nothing weird there. I fight more with libraries than with the language.
  - weberc2 7y ago
    The bit I fight with the most is how to package it all up for distribution. I'm not a frontend dev, and I vaguely understand that the answer is "webpack" but it's not clear to me what the happy path is for configuring this for distribution. It's also not clear to me whether these $LANG->WASM toolkits will solve this problem or whether they'll also need something like webpack.
    - marcus_holmes 7y ago
      Webpack gives me the screaming heeby-jeebies. Last time I looked, there were minimisation plugins for Gulp/Grunt, etc that would package JS up.
      - maemilius 7y ago
        Why? Webpack has gotten significantly easier to get up and running with since Webpack 4 (iirc). Sure, it starts getting complicated if you want to add language features that haven't made it into browsers yet (i.e. Babel) or use something that transpiles to JavaScript (e.g. TypeScript), but the really popular ones have plenty of good documentation on how to set them up and what each piece is doing. I've only had to set up Webpack a couple times and I've already internalized most of the important stuff. Source Maps are still black magic to me though...
deleted 7y ago
[deleted]
marcus_holmes 7y ago
It's the web. It runs HTML, CSS and JS. Wanting to code your web app in anything else is... I don't know... petulant? And wanting to lose HTML but keep CSS seems a little perverse ;) Every language has flaws (yes, even LISP). Every language has a different purpose. Javascript has done an amazing job so far, and there are millions of people writing some great things in it. Yes, there are also millions of people writing some terrible things in it, but that's on the people not the language. I think having a way of running Go as my front end is going to be great, and I look forward to testing it out. I will heave a huge sigh of relief if I can just code in one language for the whole stack. But that does come with complications. There are currently exactly zero Front End Developers who write usable web front ends in Go. Given the complexity of writing web front ends (and that's not going to be any easier in compiled Go or Rust than it is in interpreted JS), and the paucity of experience in writing them, I'm not sure moving to a Go front end is wise for another few years. Even then, I'd be surprised if Go won that particular competition, and I wouldn't be surprised to find that we have to run Python in Web Assembly because that's what all the Front End devs use. I like Python, don't get me wrong, but I don't see Python in WA as a huge step up from native JS...
- stcredzero 7y ago
  It's the web. It runs HTML, CSS and JS. Why? Is there some first-principles thing here? What if Flash was open sourced, massively cleaned up, changed to be search friendly, and ended up with well curated app marketplaces and code signing? The language Flash used had a shared heritage with JS, and actually did a better job of providing "just works" write once, run everywhere. Many Smalltalk variants had a practically bulletproof write once, run everywhere record of performance. What if properly code signed and sandboxed Smalltalk plugins had won? That could well have resulted in a more open web than what we ended up with. Wanting to code your web app in anything else is... I don't know... petulant? Why? There are currently exactly zero Front End Developers who write usable web front ends in Go. If the developer experience becomes a lot more like developing against a desktop UI framework, there are a ton of experienced older developers who could quickly jump in. It's not rocket science. Actually, in many ways, desktop development is easier than the web front end. For that matter, why not build something which is 1-to-1 isomorphic with React? (EDIT: I see now, that's already sort of the direction they're going for!) I'm not sure moving to a Go front end is wise for another few years. Which I would interpret as a sign that it's the right time to jump in to be a pioneer!
pier25 7y ago
So the idea is basically to avoid markup and use a better language than JS?
marmada 7y ago
Why is modern JS (TS especially) not a "real programming language". I have never once been bitten by == vs === or the crazy automatic type conversions people use to demonstrate that JS is not a "real" programming language. I especially don't understand why people would want to write a front-end in Go. React already provides a great front-end experience. If you're doing something that requires high-performance, then use c++ compiled to wasm or something similar. But why Go? It's not as performant as C++ and I don't think it provides a UI development experience as good as React.
- deleted 7y ago
  [deleted]
- empath75 7y ago
  There’s nothing wrong with js, but imagine if all server software had to be written in Perl.
iamgopal 7y ago
Try svelte

by api 7y ago

pjmlp 7y ago

You can already do that today in C, C++, D, Rust, Java and .NET. I just wait for someone bored enough to bring Flash back.

api 7y ago
With what? I look periodically and I never find anything.
- pjmlp 7y ago
  Qt has an experimental WebAssembly backend, already discussed at least twice on Qt's developer blog. Microsoft is busy pushing Blazor for .NET, and Unity is working on a 2D WebAssembly game engine already demoed multiple conferences. C and C++ can make use of Emscripten and even use SDL, POSIX subset and OpenGL mapped into browser APIs. D's LLVM based compiler, ldc, can target WebAssembly. Thus you can also write the logic in D, and do some mapping into browser APIs like canvas and WebGL. Unreal can also target WebAssembly. There is TeaVM for Java. Go compiler supports cross compiling for WebAssembly now. So plenty of information around.
  - api 7y ago
    Do any of those generate web apps that are accessible and browser-friendly? I am quite aware of the fact that you can run desktop apps in a web window. Will have to investigate Blazer and Qt.
    - maemilius 7y ago
      Could you elaborate on what you mean by "browser-friendly"? I would assume you actually meant "accessible and mobile-friendly", in which case the answer to that is generally "nothing does that". You need frameworks or libraries (not languages or compilers) if you want something that just does it for you.
    - m_fayer 7y ago
      Investigating Blazor now. It's very rough around the edges but is no less accessible and browser-friendly than React and friends.
    - Crinus 7y ago
      Well, the original comment was about bringing Flash back and Flash isn't exactly mobile friendly.
      - pjmlp 7y ago
        Actually what many are unaware of is that for a couple of years Adobe still had Flash for mobile devices via an AOT compiler to native code, as means to address iOS as target.
    - haolez 7y ago
      Qt works really well with WebAssembly. However, you lose accessibility features and the browser's native text search won't work (as expected).
fit2rule 7y ago
MOAI had the ability to target WebAssembly, and that was about as Flash in the 21st Century as you could want ..
Townley 7y ago
Is this right? (Disclaimer: I'm about halfway through the Rust book, so I'm just a bit above useless when it comes to Rust) but my understanding was that since WASM can't do DOM manipulation, you still need JS and something like Emscripten to call WASM code. The data and business logic of your code can be written in a WASM-targeting language, but I don't think you could make a React/Vue/Angular-esque UI library (or even a jQuery clone) purely in Rust.
- steveklabnik 7y ago
  While this is technically true, we have libraries (js-sys and web-sys) as well as tools (wasm-pack and wasm-bindgen) that handle creating that JS for you; you don't have to write any of it yourself. Additionally, they're implemented as polyfills for the eventual way to do this kind of thing without the JS, so once that lands in wasm proper, your code won't need to change, and things will just get faster.
- pjmlp 7y ago
  On current WebAssembly version you still need to expose canvas or WebGL entry points to Rust code. However WebAssembly is not stuck in MVP v1.0, there is ongoing work to expose more of the underlying features to WebAssembly, like the DOM references proposal.
pier25 7y ago
Check Haxe and OpenFL. It can compile to JS/HTML5.

fastball 7y ago

You don't think TypeScript qualifies as a real programming language? I personally am very happy with the progress that has been made over the past 10 years with JS and associated technologies. Still excited about WebAssembly et al., but not nearly as excited as I would've been 10 years ago.

pjmlp 7y ago
TypeScript is already similar to WebIDL, what we are missing is having it as part of the browser engines, with more optimizations based on type information, instead of being yet another language with a JavaScript backend.
superpermutat0r 7y ago
Of course it is. So is JavaScript. I've done stuff in C, C++, Haskell, python and am now writing primarily in js. Nothing weird there. I fight more with libraries than with the language.
- weberc2 7y ago
  The bit I fight with the most is how to package it all up for distribution. I'm not a frontend dev, and I vaguely understand that the answer is "webpack" but it's not clear to me what the happy path is for configuring this for distribution. It's also not clear to me whether these $LANG->WASM toolkits will solve this problem or whether they'll also need something like webpack.
  - marcus_holmes 7y ago
    Webpack gives me the screaming heeby-jeebies. Last time I looked, there were minimisation plugins for Gulp/Grunt, etc that would package JS up.
    - maemilius 7y ago
      Why? Webpack has gotten significantly easier to get up and running with since Webpack 4 (iirc). Sure, it starts getting complicated if you want to add language features that haven't made it into browsers yet (i.e. Babel) or use something that transpiles to JavaScript (e.g. TypeScript), but the really popular ones have plenty of good documentation on how to set them up and what each piece is doing. I've only had to set up Webpack a couple times and I've already internalized most of the important stuff. Source Maps are still black magic to me though...

deleted 7y ago

[deleted]

marcus_holmes 7y ago

It's the web. It runs HTML, CSS and JS. Wanting to code your web app in anything else is... I don't know... petulant? And wanting to lose HTML but keep CSS seems a little perverse ;) Every language has flaws (yes, even LISP). Every language has a different purpose. Javascript has done an amazing job so far, and there are millions of people writing some great things in it. Yes, there are also millions of people writing some terrible things in it, but that's on the people not the language. I think having a way of running Go as my front end is going to be great, and I look forward to testing it out. I will heave a huge sigh of relief if I can just code in one language for the whole stack. But that does come with complications. There are currently exactly zero Front End Developers who write usable web front ends in Go. Given the complexity of writing web front ends (and that's not going to be any easier in compiled Go or Rust than it is in interpreted JS), and the paucity of experience in writing them, I'm not sure moving to a Go front end is wise for another few years. Even then, I'd be surprised if Go won that particular competition, and I wouldn't be surprised to find that we have to run Python in Web Assembly because that's what all the Front End devs use. I like Python, don't get me wrong, but I don't see Python in WA as a huge step up from native JS...

stcredzero 7y ago
It's the web. It runs HTML, CSS and JS. Why? Is there some first-principles thing here? What if Flash was open sourced, massively cleaned up, changed to be search friendly, and ended up with well curated app marketplaces and code signing? The language Flash used had a shared heritage with JS, and actually did a better job of providing "just works" write once, run everywhere. Many Smalltalk variants had a practically bulletproof write once, run everywhere record of performance. What if properly code signed and sandboxed Smalltalk plugins had won? That could well have resulted in a more open web than what we ended up with. Wanting to code your web app in anything else is... I don't know... petulant? Why? There are currently exactly zero Front End Developers who write usable web front ends in Go. If the developer experience becomes a lot more like developing against a desktop UI framework, there are a ton of experienced older developers who could quickly jump in. It's not rocket science. Actually, in many ways, desktop development is easier than the web front end. For that matter, why not build something which is 1-to-1 isomorphic with React? (EDIT: I see now, that's already sort of the direction they're going for!) I'm not sure moving to a Go front end is wise for another few years. Which I would interpret as a sign that it's the right time to jump in to be a pioneer!

pier25 7y ago

So the idea is basically to avoid markup and use a better language than JS?

marmada 7y ago

Why is modern JS (TS especially) not a "real programming language". I have never once been bitten by == vs === or the crazy automatic type conversions people use to demonstrate that JS is not a "real" programming language. I especially don't understand why people would want to write a front-end in Go. React already provides a great front-end experience. If you're doing something that requires high-performance, then use c++ compiled to wasm or something similar. But why Go? It's not as performant as C++ and I don't think it provides a UI development experience as good as React.

deleted 7y ago
[deleted]
empath75 7y ago
There’s nothing wrong with js, but imagine if all server software had to be written in Perl.

iamgopal 7y ago

Try svelte