Angular v8.0(github.com)

274 pointsby tashoecraft7 anni fa201 comments

https://github.com/angular/angular-cli/releases

209 comments

pure7 anni fa

Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too.

Out of the box, you get: routing with lazy loading, full TypeScript support and a TypeScript-first ecosystem, a great CLI that completely abstracts Webpack and the build process, easy and mostly automatic updates with the CLI, reactivity with RxJS baked-in and supported widely in the community, a great forms library, and, of course, a component-based approach to UI development. The uniformity is a big benefit. It's easy to ramp up on a new Angular project, and there are fewer decisions to make when starting a new one. The built-in parts of the framework are all high quality and an easy bet. There's no need to evaluate different routers, form libraries, HTTP clients, get back up to speed on configuring Webpack only to forget how until next time, etc.

It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).

davedx7 anni fa

As a long time React developer, I second this. Especially this part:

> There's no need to evaluate different routers, form libraries

These two things have been the bane of my React development experience ever since the days of "flux". Every new React project I start I end up using a different set of libraries, and it's not just me either -- a very experienced React dev I work with just switched our React e-commerce SPA's form library out.

Coming back to Angular after a long time (I used to work with AngularJS) has been like a breath of fresh air. The project I'm using it on is clean, simple, consistent. The code is readable, every form and component works the same way.

If I was building something with less consistent / regular UX then I would still definitely use React, but Angular has really pleasantly surprised me.

tashoecraft7 anni fa

This has really been the great thing about Angular. Our team has grown from 2 to 10 and our projects have greatly expanded. We have them all in a frontend/node layer monorepo where all our front end projects feel the same. Their organized in very similar ways, the 3rd party libraries are all on the same version and are used across the apps.

I routinely have to hop between all the apps and I don't have to think about which libraries someone has used for each part, if Angular has a version of something we need we just that. One of our bigger apps hasn't made the switch to ngrx, but that's about the only difference between the feel of them all.

codeflo7 anni fa

Everyone's experience is different here, but I've grown to hate these all-encompassing frameworks -- somehow I always run into their limits. As far as I understand, Angular has its own module system, its own dependency injection, its own test framework. If you have any special requirements for any of those, you usually can't rely on the vast JavaScript ecosystem because Angular doesn't play well with many common JavaScript techniques. React also has a precompile step with JSX, but that's simple syntactic sugar, and besides that, React is really just a well-behaved library with a surprisingly small API surface. It doesn't try to do everything and it plays well with non-React libraries, at least in my limited experience. I usually find that in any context, taking such a mix-and-match approach is a lot more flexible in the long run than using a large framework.

jf227 anni fa

Can you describe what limits you run into?

boubiyeah7 anni fa

They work best if your team has low standards and just settle with whatever the framework has choosen for you. I'm not surprised it's fine for many.

nickserv7 anni fa

I'm not sure I would consider uniformity "low" standards.

It's quite useful when there are multiple smallish projects, for example your typical web agency.

Also useful when you have one or two experienced programmers and a few less experienced ones: makes it easier to review the code.

That said for a highly custom application, especially one you're betting the company on, and need full control, a lower level approach can be beneficial.

Not limited to Angular vs Vue.js, the same applies to Django and Flask for example.

rufugee7 anni fa

If you were new to React or Angular, but needing to choose one for a single developer project, which would it be now in 2019?

kls7 anni fa

<li *ngFor="let item of list"> <-- this says it all, flow logic in your template is a debugging nightmare. There is no debugger for conditional statements that are declared in HTML.

TLDR - Choose React.

ben9408302984327 anni fa

Angular is easier to get up and running. Then you also have a very solid foundation that can be picked up easily by new devs starting on the project. Whereas, React seems to work only for more experienced front-end developers since you have to make more choices. If someone is just starting out it can turn into a mess pretty quick.

antonkm7 anni fa

I disagree. If you use create-react-app you get best practices out of the box.

React is also much less abstraction away from vanilla JS. Learning Angular is learning a new language with a whole bunch of restrictions. Learning React is like learning JS++.

(This is my personal experience based on three Angular projects and ten+ React projects.)

marfusios7 anni fa

Yea? What about routing, forms, state, styles encapsulation, code separation to modules, http clients, etc. A lot of choices for new React project, zero choices for Angular === faster startup.

hazza17 anni fa

You don't need to choose the library but there's still the same amount of documentation to wade through, the amount of learning is the same.

although, code separation is native in React now and if you think http clients is still a thing you're too far into the Angular ecosystem to be helped.

antonkm7 anni fa

Forms: use HTML5 and expand on that. State: quick read, I'd say use context, hooks and effects if you're new. Styles: I despise style in JS, so I go with SCSS or CSS. The encapsulation problem is made up in 90% of all apps. Http: just use fetch. If you'd like, you can write a vanilla wrapper around it. Code separation to modules - don't get what you're going at really. Build functional components. Keep shared logic in services, a POJO wrapping functions and exporting it all.

ng127 anni fa

From my experience, learning React and picking an approach for each of the above is faster than learning Angular.

netzone7 anni fa

I mean you get best practices for the small part React is focused on. Angular is a full type of ecosystem, like your Ruby on Railses, Djangoes etc. in which you can install it and then create a full website directly without any dependencies other than what you get.

Rotareti7 anni fa

Comparing Angular to React is comparing apples to oranges. It would make more sense to compare Angular to React based frameworks such as NextJS [0]. Those are "easy to get up and running" and offer "a very solid foundation that can be picked up easily by new devs starting on the project", as well.

[0]: https://github.com/zeit/next.js/

hazza17 anni fa

Only if you know typescript and rxjs already is Angular easier to get up and running, react especially with create-react-app is trivial to get going.

davedx7 anni fa

Angular. Getting up and running is much simpler.

alceta7 anni fa

I cannot upvote this enough. We have long decided what to do with our painful angularjs application with thousands of beginner mistakes due to people learning a framework while using it.

In the end, we were able to partially migrate to angular 4 at the time using ngUpgrade while still using parts of the application in angularjs 1.6. luckily we started looking into typescript beforehand, making it even easier.

It took us 3 months to completely migrate with only a tiny fraction of legacy bundle of code now still running on angularjs until it's being converted

Since then I have done every major upgrade without fears. I wholeheartedly recommend it for medium-large applications (we have around 50k cloc typescript now).

Angular + Typescript keeps us and our frontend saner than before.

One thing I sorely miss is the performance of my manual webpack / angularjs build, with 15seconds initial build and 1-2 seconds incrementals... It's now at least double with the angular cli, but at least fully managed.

y-c-o-m-b7 anni fa

> get back up to speed on configuring Webpack only to forget how until next time

Is this common? Thank goodness i'm not the only one! I keep telling myself next time i'm going to remember to bookmark the billion tabs I open on StackOverflow trying to figure out Webpack configuration, but nope I forget and start from scratch every time.

EDIT: Also I've coded a project in Angular 2 and Angular 4 respectively; I have nothing bad to say about Angular but I still prefer Vue for it's ease of use and friendlier syntax.

_eric7 anni fa

I'm pretty sure it's more common than it should be, really. Everytime I had to create a new project I'd have to copy/paste the webpack configs left and right. Sometimes I miss the gulp days - it was way more straight forward and not so much magic involved.

> Also I've coded a project in Angular 2 and Angular 4 respectively; I have nothing bad to say about Angular but I still prefer Vue

I have used Angular 1 professionaly for more than 3 years with some big projects and when Angular 2 was released I ditched the idea of using it in a newer project. I was using Angular 2 since the alpha days and saw how some things got over complicated. And then I too chose Vue and fell in love with it.

azangru7 anni fa

> It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).

Huh? Hooks are just a way to use component lifecycle in absence of classes (note how React is pushing towards having components as functions as opposed to Angular's components as classes/objects). The new context api is basically just a replacement/improvement of the old context api, which has been in React for ages (React Router was built upon the old context api from get go), but has always been badly documented and considered a private interface, something you were not supposed to touch. As for embracing Typescript, the React community has extensively used static typing with Flow (since this is something that the React team itself uses) for a couple of years, which is very similar to Typescript.

Having CLI generators (such as create-react-app) is definitely something that React borrowed from other communities, but I am not sure whether Ember or Angular was the main influence.

pure7 anni fa

Definitely correct me if I'm wrong, but I also thought hooks were for factoring out common logic and sharing it among functional components. I see lots of "hooks" libraries floating around.

For Context, like you said, it existed before, but everyone was told not to use it. After the new API came out, people started suggesting ditching Redux for Context, and I know a lot of people did that. Using Context in that way is very similar to creating a stateful service in Angular and injecting it into your components.

ng127 anni fa

Hooks are used for abstracting component state logic. React is just as agnostic concerning how you implement your business logic as ever.

nicoburns7 anni fa

I agree that the pattern of "services" is a good one. But you don't really need Angular's DI for this in javascript. You can just use an ES6 module.

bradstewart7 anni fa

Unless you care about the scope/lifecycle of the service. Or want to easily replace its implementation in different contexts (like tests).

ng127 anni fa

Most test frameworks allow you to stub imports. DI is just one of the many wheels Angular has reinvented.

onemoresoop7 anni fa

I started working with angular 7 this February and I have to admit the learning curve was steep at first but after the slow start I quickly built my first project and now fully appreciate its power. I also think I am lucky to have taken a stab at it in its current stages, 4+ as I lost my patience for too much noise and too many changes. I also have many praises for Visual Studio Code. The reasons you mentioned are very valid and thats the reason Angular got adopted by enterprises. The uniformity the framework imposes on the projects makes it easy for other devs to jump in, to pick up a project done by somebody else, etc..

For all people who resent SPAs, continue using all jquery and other libs for small or existing projects but do consider a framework like angular if you want to build a stable web application (or a suite of web applications), you will appreciate it after your initial dive. I also recommend a youtube channel with clear non ADD turorials: search for ‘kudvenkat angular’ on youtube.

ohaideredevs7 anni fa

Are you using the angular CLI to generate components/services? That saves a lot of time.

The thing we love about Angular is compartmentalizing everything.

onemoresoop7 anni fa

Yes, I am using Angular CLI and I love it. I'd become jaded over the years with all the Visual Studio way of creating projects, lots of dialogs, popups, template generators and in my opinion dumb boring click-click way of dealing with things where the meat is hidden from the the programmer. With the new stack I feel like I am getting a whiff of fresh air. I'm still using C#/EF to create web APIs and deal with the DB layer but on the front end i'm much happier with Angular/Node/Typescript.

ripley127 anni fa

> a component-based approach to UI development

This is actually something that bothers me a lot about Angular. Yes, you can extract components, but the process of doing so is a lot more... heavyweight than in React.

In React, I can trivially extract any piece of UI into a stateless functional component in the same file (and later on I can move it to another file for wider reuse if needed). It's just like extracting a method in non-web programming, it's something you do without even thinking about it.

In Angular, that component needs to live in a separate file with a bunch of boilerplate and it needs to be registered in the module. This is OK for big components, but it's enough work that it's not practical to create tiny helper components frequently.

TheSpiciestDev7 anni fa

> heavyweight

I can agree with you there if by heavyweight you're referring to it's explicit definitions.

However, have you tried a "SharedModule"? You can throw any number of tiny components into however many shared modules (one shared module for your small-medium sized application vs n-number of lazily loaded shared modules for your large+ applications.)

I myself enjoy wrapping even helper components in modules because I then know exactly what a component needs and it's scope of dependencies.

ousta7 anni fa

wwweston7 anni fa

I'm one of the people who've built apps with 1.x, and hasn't ever tried subsequent releases. The transition didn't help matters, but it wasn't the reason why I not only have refused to consider it again, I generally don't even consider working for organizations who list it as a part of their stack.

I tend to find that most libraries/frameworks have a few central notions about what the challenge of developing an application in their technical domain is. As far as I was able to tell from working on two projects, Angular's was that JavaScript applications were not written enough like Java applications, or put another way, there were not enough idioms from a static manifestly typed kingdom-of-nouns class-oriented language being used in a dynamically typed first-class-functions-from-the-start prototypes-too language.

TypeScript has its points, there's things to like about it, but its emphasis does the opposite of persuade me that central philosophy has changed. And while I get that complex applications are complex, and most need some organizing principles and Angular is one (or more) of several attempts to figure this out, this one struck me as... not one I wanted to live inside of, to keep things polite.

If I'm wrong about Angular's central philosophy at this point, I'd be interested to hear how.

Roboprog7 anni fa

Ah, a kindred spirit. I too despise Angular’s static-OOP, inversion of control dependency injection framework aspect.

I’m working on two huge projects using AngularJS, but would just as soon do the next with Vue. Hopefully Typescript doesn’t infect that project badly.

Google as an organization seems to have decided that C++ / Java is the one true paradigm for all work.

mike1o17 anni fa

I've really enjoyed Angular. Typescript is a no-brainer now, and now that I'm starting to explore RxJS a bit more, it's impressive how powerful it can be once getting over the large learning curve. Being able to subscribe to an observer, and make a web request, and make sure that only the latest request is taken, and being able to do so out of the box is really, really nice.

DenisM7 anni fa

> I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people

Could have called it "Rectangular". Opportunity, missed.

Roboprog7 anni fa

Again, “Perl6” was already taken as a name.

Yeah, just like that, all over again.

tgsovlerkhgsel7 anni fa

> I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. [...] the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back.

I share this impression and feeling. Telling me that most of the stuff I learned for 1 was now useless (or worse, misleading) because 2 was doing everything differently was the first thing that soured me. The _promise_ of regular breaking changes soured me further, and the steep learning curve and high start-up cost sealed the deal.

With Vue, I can have a small proof of concept running without even a compiler in a few minutes. With Angular, I have to comprehend and set up the entire (new) project structure and sit down for hours learning concepts to be able to do anything - all that while remembering that the last time I learned their proprietary concepts, it all changed shortly after, and that the developers _promise_ that it will continue to change under me.

It _probably_ still makes sense for big projects, but damn, they're doing everything to keep people from trying.

cetra37 anni fa

The dealbreaker for me is no strongly typed templates. I have built big-ish apps (10-20k loc) in both React/Redux & Angular 6+ and I feel that there is still a lot of unsoundness in Angular 6 that I don't need to worry about with React & TypeScript.

bpicolo7 anni fa

> There's no need to evaluate different routers, form libraries

That's a great thing about Vue, too. vue-router and vuex are well-designed and well-supported / integrated. Makes a huge difference.

bpye7 anni fa

I've been using Angular for a few months now and it's mostly been a good experience. We've been using Angular 7.

My biggest gripe, and this might just be my inexperience, is fighting the change detector to try and ensure reasonable performance when displaying a large number of elements. There are certainly mechanisms to do this but it does seem to take some work.

jinder7 anni fa

Switch to OnPush, use async pipes and immutable data structures. Add to that some of the virtualization components that ship with @angular/cdk and you're pretty golden most of the time.

ajryan7 anni fa

You should be using OnPush everywhere, then your struggle will change to only getting changes detected in certain scenarios. Still a pain sometimes but not as bad as the Default change detection strategy.

jamesgeck07 anni fa

FWIW, the Angular team is aware that this is a pain point. There were several talks at NG-Conf a few weeks ago that referenced replacing or removing zone.js-powered change detection for increased performance and/or smaller build sizes. They're trying to avoid another Angular 2 situation though, so it may take a while for a backwards compatible solution to surface as the default.

nicoburns7 anni fa

This is precisely what I don't like about Angular. That there is all this stuff. And I have to care about what it is doing under the hood (and this is complicated and not especially well documented).

In React if I have performance issues, then it's pretty easy to work out what's causing them.

jamesgeck07 anni fa

You can largely ignore what Angular is doing under the hood, tbh. If you're having performance issues, the answer is often related to change detection (aka, Zone.js).

nicoburns7 anni fa

> If you're having performance issues, the answer is often related to change detection (aka, Zone.js).

This is part of Angular really. At least it's not optional to use it. Change detection issues are not fun to debug!

jamesgeck07 anni fa

> At least it's not optional to use it.

Zone.js is optional, although it is on by default. It's considered best practice to remove it when building standalone components with Angular Elements.

equasar7 anni fa

what's your use case to display a large number of elements in the same page? Curious.

paweldz7 anni fa

like lists with thousands of elements? OnPush change detection and virtual scrolling - https://material.angular.io/cdk/scrolling/overview

rubicon337 anni fa

I couldn't agree more. Angular really is an incredible framework, with great resources available.

I built my business' web application (and android app) using Angular. It works so well both in the native browser, and in an Android wrapper.

My ONLY complaint about Angular is the initial load time.

ng127 anni fa

> embracing TypeScript

There's been a huge React/TypeScript community since day one, even before Angular2 was released with TypeScript. The only difference is it's optional with React.

> creating injectable shared state (or you can call it Context)

Or Flux/Redux?

daotoad7 anni fa

If you want a redux implementation you can either use NgRx (http://ngrx.io) or use the real thing with Angular Redux (https://github.com/angular-redux/platform).

rolltiide7 anni fa

How do you guys keep up with these frameworks?

You get stuck on one project or in one startup for 2 years and Angular has moved 6.5 whole number versions

all while the rest of the job market is confused but kind of tolerating why you jump around jobs so much

if I'm using Angular, my "side project" isn't going to be using a higher version of Angular every 6 months. Its going to be using React or something to see what I'm REALLY missing.

tashoecraft7 anni fa

Angular uses semantic versioning and adheres to it very strictly. Most of the time updating between versions merely involves running "ng update --all" and if that doesn't auto update everything you just see which items it errored for and update them. There have been articles showing how very large enterprises have updated their entire codebase in under a day.

If you're on one project or startup using Angular and you haven't kept up with the versioning that's a problem with the developers. There is no reason to be using a version lower then 1 back.

Features marked for deprecation will at minimum take 2 version to be removed, so 1 year after deprecation was marked. This isn't like Angular 1 -> 2 and I hope anyone who pays attention at all to front end will realize this. Complaining about angular versioning at this point would be like complaining that react bumped a patch version.

rolltiide7 anni fa

> This isn't like Angular 1 -> 2

I'm seeing that

Organizations are still supporting a transition from 1, "1.5" and 2

qwerty98767 anni fa

Because angular versions are like chrome versions. 1->2 was a full rewrite, now the new major versions always have some small upgrades and even smaller amount of breaking changes, it's not a big deal at all to upgrade.

You don't really have to upgrade every time a new version is out btw.

ng127 anni fa

React really hasn't changed much since React.Component was introduced. Some lifecycle methods were deprecated/replaced, and hooks were added. That's honestly about it.

royjacobs7 anni fa

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

mhd7 anni fa

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…

meredydd7 anni fa

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

EugeneOZ7 anni fa

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

ChicagoDave7 anni fa

WebAssembly is still a couple of years away, sadly.

mhd7 anni fa

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.

sheeshkebab7 anni fa

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

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

gaze7 anni fa

I miss Delphi.

BreakItDown7 anni fa

I don't. Not even a little.

cjblomqvist7 anni fa

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?

microcolonel7 anni fa

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

royjacobs7 anni fa

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

arnvald7 anni fa

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.

royjacobs7 anni fa

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.

aitchnyu7 anni fa

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) } ```

vfc17 anni fa

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.

jmkni7 anni fa

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.

royjacobs7 anni fa

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.

h1d7 anni fa

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

bdcravens7 anni fa

What batteries does Angular include that Vue doesn't?

mcescalante7 anni fa

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

onemoresoop7 anni fa

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.

daotoad7 anni fa

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.

rufugee7 anni fa

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

meddlepal7 anni fa

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.

vfc17 anni fa

This release is awesome, here is a summary from the Angular team blog - https://blog.angular.io/version-8-of-angular-smaller-bundles...

The main feature among many is differential loading, that will load different versions of the application depending on the capabilities of the browser.

This will avoid installing polyfills without the need for them and reduce the bundle size. There are reports of 40kb reduction in bundle size, which is a lot.

More than that, this release does a lot of preparation work for Ivy in version 9, which will bring a completely new rendering layer.

Also, there is a lot of preparatory work for the introduction of Bazel in the build pipeline, which will bring us fully incremental builds (recompiling only the part of the code that changed and nothing more).

preommr7 anni fa

> There are reports of 40kb reduction in bundle size, which is a lot.

It would be for libraries like react or vue that are already small. Angular is still big enough that even after being 40kb slimmer it's still fairly huge (I think the typical build is like ~550+kb).

jamesgeck07 anni fa

It's just the first step. With both differential loading and Ivy, build sizes for a minimal app can drop close to 14kb, iirc. That's the goal, anyway.

mrmonkeyman7 anni fa

Use any UI lib or anything of substance really and your app is going north of 500kb really fast.

marshallant7 anni fa

Differential serving can easily be done using babel and webpack. Been doing it for awhile now.

vfc17 anni fa

Yes, it was possible with Angular also before, just like with other frameworks, but now this is built-in the Angular CLI build pipeline.

This means that this is now mostly transparent to developers, and taken care for us by the build pipeline without having, for example, to configure webpack and Typescript manually ourselves.

turadg7 anni fa

How simple is it to implement? I’ve been considering this but figured the complexity may not be worth it.

How many different builds do you emit?

Do you run into any frustrations with your user error logging tools having different stack traces?

dmitriid7 anni fa

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.

equasar7 anni fa

What's the point you are trying to achieve with that negativity?

Writing non existing tooling around some tools is almost positive as they can pave the journey to other and better tooling.

Also, I doubt you are paying a cent to those developers to justify your complaints about it.

dmitriid7 anni fa

> What's the point you are trying to achieve with that negativity?

Not trying to achieve anything. It’s my own personal opinion on how I view Angular’s development. The devs dig deeper and deeper holes to bravely climb out of them.

> Writing non existing tooling around some tools is almost positive

Since there’s no cost-benefit analysis, “almost positive” is entirely speculation.

> I doubt you are paying a cent to those developers to justify your complaints about it.

“Only paying customers are allowed to voice criticism. Please purchase a criticism package or a yearly subscription today. Volume discounts are available, contact your nearest sales representative”

pier257 anni fa

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.

christophilus7 anni fa

I tend to agree. But in defense of the SPA, my experience is that over time, most screens accrete complexity.

You start out with a simple content screen. Then the client wants comments. Then they want richer comments. Then they want live comments. Etc.

Over time, most of my web applications tend to require richer and richer interactivity on each screen. As a result, it's nice to have started out with a client-side framework, rather than hitting some threshold where you suddenly need to switch things over.

hombre_fatal7 anni fa

Your last paragraph summarizes why I default to a client-side framework if there's going to be much of any JS interactivity at all on a screen.

Even something that seems simple like a search form can be surprisingly interactive.

pier257 anni fa

> As a result, it's nice to have started out with a client-side framework

You mean like Angular or Ember?

Because you can perfectly use Vue, React, Inferno, Svelte, Imba, etc, on a multiple-page application.

switz7 anni fa

I'm not a fan of Angular, but how many times are we going to have this conversation. At this point, this is a completely off-topic comment that has no place in this thread. I'm getting javascript fatigue fatigue.

> With some exceptions, there is really no benefit

This is just a contradictory sentence of hyperbole. Who cares if there are plenty of use-cases to not write a SPA. There are also plenty of use-cases for it, and many benefits.

Angular is a popular library and therefore this is newsworthy and we should respect it as such instead of devolving into a played-out asymptotic argument.

pier257 anni fa

> There are also plenty of use-cases for it, and many benefits.

I obviously disagree, but please elaborate.

equasar7 anni fa

I would like to read your elaborate opinion of why there's no use-cases for it.

pier257 anni fa

I didn't say there are no use cases for a SPA, what I'm arguing is that in the vast majority of cases it's not a good option.

What constitutes a SPA? Essentially it is a JS application that handles all route changes and in consequence also has to handle application logic, state, etc.

To be able to achieve that kind of functionality development becomes much more complex. Not only you now get all the architectural nuances of making an app, which your typical JS dev doesn't understand, but the dev workflow becomes convoluted for a number of reasons:

1. Not all browsers support the same language features and APIs which introduces the need of using transpilers like Babel or Traceur.

2. JavaScript is objectively a poor language for complex projects hence the success of alternatives like TypeScript.

3. The JavaScript standard library does not live up to the necessities of the modern front end developer which introduces the need of using and managing more dependencies. For example, after all these years there is still no native reactivity.

For these reasons we now have to use bundlers like Webpack, NPM dependencies, and a very long etcetera. Plus a continuously changing dev landscape (see React hooks for example).

It is still challenging to make an accessible SPA. Common functionalities likes control+click on a link have to be re-implemented.

Of course sending all this functionality to the client can have a serious cost in size and CPU. It's not as big in leaner frameworks/libs like Svelte but it's always there.

The initial bytes can be mitigated by using something like Webpack chunks, but again this introduces more dev complexity.

Finally, in the vast majority of cases (if not all) SPAs also render the content. This requires developing an API (GraphQL, REST, etc) which introduces another layer of complexity vs doing the rendering in the server. In some cases this is necessary as there can be various clients, but not always.

IMO all these drawbacks make sense when the SPA model is justified and there is a need for sophisticated functionalities. Gmail is the perfect example. Soundcloud is another good candidate since audio needs to keep playing at all times.

So usually the arguments in favor of an SPA are that the UX is better or that after a number of clicks the user receives less bytes compared to receiving markup.

I think that the UX benefits of a SPA are exaggerated for common use cases (e-commerce, CRUD admins, enterprise apps, marketing websites, etc). Amazon, Ebay, Wikipedia, are not SPAs and they are still getting millions of visits every day and probably growing.

As for getting the data in JSON or WebSockets vs getting HTML, yes, after a number of clicks there are some bytes savings but after having paid a high cost in initial bytes and CPU cycles. This argument could make sense in very particular use cases, but I don't think it can be applied as a general argument on all websites. It makes sense for gmail, since there is a lot of clicking around and changing views, but that's not a concern for the vast majority of websites.

I should probably write an article about this since I've left out some points and haven't gone with much depth into others... but I hope this comment conveys my position.

elliotec7 anni fa

"The vast majority of cases" doesn't mean anything. Everything depends on what you're building.

First I must say that this phrase: "Not only you now get all the architectural nuances of making an app, which your typical JS dev doesn't understand" is ridiculous and needlessly derogatory. There are a LOT of JS devs in the world, and the "typical" ones obviously understand this, or you wouldn't be on the internet right now. Furthermore:

1. That's why JS projects use Babel. Or Typescript.

2. This point is objectively false, given the fact that most websites you use are complex JavaScript projects. Also, yeah, there's TypeScript.

3. That's why JS projects use libraries and "more" dependencies. It's very rarely an issue.

- "we now have to use bundlers like Webpack, NPM dependencies..." Have you heard of Makefiles, unix package management tools, "and a very long etcetera"? None of this is new by any means.

- "Plus a continuously changing dev landscape" - welcome to programming. Change is a constant.

- "It is still challenging to make an accessible SPA..." Of course! it is still challenging to build products, and make good UX. Welcome to programming for users. Good luck figuring out what they want and need. There are jobs for that too.

- "sending all this functionality to the client can have a serious cost in size and CPU." Sometimes. Sometimes not. Sometimes it doesn't matter, like in most of the cases of most of the customers using SPAs. When it matters, people figure out how to solve this.

- "Finally, in the vast majority of cases (if not all) SPAs also render the content" - definitely not all, maybe JUST the majority. And... "developing an API" vs "doing the rendering in the server" is rarely an issue or conversation and basically not a valid argument.

- "Amazon, Ebay, Wikipedia, are not SPAs and they are still getting millions of visits every day and probably growing." This is a fundamental misunderstanding of what a SPA is. Of course not literally every single page on the top largest websites in the universe are consistently in one single application with only client routing. But each of them have many pieces that are. Most popular web apps are hybrids like this.

- "It makes sense for gmail, since there is a lot of clicking around and changing views, but that's not a concern for the vast majority of websites." This leads to a philosophical discussion of the difference between a website and a web application, where one is mostly reading and displaying data, and the other is "a lot of clicking around and changing views" (which, it turns out, is what many, many companies and products fundamentally are), which isn't really germane to this. It's probably safe to assume most of us are talking about the latter. We can also agree that blogs don't usually need app behavior.

pier257 anni fa

> Everything depends on what you're building.

Obviously, that's precisely my point.

> ...is ridiculous and needlessly derogatory. There are a LOT of JS devs in the world, and the "typical" ones obviously understand this, or you wouldn't be on the internet right now.

I admit I speak from my anecdotal experience, but probably so are you. Also because something works doesn't mean it's properly coded.

> That's why JS projects use Babel. Or Typescript.

Yes, that's what I said. My point is that needing to use Babel is not a good thing.

> This point is objectively false, given the fact that most websites you use are complex JavaScript projects. Also, yeah, there's TypeScript.

First, you don't really know which websites I use. Second, I seriously doubt HN is a complex JS project nor classic desktop Reddit or StackOverflow. Third, TypeScript precisely validates my point.

> That's why JS projects use libraries and "more" dependencies. It's very rarely an issue.

> None of this is new by any means.

> welcome to programming. Change is a constant.

No offense but that is the typical JS developer Stockholm syndrome.

Yes, obviously, there will always be change in all aspects of life. In any other language things are much more stable.

> Of course! it is still challenging to build products, and make good UX.

You are missing the point which is: SPAs are solving problems that are already solved at the browser level.

> This is a fundamental misunderstanding of what a SPA is.

Not really, you are fundamentally cherry picking. The core experience in those sites are not SPAs, it is irrelevant if they have some SPA mini site somewhere.

> This leads to a philosophical discussion of the difference between a website and a web application

Exactly, and that's my whole point.

There is an abuse of the SPA architecture for websites that are not applications. Even when the development complexity is a lot higher with not many benefits for regular websites.

ng127 anni fa

I've spend the last decade building highly dynamic data visualization applications. Building them server-side would be a huge pain.

pier257 anni fa

A visualization doesn't need to be a SPA.

ng127 anni fa

No, but one that's highly interactive and is constantly re-fetching/updating data does.

krisrm7 anni fa

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.

pier257 anni fa

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

Right, but you could still do server side rendering by consuming a third party API instead of a DB directly.

Maybe bloating is not an issue in some use cases, but client side rendering can have a major impact on the CPU.

krisrm7 anni fa

The "server" part of the "server side rendering" is necessarily on premises, and likely to move to... something? Soon? I deliberately wrote it as thin as possible, because it will need to be rewritten, without question. The db, fortunately, is on a stable platform.

I don't disagree with the bloating issue, but in this case, these are all decently capable desktops, and it hasn't been even close to a problem.

jmkni7 anni fa

I'm kind of with you.

I think SPA's can be suitable (sometimes) for internal line-of-business applications, where you have a degree of control over the environment the end user will be using your application on (ie the device/browser (+version)/etc) and bandwidth isn't a big issue.

In this sort of environment, Angular can work pretty well.

For public facing applications, where you can't say with confidence that your end user will be on a modern computer, using a modern browser with a good internet connection, etc, you are better using a server-side rendering framework and progressively enhancing using something like Vue.js.

That's my 2 cents anyways.

remify7 anni fa

You can do severside rendering with Angular Universal.

Also Angular has helped me a lot with bowser compatiblity in the past (IE 9).

jmkni7 anni fa

True, you can also do it with more mature frameworks such as Rails/MVC Core/Django etc.

I don’t have experience with Angular Universal, I do with Nuxt (Vue SSR) and it was great, but frustrating to work with as things got more complex.

onemoresoop7 anni fa

SPAs aren't classic websites, they are web applications and should only be used when you need to create a web application. If a SPA is created for every usecase a regular website would do is a bad management decision but nothing wrong with SPAs per see. And yes, in this particular case is a waste of resources.

hendryau7 anni fa

I've been building Angular apps for 3 years now, and all projects I've built have had a "relatively light" frontend, meaning little to no business logic there.

Angular as a framework doesn't prevent you from doing anything on the backend. It's all about the re-usable components imo.

phponpcp7 anni fa

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.

pier257 anni fa

Yes it's all about the use case, but I generally don't buy that argument.

First, because the largest ecommerce websites are not SPAs and are generating a shit ton of revenue. Not only Amazon and Ebay but also stuff like Magento and Shopify.

Second, while it can be argued that after a number of clicks the total kbs will be lower by using JSON and rendering on the client, the vast majority of users really care about the initial load. Much like monthly payments, it's generally better to have a consistent 500ms lag than a 3000ms lag on the initial load and then 200ms on every click. Of course I made these numbers to explain my point.

This does not apply to all use cases obviously. In some cases such as an application like Gmail an SPA is completely justified and my arguments do not hold, but in the case of e-commerce I think there are no valid arguments for an SPA.

strzibny7 anni fa

Exactly! Initial load is IMHO far more important, since as I travel the world some sites (including allmighty new GMail) just won't load. No load, no sale. And maybe perfectly crafted JSON will be very small, but a classic HTML page it's not gonna be much more than that (compared to cached assets).

jackbravo7 anni fa

Angular has server side rendering capabilities, called universal angular app, which allows sending HTML pre-rendered to the client similar to Next.js or Nuxt.js.

holografix7 anni fa

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!

jaabe7 anni fa

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 tech hype cycles much, at least not when you live in a country like mine.

vnglst7 anni fa

I can confirm this for the Dutch public sector as well. I'm saying this as a longtime React contractor. There's some React contracts, but very few and no Vue that I know of.

h1d7 anni fa

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

kreck7 anni fa

We're not doing .NET, however i suppose besides the fact that it uses TypeScript it is popular with MS developers, because it gives you a structure that allow to develop enterprise applications in larger teams.

If you know your application will have to be enterprise grade, will be large, will be developed by enterprise devs and has to be supported for years to come, Angular is still the definitive choice (IMHO). Mainly because it gives your team a clear structure to operate in combined with known concepts.

mbesto7 anni fa

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

Gene_Parmesan7 anni fa

MS Build? I was there too! Great conference.

This fact about Angular doesn't surprise me. It uses TypeScript which is a Microsoft joint, and the architecture feels rather similar to the MS standard MVVM. Two way data binding in the UI, a "code-behind" in the component. And TypeScript lends a sort-of C# flavor to the framework. It takes some "enterprise" and puts it in the front-end, which can help make the transition from ASP.NET MVC or whatever to Angular a bit easier (especially as compared to something like React).

If you're already doing .NET stuff, and you need enterprise-grade front ends, Angular seems like the natural choice still. One thing about Microsoft shops (of which my employer is one) is they tend to use Microsoft for everything, and despite Angular not actually being Microsoft, TypeScript makes it close enough. I'll be curious to see if the eventual production-ready release of client-side Blazor changes the dynamic at all.

tvphan7 anni fa

The Stack Overflow developer survey showed that React and Angular are neck to neck so there's obviously a lot of people who use it.

However, you can see just how popular React is by number of npm packages that depend on it: https://github.com/facebook/react

inglor7 anni fa

In my experience (as a conference speaker) the people who recommend .NET and sell .NET consulting are often the same people who recommend Angular and do Angular consulting.

Both have a relatively high entry barrier compared to their alternatives (though lower than a few years ago).

pjmlp7 anni fa

I do enterprise Java and .NET consulting, in what concerns Web frontends, if we use a SPA framework, it is most likely Angular.

If we are using just a couple of WebComponents with traditional server side rendering, then Vue.

jetti7 anni fa

That doesn't really surprise me as Angular uses TypeScript.

Yuioup7 anni fa

Meanwhile Microsoft is porting all of Office to React and have released React Native for Windows.

Sahhaese7 anni fa

This should point to https://github.com/angular/angular-cli/releases/tag/v8.0.0 which is the release page for this version rather than all releases.

tashoecraft7 anni fa

I can’t update if a mod wants to update it for me then go ahead

FiniteLooper7 anni fa

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!

sheeshkebab7 anni fa

Job security

zihotki7 anni fa

I wonder what's the story behind delays of Ivy? Can somebody elaborate? It was first scheduled for v6 (don't remember , then for v7, now there is v8 and it's again rescheduled for v9.

romanovcode7 anni fa

It needs to be backwards compatible and it is tested with google internal applications and needs to be approved by said applications.

jamesgeck07 anni fa

To add to this, the Angular engineers at Google are responsible for updating all however-many-hundred of those internal applications if they make any backwards incompatible changes.

imcotton7 anni fa

That what they have been saying for years, not what the REAL reason.

romanovcode7 anni fa

What would be the real reason then? It's not like they are workng on something else. Ivy is pretty much all they are working on for the past 1-2 years. Even to the point where events like Angular Connect are very boring because there is nothing new except this. I'm pretty sure they want to release it ASAP and be done with it.

fknop7 anni fa

Note that it already mostly works right now with v8.

bob10297 anni fa

I honestly had no idea this was still a thing. We jumped ship to riot.js back around Angular V2 and haven't really thought about another javascript framework since. All of our web tools have been vanilla JS/CSS/HTML with riot tying it all together for the last 3+ years now. It really does seem like the ideal way to compose single page web applications. We do use some 3rd party stuff like codemirror, momentjs, etc., but that's about it. Not even jQuery to be found unless some 3rd party component depends on it.

The advantages of not using someone's framework, language or module system is that we have a direct and stable surface (the DOM) against which to tie things together. Complex web interactions we attempted to do (and failed to do) using Angular directives/components/etc became trivial using our vanilla+riot approach. It almost feels like cheating by comparison, and then you don't care because your incredibly-complex web interaction that involves 5+ vendor libraries and 8 nested API calls just works and is easy to inspect directly.

Obviously, you need some discipline to manage something with less structure around it, but all it takes is a handful of code review sessions to get other developers synced up on how things work in this more 'open' world. There honestly aren't a lot of new things to learn either (there are definitely more things to unlearn coming from Angular). Productivity is also a huge plus. I don't have to spend an hour reviewing the semantics around some Angular construct before I do my work. After a few weeks away from some web project, I can jump directly into the HTML/JS/CSS, crank out a new .html riot tag file and be done with it in less time than it would have taken to re-sync my brain into Angular semantics land.

If you haven't tried riot yet, you should definitely take a look. Once we got our first application working on it and we understood the basics, it felt like we had escaped from frontend jail and could do anything we wanted to. For everyone who views front-end as a mosh pit of chaos and uncertainty, I strongly suggest trying this approach out on a throwaway project when you get some free time.

pier257 anni fa

Anyone knows when Riot v4 will be ready?

I wanted to try Riot but then I saw they were working on v4 with the Simulacra guy and decided to wait until the new version.

visarga7 anni fa

Angular is too abstract / has a steep learning curve. You need to learn too many design patterns at once (factory, provider, service, singleton, pipes, directives, observable, component, container, dependency injection). Trying something simple is trivial, but trying something more complex is overly difficult.

DrFell7 anni fa

True, but you are learning ubiquitous programming concepts in about as well conceived of an implementation as you will get in a frontend scripting framework.

While none of the extra complexity is crucial to making a dynamic website, it earns its keep when you try to build a big online application. Why not just learn that stuff.

I think all the bundled pre-built functionality, like reactive forms, is the hardest part of Angular. That can be tedious to learn. But then again, so is 3rd party library X, so it's a wash.

Factories are no longer in Angular 2

sa467 anni fa

I understand your point but to be fair, if we cherry pick all the terminology from React it also looks bad:

JSX, components, props, context, error boundaries, forwarding refs, fragments, higher-order components, container.

Once you add in concepts from the other libraries commonly used with React like mobx or redux I think the comparison isn't as clearcut.

[deleted]7 anni fa

revskill7 anni fa

I feel Svelte is the framework that Angular author actually wanted to build since the first version.

romanovcode7 anni fa

A lot of talk about Svelte in this thread, I guess it's the new FOTM front-end framework.

In any case - angular has no one author and it is moving to the Svelte direction of rendering with Ivy which is to be released in next major version.

inglor7 anni fa

Funnily enough, Ivy takes a pretty similar approach to Svelte with its markDirty calls similar to Svelte's $$invalidate calls.

That said, Angular doesn't utilize its compiler the same way Svelte does (yet) so time will tell.

Sammi7 anni fa

I think moving stuff from runtime to compiletime is the theme of most changes to Angular 2+ compared to Angular 1. So I'm very much expecting Angular devs to look at Svelte and start hitting ctrl-c ctrl-v repeatedly on their keyboards :)

arnvald7 anni fa

Congratulations on the release and thanks to core team and all contributors for their work!

sheeshkebab7 anni fa

Angular feels like frontend framework built by backend java Spring developers, that hate frontend development.

stupidcar7 anni fa

This feels like an argument made by somebody who has never built a serious project in either, and has instead formed an opinion based on quick glance at the respective syntaxes.

To me, Angular is what HTML and the DOM would look like if they had been designed from the beginning for application development:

- Custom elements backed by controller classes. - Data-binding and event-binding syntax baked into HTML - Component style encapsulation, on by default.

React seems far more like a project created by people who dislike front-end development: As I recall the genesis of the project was to replace traditional DOM mutation with a more PHP-esque approach of updating state and re-rendering everything, just as you would do on the back-end.

shadowmint7 anni fa

Why does having a different opinion to you mean someone has no idea what they’re talking about, or has never used a thing “seriously“?

I used to love angular, then I got a job which was a “| async” dumpster fire and spent a year watching a team of smart c# developers wallow in a mire of disaster so bad it became a two week regression to change a text field on a form. So full of amazing functional statement no one, even the original authors, could touch it without breaking something in the process.

so.

Your milage may vary. I no longer particularly like angular, personally, because I find it a chore to herd inexperienced FactoryInjectorConstructorFactoryPattern angular developers into not screwing things up.

...but talented team can do well with it too, and I’ve seen people screw up react projects too.

It really is more about good practice and experience than framework, your personal preference is probably, like mine, basically irrelevant.

zdragnar7 anni fa

I've shipped products using most major FE frameworks. Those things can be had by pretty much any of them. The biggest annoyance with angular is the excessive amount of baggage and boilerplate.

Decorators aren't inheritable or composable. Because templates are strings, you need the hacky DI and superfluous module system to avoid tag name clashes.

As for React, it is nothing like PHP. JSX is a macro for function calls that return objects; as such they are first-class data structures with all of the benefits you would expect. Yes, it is just a view layer and you need to bring more stuff in if you have a big project planned.

If angular floats your boat that's great. The last time I used it was in a team of mostly C#, Java and Python enthusiasts. Once they figured out what was es2015, what was typescript, and what was Angual, the dev experience was generally reviled. (especially once they saw some react code). I generally don't say that I won't work with a technology, but after a year with it (and having years for AngularJS/1.x, React, Ember, Vue and Backbone under my toolbelt) I am content with saying that Angular sits with Backbone at the bottom of the pile of what I would choose to use again.

hesarenu7 anni fa

React seems far more like a project created by people who dislike front-end development - that seems way off. For me react is the perfect fit for front-end development. You have syntax similar to html and logic in plain javascript. Angular is like some heavy java back end framework.

ng127 anni fa

> React seems far more like a project created by people who dislike front-end development

This is a really poor characterization. I started using React because I love front-end and it was exactly what I wanted front-end development to be. It solved every one of the pain-points I was experiencing with a jQuery/Backbone/Handlebars stack.

sdegutis7 anni fa

Every time I look at Angular, I remember that they use string literals for both HTML and CSS which is strongly off-putting. Especially because for HTML, it becomes another template language like Vue.js, whereas React.js is just JavaScript with a simple and predictable syntax transformation.

sixbrx7 anni fa

You see the template and css as literals in little Angular examples, but the normal case is that the literals are just names of the separate html and (s)css file names.

royjacobs7 anni fa

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.

scotchbonnet7 anni fa

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.

RhodesianHunter7 anni fa

And if they do ever hit it, having never seen a reason to use it before, they instead layer over it with poorly thought out abstractions leading to unmaintainable code that they'll probably hoist onto the next dev.

porker7 anni fa

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?

p2t2p7 anni fa

Recently I had to hide a bunch of functionality for certain license type in a product. Spring + AspectJ turned it into a enjoyable experience - just add one annotation, two classes, one for aspect, another for exception mapper in rest and you can mark any class as "requires certain type of license" in one like of code now.

merb7 anni fa

the problem in angular is that it's bloated. and their components generate a load of bloat. Since basically all components have a FactoryComponent thingy, which you don't see, because it gets generated. However a bigger application can easily grow to a few mbs which is a huge no-no for javascript in the browser.

vfc17 anni fa

It feels familiar to Java developers, due to Typescript which is also statically typed (but much better IMHO) and due to the use of decorators and classes, which are an awesome way to describe a component.

Being familiar to a large base of existing developers is a huge feature.

azimuth117 anni fa

React has also been using classes for a long time (although the trend is to move away from them for performance and simplicity reasons). There is also a huge upward trend of people using TypeScript with React. Personally, after using TypeScript & Angular at work, I've preferred switching to TypeScript when using React in personal projects.

My main gripe with Angular (vs. React) has been the lack of first class support for patterns (higher order components) that have been a boon for React. It does look like Angular will have more 1st class support with Ivy[1], however, higher order components are so simple with React (and even better with TS/React).

[1]: https://blog.nrwl.io/metaprogramming-higher-order-components...

preommr7 anni fa

> React has also been using classes for a long time

And this

> (although the trend is to move away from them for performance and simplicity reasons)

Make me very frustrated because things like react became very popular for their simplicity. I read the reasoning the react team gave for hooks and I am not sure it justifies having such vastly different way of building components.

asark7 anni fa

Hooks are the biggest WTF for me in React-land, which is saying something. Classes and inheritance can lead to bad situations sometimes if you use them wrong, so we'll write our own method & property lookup table with a joke UI, then just not implement inheritance so that problem doesn't come up. I mean... what?

merb7 anni fa

> although the trend is to move away from them for performance and simplicity reasons

I do not think that react classes will go away anytime soon. you can't represent state without them.

jaquers7 anni fa

https://reactjs.org/docs/hooks-intro.html

edit: Lol apparently two React devs ears were burning at the same time.

merb7 anni fa

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)

allover7 anni fa

> 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

azimuth117 anni fa

While you wouldn't want to leave "console.log" in your code in production, you can use them in function components just like a classes' render methods.

A better example (from the video "React Today and Tomorrow and 90% Cleaner React With Hooks" from October[1]) is something along the lines of updating document.title = `${some} Page` or possibly calling an API.

[1]: https://www.youtube.com/watch?v=dpw9EHDh2bM

allover7 anni fa

The console.log was only there to illustrate that the code in useEffect's callback is only being run on the client-side (see the codesandbox I linked to).

I think it's clear from the parent I was responding to that they have better use-cases in mind :)

jaquers7 anni fa

Btw, totally agree about classes. I still like the 'look' of them for stateful components.

pennaMan7 anni fa

https://reactjs.org/docs/hooks-intro.html

vikingcaffiene7 anni fa

Honestly have you ever built anything of substance w/ it? It’s an awesome framework. You really should give it a try.

murph-almighty7 anni fa

I detested working in AngularJS but I'm loving 2+. 2+ and NgRx is also pretty nice if you're trying to add state management, although sometimes it just feels like I'm using effects as boilerplate on top of API calls.

dio1237 anni fa

https://github.com/jhipster/generator-jhipster/issues/9817 :)

romanovcode7 anni fa

Have to be honest, had to double check if this project was not satire.

https://www.jhipster.tech/

mrec7 anni fa

The name does have a certain https://html9responsiveboilerstrapjs.com/ vibe to it, yes.

rafaelvasco7 anni fa

Front-end development is inherently chaotic right now, doesn't matter the framework. Things will get better.... I'm intrigued by Svelte.

shapiro927 anni fa

I took a peak at Svelte and wow this seems promising. I think its heavily inspired from WPF app building

benatkin7 anni fa

I'm not crazy about the significant filenames. Maybe I should because I like significant indentation. This might help me see where those who don't like significant indentation are coming from.

https://github.com/sveltejs/realworld/blob/master/src/routes...

benatkin7 anni fa

Front-end development is really great right now, because of React, which makes it so you can develop in one language, but unlike past attempts like GWT [1], doesn't rely on leaky abstractions.

1: http://www.gwtproject.org/overview.html

OkGoDoIt7 anni fa

Everything is a leaky abstraction at some point, the question is how much of a pain is it once you do need to dive underneath?

Personally I’ve found debugging and dealing with anything non-standard in React to quickly turn into a huge mess (but given all the praise heaped on it by other developers I know, I’m willing to concede that I might be doing it wrong).

lostjohnny7 anni fa

JSX is a different language

benatkin7 anni fa

JavaScript with JSX is a single language. The tags are a syntax extension. JSX is a very non-leaky abstraction. The tags are just function calls. https://reactjs.org/docs/introducing-jsx.html#jsx-represents...

royjacobs7 anni fa

I don't buy that argument. On the one hand you claim there's no leaky abstraction, yet your argument only works if "Javascript with JSX is a single language".

Then "C++ with inline assembler" is also a single language? What about English with quotes in Japanese?

kaoD7 anni fa

JSX is syntactic sugar for JS[0]. C++ and ASM (actually, _which_ ASM?) are different languages.

[0] https://fettblog.eu/jsx-syntactic-sugar/

royjacobs7 anni fa

Since JS is the only thing you can actually use[1] in a browser you can argue that anything that runs in the browser is syntactic sugar (and in fact, Typescript is syntactic sugar).

A less flippant analogy might be macro support in Rust. It's clearly part of Rust, but the syntax is completely different and it requires IDEs to have completely separate processing just to handle it. I wouldn't consider that to be mere syntactic sugar either.

[1] Yes, yes, wasm

kaoD7 anni fa

JS and JSX are isomorphic (in the mathematical sense) hence why JSX is considered just syntactic sugar.

JS and TS aren't isomorphic (there's no inverse morphism once you go TS->JS that can bring the resulting JS back to the original TS) hence why TS is a different language (even if a superset of and compiled to JS).

lostjohnny7 anni fa

> JS and JSX are isomorphic

They are not

Or, if they are, they are in the same way of a custom XML templating language that can be translated to a specific javascript library implementation and then back to XML

In the same way, is Mustache isomorphic?

    "{{title}} spends {{calc}}"

can be translated to

    `${title} spends ${calc}`

and back to

    "{{title}} spends {{calc}}"

[deleted]7 anni fa

pier257 anni fa

> because of React, which makes it so you can develop in one language

You may argue that JSX is a single language, but that is irrelevant since you still need to understand HTML and CSS.

justanegg7 anni fa

Tade07 anni fa

My take is that it would have been so much better had the devlopers not elected to bundle Rx.js with it.

adl7 anni fa

as a Java Spring Developer that hates frontend development (and loves Java and Spring), I found this very funny :)

romanovcode7 anni fa

Great, this is why I think Angular is amazing!

i_can_c_sharp7 anni fa

Does anyone know how Angular compares to Aurelia?

ousta7 anni fa

sungju12037 anni fa

bricss7 anni fa

(2)