why use Angular instead of Vue? no benefit at all.
Angular v8.0
191–200 of 210 posts
Re: Angular v8.0
#192guys. as a long time old school dev. I have heard about components all my life from ASP MVC to JSF in java. what is really the difference with angular? A better embedding of RX-JS and AJAX is that it all?
Re: Angular v8.0
#193Earlier quoted context omitted.
> 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…
> 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 bec…
I agree. you need to think about where to put your component, when to design components containing components and when to design a global component embedding everything in one, when to create new services, what should be the service range, will ever components need that service or no, ect, and they are all hard choices to get back from once you have a big codebase
Re: Angular v8.0
#194Earlier quoted context omitted.
I would like to read your elaborate opinion of why there's no use-cases for it.
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 nuan…
"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.
Re: Angular v8.0
#195Angular 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 la…
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.
Re: Angular v8.0
#196Earlier quoted context omitted.
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 S…
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?
TLDR - Choose React.
Re: Angular v8.0
#197Earlier quoted context omitted.
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 nuan…
"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…
> 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.
Re: Angular v8.0
#198Earlier quoted context omitted.
> There are also plenty of use-cases for it, and many benefits. I obviously disagree, but please elaborate.
I've spend the last decade building highly dynamic data visualization applications. Building them server-side would be a huge pain.
A visualization doesn't need to be a SPA.
Re: Angular v8.0
#199Earlier quoted context omitted.
I've spend the last decade building highly dynamic data visualization applications. Building them server-side would be a huge pain.
A visualization doesn't need to be a SPA.
No, but one that's highly interactive and is constantly re-fetching/updating data does.
Re: Angular v8.0
#200Earlier quoted context omitted.
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 :)
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 somet…
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) } ```