Hacker News Reader

Comment by api | Hacker News Reader

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.

View on HN

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...

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!

> actually did a better job of providing "just works" write once, run everywhere.

It did, for its time. But there's a tremendous amount of work done in scaling UIs between mobile and desktop viewports on the web that Flash could never easily achieve, and most native frameworks are still struggling with today.

> If the developer experience becomes a lot more like developing against a desktop UI framework

... then the mobile experience is crap, yeah.

But there's a tremendous amount of work done in scaling UIs between mobile and desktop viewports on the web that Flash could never easily achieve, and most native frameworks are still struggling with today.

Keep in mind that Flash was effectively abandoned/deprecated. Again, there's nothing first principles here. The greater effectiveness of MacOS in dealing with scaling UIs is a demonstration of this.

> If the developer experience becomes a lot more like developing against a desktop UI framework

... then the mobile experience is crap, yeah.

Credit where credit is due. Look at what Apple has achieved in terms of this. In a way, the argument tactic is straw-manning here. Instead of picking a few glaring errors from past frameworks, shouldn't we be looking at the best of what existing frameworks can do, and try to build that?

Flash lives on as Animate CC

https://www.adobe.com/products/animate.html

petulant (and I'm still not sure that's the right word for it) because instead of learning the technology that everyone else (i.e. the standards bodies that decide these things) decides is what we're doing now, you gotta do something different. Not better, but different.

Flash was proprietary tech. Eventually Adobe would have worked this out and owned the internet. You can't have proprietary tech underpinning everything. The story of video codecs bears this out.

I developed a ton of desktop UI in Visual Basic. It was easy. But I didn't have to allow for random screen sizes, random browsers, random OS's, random accessibility problems, rarely had to allow for random languages (and that was difficult), and I had a synchronous back end that I could wait for between clicks. Sorry, but the difference between desktop and web UI is huge, and underestimating that gap is a major cause of bad web UI.

Pretty easy with VB.NET and WPF/UWP.

The desktop world has long moved from fixed layouts from VB 6 and lower.

Since 2001 actually, given that even Forms has a layout manager.

You don't get better, if you don't try different. In terms of clarity and expressive power, I would say that Smalltalk is a step above Javascript.

Meh. Wanting to replace javascript for frontend webdev is no different than wanting to run javascript on the server. It's not perverse or petulant. Everyone has opinions...

I've written a lot of python, javascript, C and go in my career, and my opinion is that javascript has done a barely adequate job despite being the only game in town.

I feel the same about C for systems coding. You're not wrong.

I'm actually with you on C. C has the excuse of being portable assembly and from the dawn of time. Javascript is just the result of shoehorning something into the browser quickly.

C is 10 years younger than the dawn of systems programming languages and it is only portable Assembly if the CPUs are still PDP-11 look alike.

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?

Thank god for the petulant, else we would still be foraging for berries.

Every language has a different purpose.

What is the purpose of C#1, when one could use C#3.5?

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.

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.

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.

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.

Webpack gives me the screaming heeby-jeebies.

Last time I looked, there were minimisation plugins for Gulp/Grunt, etc that would package JS up.

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...

Our webpack builds are really slow and we can’t seem to figure out how to profile it.

It's taken me 8 days to answer, because I've rewritten this a few times. I may write this up as a blog post.

OK, so...

    1. It doesn't do one job and do it well. It tries to do it all.
    2. It has magic. Why does this setting do this? Don't know, just do it.
    3. It's vastly overcomplicated (related to 1, and produces 2)
    4. It's a black box. It's not at all transparent about how it does what it does, and the output it produces seems to be arbitrary. I mean, you could probably work back from the minimised mess that you get to relate it to the source, probably. But it's not at all clear why tweaking this declaration makes that function move to that module.
    5. It's not instrumented, or predictable. Changing a declaration can make it double its processing time, and there's no way of knowing which of the 5 changes you just made caused that.

And finally... It's a solution to a problem that only exists because of the dependency culture in the JS community. Because each dependency contains a lot more code than is needed to solve the one problem it was imported to solve, web apps tend to bloat. So we need to break them into modules and only import the modules we need. So we need a tool to do that and package the modules up. So we get Webpack. Instead, why don't we just import less code in the first place? We really (and I mean really) don't need 500Kb of javascript to create a basic web app. If we could cut that down to 100Kb then we could just minimise it and we wouldn't need webpack at all (maybe Gulp to run Babel for those oh-so-necessary new cool JS features).

I switched from Webpack to Parcel (https://parceljs.org/), it requires far less configuration (only command line parameters for me) and runs faster. It's "batteries included", and I find it's enough for most of my applications.

I’m a somewhat (?) unusual situation where we are a Java shop in which I persuaded the group a few years ago to move to an SPA on top of web services (REST, JSON) architecture...

That said, I’m using the Maven plugin which runs the Google Closure compiler to bundle my js files (and strip white space, but not name-mangling). Seems to get the job done.

Note: most of the files are just a few large “IIFE”s to be concatenated together, rather than “modules” or such, as we had a requirement to support IE11, and were initially sticking with ES5 style.

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

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.

With what? I look periodically and I never find anything.

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.

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.

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.

Investigating Blazor now. It's very rough around the edges but is no less accessible and browser-friendly than React and friends.

Well, the original comment was about bringing Flash back and Flash isn't exactly mobile friendly.

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.

Qt works really well with WebAssembly. However, you lose accessibility features and the browser's native text search won't work (as expected).

MOAI had the ability to target WebAssembly, and that was about as Flash in the 21st Century as you could want ..

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.

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.

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.

Check Haxe and OpenFL. It can compile to JS/HTML5.

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.

There’s nothing wrong with js, but imagine if all server software had to be written in Perl.

Try svelte

Reply on news.ycombinator.com