Hacker News Reader

Comment by royjacobs | Hacker News Reader

Congratulations on the release! For all the talk of React and Vue I still like the 'batteries-included' approach of Angular.

I mostly do Kotlin in my day job so Angular aligns fairly nicely with the way applications are structured. I don't get the militant need for terseness that's seen in approaches like React Hooks. I also don't need the choice between multiple backwards-incompatible (or competing) routers, nor do I have a need for functionally pure reducers.

So, it may not be sexy, but It Works and that's good enough for me :)

View on HN

I've been burnt by the non-Euclidian enormity of ExtJS, so I understand the desire for something simpler. On the other hand, when you leave the world of progressive enhancement and widgets (ie. jQuery), you find yourself needing a lot of common infrastructure and picking and matching that can be quite tedious (never mind dependency hell), which is something that react always had issues with -- and that seems to extend fractally, where it's not just MobX vs. React but then what framework/project setup you have on top of each of these choices. And now hooks.

Still, angular always struck me as going slightly too far into Java-land -- my Struts/J2EE/DI battle scars are larger than even my ExtJS mutilations.

And in between you've got VueJS/Vuex, which seems to move a bit too close to react at times, and EmberJs, which seems to move too slowly and/or without many people watching it.

I really want to go back to late-90s desktop UI development sometimes…

WebAssembly is still a couple of years away, sadly.

Yes, then we'll get native J2EE in the browser instead of JS copies…

The whole interaction model is just a lot more tedious than desktop UI development. One of the few approaches that I actually liked (not just tolerated) was Seaside, but that went away when the blood-dimmed tide of JS was let loose.

>then we'll get native J2EE in the browser instead of JS copies…

Can’t wait. Imagining all the possibilities...

DI in Angular 8 is much less aggressive than in AngularJS/Angular 2. At least it feels this way :)

I miss Delphi.

I don't. Not even a little.

> I really want to go back to late-90s desktop UI development sometimes…

While it's not a JS framework, can I interest you in an explicitly VB/Delphi-inspired app development tool for the web?

It's got drag'n'drop design, you code entirely in Python (including the front end - it transpiles to JS), and it even has a built-in database: https://anvil.works/

But Vue got the batteries included? You have a router included and you can just keep your store as an object or use Vuex for larger applications (if you feel the need for even more structure). All this is according to the official docs, thus included and best practice?

> Congratulations on the release! For all the talk of React and Vue I still like the 'batteries-included' approach of Angular.

It's a different story when your application is huge and mostly made of batteries. ;- )

When a typical application spends multiple megabytes just for the webfonts and logo JPGs on the front page, I don't really care whether my application bundle is 200k or 500k, though. I care more about productivity.

Now, this clearly needs SOME boundaries, but let's not start a whole "Electron" thread again :)

The bundle size is now much better, and will only get better with Ivy. Also, I don't think it makes the most important comparison point although it certainly is one to consider.

Most websites on the internet load several megabytes of Javascript.

For a full-size SPA, I think Angular is a great choice, but for incremental use cases like adding some interactivity to a mostly static page, it's still not the main use case, although that will change with Angular Elements.

Yes, that is absolutely fair. I was indeed talking about Angular in the context of a full SPA, not a tiny component in a banner.

For your second use-case (adding some interactivity to a mostly static page), Vue works really well.

For a full on SPA, Angular is lovely to work with.

I think it's still worth paying attention to size of the JS download. If you download 500k of JS, it means that after ungzipping it, it will be 2mb or more. Your browser needs to parse and execute that code, which also takes time, and it impacts the user experience.

Also it's easier (at least from developer's perspective) to deal with a big image than to deal with big JS codebase. You can't just replace it with something smaller, you often need to spend a significant amount to shrink it.

Definitely, this is also why it's important that Angular is making strides towards reducing the total download size. This is, in fact, exactly what is happening with this release (and it will only improve when Ivy is released).

This does not mean the frontend community should continually be bending over backwards reinventing wheels just so the claim can be made that a certain package is now "only 1.6k GZipped!", imho.

Is there anybody who assumes networks are fast enough and immutable caches are a thing but parser is the bottleneck? They would bundle everything into a single js but minimise parsing costs.

``` polyfill1 = "function(...)" polyfill2 = "function(...)" vendor1 = "function(...)" vendor2 = "function(...)" route1 = "function(...)"

if(firefox) eval(polyfill1) if(route === '/locations') { eval(vendor1) eval(vendor2) eval(route1) } ```

Since when are developers supposed to develop with developer first mind? Those products usually look dull and tedious to use.

What batteries does Angular include that Vue doesn't?

I think instead of meaning specific components (http and routing come to mind) that more often people mean by "batteries included" that Angular has an opinionated way to do most everything, and their docs/guides include examples. In my experience, Vue and React allow a higher degree of freedom in choosing how you would like to approach various things, and there are more choices for some core behaviors for them as well

Freedom isn't bad but in larger environments that freedom can lead to multiple ways of doing the same thing and in turn it becomes harder for new people to jump into current projects, they have to first figure out what the initial thought behind a design was. The way Angular is opinionated benefits this setup and unknown projects look more familiar when you first dive in. Also, searching for solutions online almost always fit your needs.

Funny thing is, if you look at projects like AngularMaterial, they don't follow to the Angular styleguide by a country mile.

The nice thing is that the automation tools are being made progressively easier to customize. That means that it is easier to define your own standard and support it with standard tooling.

Ah...Kotlin on the backend? Can you share more details about your stack/experience? I've been keeping an eye out for it to crop up in production backend stacks, so I'm very interested in learning how well it works for you...

I dunno about original poster but in Kotlin I use Javalin.io for HTTP web services and JDBI for SQL. Jedis for Redis access.

These are pretty typical Java libraries, but lightweight. Nothing particularly Kotlin about them but that's why I like Kotlin because you can leverage the entire Java ecosystem easily.

I find Kotlin on the backend to be a pleasure.

Reply on news.ycombinator.com