Hacker News Reader

In my experience, this is a much bigger problem in web programming than elsewhere. Take the JVM, for example, since it's the subject of the article- it's been around for decades and while things have changed, you can still pretty just just keep using whatever you're using without fear of the developers jumping ship for something shiny.

Indeed. Also, in more sane / stable areas of the industry, the code doesn't rot so fast. Java is relatively backwards compatible down to version 1.5 or so. In Common Lisp world, the code written more than years ago works perfectly fine without need for any change.

Man I smelled that "horrendous complexity" odor on Angular a mile away. Made me glad I can do mostly backend work.

You're not wrong. I am an Angular 1 dev who's in the process of moving to Angular 2 and even that is an up-hill battle. However, I think it's about picking the right tool for the job in that the batteries-included / opinionated nature of Angular is great for once you start scaling a team AND/OR you have a product that you need to keep shippable at all times.

You're forgetting that this is every web developer's dream. To always keep learning new frameworks (to do the same fucking thing) over and over.

I get that this is the easy way to see it from the outside, but:

- You don't have to learn every new framework. Google has 10k+ Angular 1 projects, this stuff doesn't go away after hitting critical mass.

- This constant iteration has lead to multiple production-ready UI paradigms that were just relegated to FP research. Try using Angular 1 or vanilla React, and then do something with vanilla Android. Or GTK+. Do we want GTK to be our baseline for UI work? Qt is nicer, but it's definitely playing catch-up.

You can poke fun, but there's a reason everyone opts for things like Electron. It's the most satisfying way to build frontends for a lot of people.

> Everyone opts for electron

And I’m just sitting here, using https://github.com/ReactiveX/RxJavaFX

Is JavaFX okay? Or maybe even good? What's wrong with it? (Not polished enough, not maintained enough? Not updated fast enough?) RxJava seems pretty okay.

Seems perfectly fine for building desktop applications in Java (which is what I've been doing for the last 1.5 year at my $dayjob).

Java has problems on OS X and Linux. It is not truly cross-platform like Electron is.

Don't know about the OS X problems much, but on Linux it's workable with FX (our product is actually used on both Windows and Linux). OTOH, Electron achieves its portability by shipping the whole Chromium browser with your application...

There is actually one issue JavaFX has on Linux: It uses Gtk to determine renderscale, so it can’t handle HiDPI at all (Gtk only scales in integer amounts, so everything is either 96dpi or 192dpi)

Could you talk a little bit about these problems? I was not aware of any serious issues on non-Windows platform, and would like to hear about them. As Java/Kotlin is generally my go-to language for making things in my off time, that would be helpful to know about.

Off the top of my head: misses some UI elements / widget types (spinner / numeric entry). UI bindings require a lot of manual converters instead of doing conversions that p.e. WPF does out-of-the-box (like double to string when using a text box; principle of least surprise).

And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).

> misses spinner

https://docs.oracle.com/javase/8/javafx/api/javafx/scene/con...

> UI bindings require a lot of manual converters instead of doing conversions that p.e. WPF does out-of-the-box (like double to string when using a text box; principle of least surprise).

You can use String.valueOf, but usually don’t want to do that. And how do you want to represent the float? With Scientific notation, Engineering notation, or purely decimal? This is not simple.

> And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).

Or you use the FXML bindings for creating them from XML?

The constant iteration has definitely led to more production ready UI platforms. But once they are in production they are largely abandoned in favour of "shiny new thing 2.0". The rate of change on the web development side is simply too fast to keep up with especially with regards to tooling.

> You can poke fun, but there's a reason everyone opts for things like Electron. It's the most satisfying way to build frontends for a lot of people.

I'm not convinced it's particularly good reasons. I think ignorance of native GUI coding and the old, "When all you have is a hammer, every problem looks like a nail" mentality has a whole lot to do with it.

Wouldn't really say that I am seeing it from the outside. Have done some web frontend projects last couple of years and also used Electron for a project. Starting an Angular 1 project now is comparable to doing Windows desktop applications in MFC, and Angular 1 is what, 6 years old?

And the only satisfying thing about Electron, is hitting package and getting three platform-specific binaries. Otherwise, it is still web frontend development. In contrast, I have had the pleasure of doing desktop development in Qt and WPF, which was quite enjoyable (and the ecosystem has not changed a lot since I left it years ago).

Also, MVC and MVVM were UI paradigms before web frontend development. And I am quite sure I heard about ReactiveExtensions before Facebook React.

Yes, vanilla Android is terrible.

The primary reason to learn new web framework all the time is that current are still not quite there yet. It needs more maturation till it can stabilize into something good enough.

"Why would you want a 2017 car? I have a Model T here that does the exact same thing"

I've done a few projects with Angular Material, and I actually ran into that exact same issue of trying to re-create the documentation's sidebar, only to realize the components weren't in the framework.

> Guess what? Angular Material is dead. All the developers decided to start over with Angular Material 2 because there's a new screwdriver brand in town: Angular 2.

I think an important lesson from this is to be careful about the tools you use. If a particular company puts out great tools but changes them in incompatible ways, you might end up having to go back and rehang a lot of doors.

I think I'm in love.

It's a free and open source project and you're still complaining. And browsers and the web, JS and a lot of things changed between Angular 1 and Angular 2.

Yes, Google could have handled those projects better, they could have put up big warning signs that they are "deprecated".

I think it was a good move to recognize how unmaintainable things (can quickly and usually) become with angular1 (or with anything that is a mess of a hundred semi-external JS libraries), hence TypeScript.

Maybe marking them deprecated when they're launched?

So we've moved past the 'forever in beta' phase to the 'deprecated at launch' phase?