Hacker News Reader

Comment by sheeshkebab | Hacker News Reader

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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?

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.

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.

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

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

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

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

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

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

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

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?

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

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.

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

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

https://www.jhipster.tech/

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

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

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

JSX is a different language

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

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?

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

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

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

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

> 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}}"

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

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

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

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

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

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

Great, this is why I think Angular is amazing!

Reply on news.ycombinator.com