Live data from Hacker News

Angular v8.0

github.com

81–90 of 210 posts

Re: Angular v8.0

#81
post #69

While the effort by the Angular team deserves praise, I think for the vast majority of use cases it is a mistake to do it all client side. With some exceptions, there is really no benefit in making a SPA but there are many drawbacks. I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.

It's all about the use case. If you're on an ecommerce website and click between category and PDP pages 5-10 times browsing, a SPA is going to make that transaction an order of magnitude faster. Since you're only loading the smallest possible payload (JSON) that contains only the things that have changed, it is optimized in a way that is never going to be achievable with server-side rendering.

At least that's why I opted to push for a SPA.

Re: Angular v8.0

#82
In my opinion Angular's story is a story of how people invent problems and then valiantly tackle them.

- We want to re-write the whole thing from scratch. In TypeScript.

- And let's use Google's Closure Compiler for JavaScript. Even though it doesn't support TypeScript, modules, or anything, really from non-Google Javascript world (at the time)

- Oh. Then... Let's create a TypeScript to Closure Translator even though TypeScript doesn't let you extend the compiler and TypeScript and Closure are in general not entirely compatible

- Oh, and we use a weird combination of annotations and templates to work, so... we need to compile our templates into TypeScript (which we need to translate to Closure-compatible JavaScript which will then be compiled further down)

- Only the whole process is abysmally slow. Let's implement incremental compilation.

- It's probably still slow, complicated, and error-prone. We know! Let's use Google's Bazel! You know, the tool to build huge codebases in parallel on clusters. Yeah, why not use that to build JS code?

- Only bazel has no support for either Closure, or Javascript, or TypeScript, so we have to build tools and integrations to work with bazel!

And the quests just keep popping up.

Re: Angular v8.0

#83

Earlier quoted context omitted.

> 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 :)

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

Re: Angular v8.0

#84

I was recently at a Microsoft heavy tech conference and spoke to at least 50 .Net developers. Anyone who also did front end did so in Angular. I was surprised at how popular it is!

Well according to non-anecdotal measures, you're correct, it appears to be neck-n-neck with React:

https://insights.stackoverflow.com/survey/2019#technology

Re: Angular v8.0

#85
post #19

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'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 exten…

I miss Delphi.

Re: Angular v8.0

#86
Literally just finished a huge re-write of an angular 4 app to latest Angualr 7 today, to revise the UI and improve everything. As I was about to merge it in I see this... time to upgrade!

Re: Angular v8.0

#87
post #64

I was recently at a Microsoft heavy tech conference and spoke to at least 50 .Net developers. Anyone who also did front end did so in Angular. I was surprised at how popular it is!

I work in the Danish public sector and we currently have 300 systems from various contractors. Almost all of them are moving toward a C#/JAVA api based backend and an Angular front. Only one of those systems uses Vue. None of them use React. Outside the public sector React is a bit more popular, but it’s still mainly used outside of enterprise and Vue rarely sees any use. The job-market doesn’t seem to follow the tec…

Maybe just afraid to use tools developed by someone you don't know?

Re: Angular v8.0

#88
post #69

While the effort by the Angular team deserves praise, I think for the vast majority of use cases it is a mistake to do it all client side. With some exceptions, there is really no benefit in making a SPA but there are many drawbacks. I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.

Small, internal business apps have been a good use case for me. I'm working with few dev resources (me, myself & I), so the "batteries included" approach of Angular is nice, and knowing it's always served over a fast corporate network alleviates the filesize concerns somewhat. Plus, we're in a situation right now where some of our clients are being sort of amorphous on what server platform they'd like to migrate to and when, so the browser is a more stable target (ironically).

It's an unusual situation perhaps, but having done similar apps with other frameworks and paradigms over the past ~10 years, Angular 2+ just feels like a good tool for the job.

Re: Angular v8.0

#89
post #65
post #57

Earlier quoted context omitted.

https://reactjs.org/docs/hooks-intro.html edit: Lol apparently two React devs ears were burning at the same time.

well 16.8 (which basically was the latest version) also btw: https://reactjs.org/docs/hooks-faq.html#do-i-need-to-rewrite... and I still have no idea how I only do stuff on the client in a SSR environment (stuff that i did in componentDidMount)

> and I still have no idea how I only do stuff on the client in a SSR environment (stuff that i did in componentDidMount)

The 'useEffect' hook - it won't be executed if you use e.g. ReactDOMServer.renderToString() for SSR

    useEffect(() => {
      console.log('Client side only');
    }, []);
Codesandbox: https://codesandbox.io/s/peaceful-dew-nvw83

Re: Angular v8.0

#90

Earlier quoted context omitted.

Apart from being verbose, why is that a bad thing? Spring is used to successfully build massive applications. You can meme about Spring's AbstractFactoryBeans all day, but in the end it does what it's supposed to do.

I maintain a class library that is highly depended upon in the rest of our company. I don't like to introduce dependencies at my later because of that. So things like DI are all factory patterns / builder patterns. It's explicit and has kept my object lifecycle super manageable. It feels like the people who meme about EnterpriseFactoryFactory at times just haven't hit the right use case for it.

I'd like to understand this more, as being on the fringe of popular open source projects I think I experience this. Can you expand any further with pseudocode?
Post reply on HN