I really don't get the hate for Angular 2+. Been using it for almost a year now and I love it. Fantastic stuff.
Likewise. I think a lot of the hate is down to the naming (AngularJS vs Angular), but at some point you need to just accept that it is what it is and get over it!
Angular 5.0.0
181–189 of 189 posts
Re: Angular 5.0.0
#182Earlier quoted context omitted.
Angular, React, etc. are nothing but a bunch of pre-written lines of code that does data binding. Quality lines of codes with a lot of candies, but in the end it's only a bunch of JS lines. There are no obligations whatsoever to keep your project cutting edge and even less of reason to migrate to a more popular framework. It's not as if browser support for Angular 1 would stop.
True, but it's nice to be able to use the newer features of your framework as they come out. Positive QoL changes in an API are always welcome
Re: Angular 5.0.0
#183Congrats to the new release! I've got a lot of respect for putting so much energy into open source projects. Predictably, the discussion evolves around Angular vs react/vue/ember or whatever (personally, I like react). My current customer project introduced me to a new generation of web front-end developers specializing in a particular framework (react/redux in our case) but know very little about CSS and the myriad…
It should allow side-stepping the complex morass of piecemeal evolved html features and implementation border case incompatibilities.
e.g. Today you can use Unity game engine to target WASM as a runtime and it should render, and function, very much identically across all browsers, and with a bit of creativity can be used to include forms and business functionality.
This does come at the cost of downloading the app runtime and UI libraries with the app, but frankly the download size is not such an issue anymore and in the future for many markets. e.g. 5G mobile broadband is targeting Gbit speeds!
Re: Angular 5.0.0
#184I somehow do not get all that bashing. Angular did extremely great things with Angular 1 (back then). As time passed, the community learned that there are better/other concepts. React came out - nice. NG2/4 therefore had to include major changes to pave the way for the future and more modern concepts. And it is important that they do that because some people have built huge teams and applications based on Angular. So…
People jump on a victim train too easy. If they can't complain on life, they complain on JS or Angular. If you think something is better, ok thanks, we will consider it. But what is the alternative? React? Good god, never. Vue? Can't comment, but doesn't seem to be doing good: https://trends.google.com/trends/explore?date=all&q=Angular%...
Github stars is a more precise metric. There, react has 80K, Vue is close with 72K (and gaining ground), and both are far ahead of angular on 30K (as of early November 2017).
https://github.com/vuejs/vue https://github.com/facebook/react https://github.com/angular/angular
Re: Angular 5.0.0
#185Congrats to the new release! I've got a lot of respect for putting so much energy into open source projects. Predictably, the discussion evolves around Angular vs react/vue/ember or whatever (personally, I like react). My current customer project introduced me to a new generation of web front-end developers specializing in a particular framework (react/redux in our case) but know very little about CSS and the myriad…
Perhaps WASM will provide the better match for business applications, sidestepping HTML entirely. It should allow side-stepping the complex morass of piecemeal evolved html features and implementation border case incompatibilities. e.g. Today you can use Unity game engine to target WASM as a runtime and it should render, and function, very much identically across all browsers, and with a bit of creativity can be used…
I was thinking more about ditching the browser entirely for apps. Because what WASM and WebGL do is just a very tiny subset of what's been possible for ages with plain old native languages and D3D/OGL. And why do we need a new bytecode format when basically all phones run on the ARM ISA? I guess I don't get why games should run in a web browser with all it's security and privacy issues.
But yeah, almost anything is better than HTML/CSS/JS for complex UIs.
Re: Angular 5.0.0
#186Earlier quoted context omitted.
But we're comparing against Angular, which has a router and the rest of the kitchen sink. If your React app is anything more than a toy, it will almost certainly require most of that sink and you'll suffer the version churn of a thousand ambiguously maintained components. --React developer
This is just not true, and is I think a pretty harmful cargo-cult idea. People think "industrial strength React" means react-router and redux, even though neither of those deps are required for serious production applications. As I said upthread, there's a spectrum of routing needs for applications. There are ways to use React (for real) where the server handles routing, because you're not running the whole app as a…
A thousand times, this. I am working on Redux-enabled app that answers "no" to all 5 of the questions to consider when trying to decide "do I have to put all of my state in Redux?" [0]
IMO it's now all so much more complicated than it needs to be. Admittedly this is my first exposure to Redux, but rather than "you might not need Redux" I'm leaning towards "you almost definitely don't need Redux"
Re: Angular 5.0.0
#187Earlier quoted context omitted.
I mean, I feel ya. The web was built for rendering PhD research papers, not the complex, rich, responsive apps we have today. Square peg, round hole for sure...but we been hacking away at the hole for sometime to get that peg in there...and today it is feasible to build these things. But you're right that if the web had conceived of being used for rich apps from the beginning we would have been spared a lot of troubl…
Its easy to say that, but what form could it have taken? RPC? X11? The adoption of simple REST style resources over SOAP, corba etc shows how useful the original "handle system + simple verbs" design really is.
Re: Angular 5.0.0
#188Earlier quoted context omitted.
But we're comparing against Angular, which has a router and the rest of the kitchen sink. If your React app is anything more than a toy, it will almost certainly require most of that sink and you'll suffer the version churn of a thousand ambiguously maintained components. --React developer
This is just not true, and is I think a pretty harmful cargo-cult idea. People think "industrial strength React" means react-router and redux, even though neither of those deps are required for serious production applications. As I said upthread, there's a spectrum of routing needs for applications. There are ways to use React (for real) where the server handles routing, because you're not running the whole app as a…
Sure, you may not specifically need react-router or redux, but you do need to route and you do need to manage state. So you either build your own router / state management engine or you take one off the shelf.
Yes, I do think it's fair to say: If you don't need routing, you have a toy app or at the very least are annoying the crap out of users who try to bookmark things. React-router is not "extremely complicated". On the other hand, your homegrown router may very well be a few years of revision while you learn all the lessons the react-router team learned before building v4.
Redux is a different matter; I loathe it and do not use it. Component state is great! Until it isn't. Angular has a great story around this with injected components. React... well, you bring in a library like Redux or MobX or you do something else on your own. Personally I do "something else". But Angular has a clear story here, and you aren't saving yourself any code by using React.
There's more; fetch libraries and scss resources come to mind, as well as the whole build system itself. Not to mention the actual UI component libraries.
In my short year in the React ecosystem I've gone through quite a lot of version churn, just with all the libraries that surround React. It's real and I don't see this as a "benefit" over Angular.
Re: Angular 5.0.0
#189Earlier quoted context omitted.
Perhaps WASM will provide the better match for business applications, sidestepping HTML entirely. It should allow side-stepping the complex morass of piecemeal evolved html features and implementation border case incompatibilities. e.g. Today you can use Unity game engine to target WASM as a runtime and it should render, and function, very much identically across all browsers, and with a bit of creativity can be used…
I know people put high hopes into it, but WASM by itself does exactly nothing to improve the basic rendering model of browsers (CSS and it's various layout models). It just replaces JavaScript (which I have no problem with at all), making browsers even more complex. WebGL, OTOH, can be used from JavaScript without problems, including typed arrays and SIMD. I was thinking more about ditching the browser entirely for a…
This is the only approach supported by WASM in the near future, although a browser DOM bridge is roadmapped for a couple of years on. ie ditching the (DOM of the) browser entirely for apps (in WASM) - apps that can run on ANY platform with a modern browser.
>> And why do we need a new bytecode format when basically all phones run on the ARM ISA?
There are in fact some good reasons
* It's an open standard, which it seems many vendors will get behind and it will become ubiquitously available, and as such stands a chance of competing with Html/JS for the crown of the 'everywhere platform'.
* Being sandboxed by the browser instead of running on bare metal has huge value for security.
* Being sandboxed as an abstraction layer allows ISA portability. You mention most phones run on ARM, but more than a handful of people want to use PCs running Intel too! Also not all phones run ARM, and there are future ISAs that don't exist or aren't mainstream yet (such as open source ones) and the abstraction of a runtime makes it easy. WASM has been design to be good as a portable target (ie easy to implement on a new ISA as opposed to writing full emulation).
The first one is the most important one, about being an open standard with enough industry implementation to achieve critical mass for users and become a sustainable 'any/everywhere' platform .. the technical issues could be addressed other ways, but that only matters if people can access your runtime (which is what killed Flash and Silverlight).
There are downsides too, such as performance, however the market has shown it doesn't really care about performance by choosing the bloated Javascript mess have today.
tl;dr; Runtimes are good for the majority of consumer and business software, and WASM is the first one all the big players are supporting instead of the competition sabotaging
>> I guess I don't get why games should run in a web browser with all it's security and privacy issues.
The question implies that native code has a better security and privacy profile than a hardened browser sandbox.. actually that right there is the issue. You actually get a far better security and privacy 'platform' on the browser, despite/because of the much larger attack volume.
With native you can do and access anything the OS allows, and find vulnerabilities in the entire OS APIs. Even on e.g. iOS the native code can do all sorts of things and call private hidden apis etc, Apple just tries to use static analysis to attempt to find these issues before you download it..