Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Learning Angular 2 Was Excruciating

hackernoon.com

Post reply on HN
Print view View original

211–220 of 226 posts

Re: Why Learning Angular 2 Was Excruciating

#211

Post by shitgoose »

aikah wrote: post #201
shitgoose wrote: post #169

now you understand how some of us feel about Java... ironically, JS is just a natural evolution of Java, taken to a logical conclusion, so to speak.

You forgot an important difference between JS and Java : the tooling is inferior. Sure you can use Typescript which makes thing a little bit better, but good luck with out dated type definitions or libraries that do not have type definitions, good luck with templates can't be validated ( forgot some directive ? misspelled a component name ? too bad you're fucked ... ). Java is verbose but there is a fairly large numb…

this is all true, but i think the problem of JS is not the lack of generics and types, but the mindset - an honest conviction that one should pile up one layer of code on top of another like there is no tomorrow. this is the common trait between Java and JS developers. the sheer complexity of the system is the problem, not tooling. old farts like me think that complexity is bad and we try to avoid it at all cost. young generation thinks that complexity is good and try to increase it at every opportunity they have.

Re: Why Learning Angular 2 Was Excruciating

#212

Post by ng12 »

gaius wrote: post #208
ng12 wrote: post #192

Earlier quoted context omitted.

The big shift has been from managing complexity to avoiding it where possible, encapsulating it when not. In my current favorite webstack, every logical view is abstracted behind an API (which happens to be a React Component). Internally, everything about that component is encapsulated -- the internal implementation, the sub-components, even the CSS thanks to CSS Modules. In fact, if I really had a reason to write a…

Writing UI code is hard, and I'm not sure why some HN folks assume web developers are ignorant. But it really isn't and the proof is HyperCard from the 1980s. It's only hard because you have made it hard, for no reason that anyone can fathom (apart perhaps from job security).

I'm very curious what kind of web apps you think people are building. HyperCard was great for demoware -- and if you were to try and make it into a real production-ready tool you'd get VBA.

Do you really think everybody -- from Android/iOS to Swing to qt to Web 2.0 -- just had no idea what they were doing?

Re: Why Learning Angular 2 Was Excruciating

#213

Post by cromwellian »

Retric wrote: post #190
cromwellian wrote: post #135

Earlier quoted context omitted.

Google has larger and more complex JS apps than most other companies on the planet. They do a lot with Javascript besides gmail. Maps, Docs, Photos, G+, are all large Javascript applications. And those are just a few.

These are all separate applications which sit in their own silos. They are individually complicated, but they don't need to fit into some company wide framework.

They typically sit on top of internal Google frameworks. Closure's runtime library is the tip of the iceberg.

Re: Why Learning Angular 2 Was Excruciating

#215

Post by stickfigure »

adamnemecek wrote: post #204
DigitalSea wrote: post #155

Earlier quoted context omitted.

As someone who has been using Aurelia for over 12 months now, I am happy to see someone post this. A great framework that hasn't really had any major breaking changes, even when it was alpha, then beta and release candidate. Keeping it up-to-date has been no effort at all and I have been building with it since it was basically announced. The thing I find funny about Angular 2 is all of the breaking changes they made…

What do you mean by "greentea oriented framework"?

Greentea is the codename of the internal CRM application at Google that spawned Angular.

Re: Why Learning Angular 2 Was Excruciating

#216

Post by tim333 »

untog wrote: post #125
janfoeh wrote: post #76

I've said it before here and I'll say it again: the JS ecosystem is moving in the wrong direction. Sometimes I feel that with Javascript, we developers have taken something that wasn't ours, and we're in the process of destroying the best thing there ever was about it. One of its best qualities used to be that you could have absolutely no idea what you're doing, read a few bad tutorials somewhere on the web, mash you…

jQuery isn't dead - they're still releasing new versions. You can still do everything you used to be able to. But now you can also do more - you can sensibly modularise your code. Virtual DOMs bring huge performance boosts with very little work. IMO, the JavaScript ecosystem has matured. Sometimes in weird ways that aren't great, but it's still better to have an irritating package manager than no package manager at a…

>Virtual DOMs bring huge performance boosts with very little work.

Do they? In most tests I've seen straight javascript / jquery on the DOM is faster. eg. https://objectpartners.com/2015/11/19/comparing-react-js-per...

Re: Why Learning Angular 2 Was Excruciating

#217

Post by LouisSayers »

bombtrack wrote: post #129
LouisSayers wrote: post #103

Earlier quoted context omitted.

Lmao, this is exactly how I've felt, and why I'm using ordinary js with closures and a bit of jquery for the time being while I get up to speed and figure out wtf is going on. "Javascript the good parts" has served me well.

If what you're trying to accomplish is feasible and maintainable with "ordinary js ... and a bit of jquery" then using a full React+Flux stack like the OP outlined is complete overkill. If someone has experience with those libs and tools then they'll probably use it even for trivial projects. However that does not mean it's prescribed for _everyone_ to use _every time_ they need to write a bit of javascript functiona…

Sure, but tell me what isn't feasible? Ok, I'm not creating photoshop in a browser, but there have been some non-trivial highly interactive apps I've built and they are still modular and serve their purpose well.

I'm not saying we shouldn't get on react - I'm sure in the end it will serve myself and others well, but it's a bit of a headf*ck trying to figure out the whole ecosystem, and how to write a good solid app in it. For anyone that tries to say "but it's only react with x" - No it's not! Not for anyone that cares about the quality of their app, theres a whole heap to learn.

And I am learning, but at the same time I'd rather create a well designed app with the crummy tech I know than a crummy app in something I just haven't figured out yet. Luckily I'm doing my own thing so have that choice.

Re: Why Learning Angular 2 Was Excruciating

#218

Post by gaastonsr »

ng12 wrote: post #199
flukus wrote: post #196

Earlier quoted context omitted.

> Writing UI code is hard, and I'm not sure why some HN folks assume web developers are ignorant. Probably because every feature you listed was achievable before react.

I actually regret writing out such a detailed reply. Congratulations, you're a top HN troll.

Great answer. Sometimes I hate HN for people like above.

Re: Why Learning Angular 2 Was Excruciating

#219

Post by OskarS »

dkarapetyan wrote: post #83
OskarS wrote: post #59

Earlier quoted context omitted.

He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake. A release candidate is a "release candidate", that is to say "we're pretty sure we could release this whole thing right now, but we want to send it out to the community to make sure there are no catastrophic bugs we haven't noticed". In other words feature-complete, and with most of the kinks ironed out. It'…

She.

Apologies to the article writer, i didn't notice and shouldn't have assumed.

Re: Why Learning Angular 2 Was Excruciating

#220

Post by rpeden »

Andrex wrote: post #87
janfoeh wrote: post #76

I've said it before here and I'll say it again: the JS ecosystem is moving in the wrong direction. Sometimes I feel that with Javascript, we developers have taken something that wasn't ours, and we're in the process of destroying the best thing there ever was about it. One of its best qualities used to be that you could have absolutely no idea what you're doing, read a few bad tutorials somewhere on the web, mash you…

I get where you're coming from but your comment boils down in favor of unoptimized and insecure code. And I can't agree with that. I would also point out that the web is the most backwards-compatible platform of all time and Alice and Bob can continue doing their thing for as long as they want. The tools that professionals use today are an abstraction to increase efficiency and reduce code reuse, in the same way most…

The catch is that using NPM and CommonJS modules for front end packages makes it so that tools like Rollup and the Closure compiler can't do the kinds of optimizations they are capable of. The code we ship is doing a lot of runtime dependency resolution that could be done at compile time if we constructed our modules properly.

I think that many of the front end tools we use now result in an optimized developer workflow, but usually not optimized code.

Post reply on HN