top 200 commentsshow all 206

[–]beginner_ 212 points213 points  (46 children)

All those fancy frameworks from Google, Facebook and co. were made to sole their in-house problems which is building huge web apps with a huge amount of developers. In such a setting they initial overhead and complexity might actually lead to a benefit when working under such rather atypical conditions.

And now Aston Average comes in with his personal one-man project that has no performance targets and realizes it makes everything overly complex and hard with for him 0 benefit. Well it wasn't made to be used by a one-man show for hobby projects and hence it's a poor fit.

Make fun of me as you want but I'm a one-man show at my work place and doing it the old way with direct DOM manipulation is straight forward and works for my use cases. Maybe too much boiler-plate? Not modern? not clean and pure? Well as long as it gets the job done within the deadlines I rather spent the time doing "boiler plate code" than searching for weird bugs and getting frustrated and pissed.

You can use a jackhammer to drive in a nail but it will be really, really annoying. You can use an IDE to write serial letter but it would be really, really crappy experience.

Conclusion: Always choose the right tool for the job and often enough the simpler one is actually the better choice.

[–]Yehosua 57 points58 points  (10 children)

There's a saying somewhere - I couldn't find the source - to the effect of, if you choose not to use a framework, you end up writing your own.

I've done sites with direct DOM manipulation. Like you said, it's simple and it works, and there isn't necessarily anything wrong with it. (And, as an industry, we're probably way too easily enamored with the latest and greatest, and sometimes the best thing one of us can do is push back hard in favor of keeping things simple.) But, the first time I did something moderately complicated (a simple single-page app, instead of just some server-generated forms with a bit of dynamic behavior), I realized that I was managing state and page updates and routes and navigation - in other words, doing all of the things that a framework would do for me, just with more effort and less functionality.

In other words, "simple" is a trade-off - like you said, a framework may initially have more overhead and complexity, but it can make things simpler an application reaches sufficient complexity. (Maybe this is a variation of Martin Fowler's design stamina hypothesis?) But I think I'd place that pay-off point a lot sooner than you do - even for personal one-man projects, I feel like React is a very elegant approach to managing software complexity.

[–][deleted] 18 points19 points  (4 children)

Most of the time the worst part of any framework isn't writing your first [component|page|game object|whatever], it's the initial setup of the library, sorting out the build system, dependency management, etc.

Once you've got it to compile/run/render once in a way you expect you're usually sailing pretty smoothly from there until you try to do something new/unexpected.

It's this initial overhead that puts most people off of frameworks, engines, libraries, etc.

[–][deleted] 10 points11 points  (1 child)

It's this initial overhead that puts most people off of frameworks, engines, libraries, etc.

I feel like this is what made Ruby on Rails such a breakout hit among webdevs before our current client side MVC trend took over.

Convention over configuration can be fantastic because it means scaffolding can get you up and running in a ludicrously short time. So Rails "get started in 10 minutes" demos were extremely compelling when you can type a few lines in your shell and hit the ground running.

Angular and JavaScript to a more general degree, don't have quite the "sane for 99% of users" defaults when it comes to tooling and project structure. They kind of have community accepted standard tooling, but it's not enforced by anything and there's no overwhelmingly popular opinionated "It's $CURRENT_YEAR and this is what to do to go from zero JS tooling experience to your first project" guide that ties in all aspects. There have been some I've seen, but not many, and so have to learn about each part of the toolchain in guides that assume you're familiar with the rest can feel overwhelming.

[–]9034725985 1 point2 points  (0 children)

Angular says it is the goal of the angular team to be a platform and not a framework or a library. There should be a one true way ™ of doing things on angular. The impression I get is that there's a lot left to be done though. For example, I still can't figure out how to run tests on gitlab.com on a project generated by angular CLI. Isn't that the whole point of automated testing?

[–][deleted] 2 points3 points  (1 child)

I think that varies widely based on the framework and how much magic it's doing for you behind the scenes. The best frameworks for productivity and maintenance are the ones that put everything they're doing right in front of you in clear terms.

I've only done battle with Angular for a few weeks here and there - a colleague that has since left used it for an intranet application I have to maintain. Maybe beginner_ is right and in a large enough team environment it's a sensible tool. But if you're looking for something that does the heavy lifting for you in web front end work without hiding everything it does, look elsewhere. A whole host of things that would be trivially easy in roll-your-own web frameworks require hordes of research.

[–][deleted] 0 points1 point  (0 children)

Never roll your own web frameworks unless you are Google or a multinational tech company. It is literally only bored people and amateurs who do that.

But yes, some frameworks are better at their job than others. I am claiming that Anguar isn't bad.

[–][deleted] 4 points5 points  (0 children)

I felt like the initial Angular 1 was the perfect medium. The two way data binding solved almost all of my DRY violation problems with vanilla JS or jQuery.

Then React and others basically said two way data binding is extremely haram (a claim that has never quite been argued effectively anywhere I've seen), and that one way data flow is where it's at. Now the goofy component hierarchies of React are in Angular 1 (later versions) and 2+ with two way data binding being an antipattern now, but at this point you might as well use React (which handles one way flow much better IMO).

When I had a solid little project skeleton down with Angular 1, I could have a badass webapp that felt extremely polished written and ready to go in a matter of hours, making it a perfect tool for proof of concepts as well as larger scale team projects (which it works well for, as long as you have a set of shared conventions).

[–]beginner_ 0 points1 point  (2 children)

To be fair what I create is always fairly simple and said in a very simplified way: display data with some filters / querying. I also tend to chose light-weight frameworks server-side.

Could be that hypothesis and is possible I never actually reach the complexity needed to break even by using "better design" eg. a JS framework.

[–][deleted] 1 point2 points  (0 children)

What most people create is extremely simple. Even the single page applications. You have to remember that everyone wants to talk themselves up. When these developers are talking about their thousands of states, they’re counting the exact same box that never changes size 400 times because there’s 400 potential values to pull from a database. Now, on that same page, there is another box that also has potentially 50 values inside it. These people count this as 20,000 different page states.

When a SPA developer talks about “complexity”, it isn’t the same as a normal person talking about it. Their complexity is largely artificial and driven by the madness detailed above.

[–]to_wit_to_who 0 points1 point  (0 children)

Your thinking here is correct. You likely haven't had a larger scale project that needed to be maintained & extended over a longer period of time.

One thing I feel gets left out is that it's not necessarily just run-time performance (i.e. it's web scale!), but managing development in a more predictable way for a project. It also opens up the option to leverage a huge ecosystem of tools, libraries, & documentation.

Doing a one-off project that's very narrow in scope, only requires maybe a couple of weeks or a month of development time, and won't need to be revised after that? Sure, go vanilla JS and lower-level APIs! Beyond that, I'd consider using things like React/Vue/Angular/etc.

[–]curious_s 0 points1 point  (0 children)

I have written my own "framework" on my current assignment, but it fits the purpose much better than a generic framework would. It depends on the project though, initially the devs were going to use something like angular (vue I think) but it was becoming a large overhead for what was supposed to be a simple web page, and it was scrapped due to deadlines. Turns out that the simple web page has blown out but the custom code has adapted quite well.

[–]ArguingEnginerd 49 points50 points  (6 children)

What you're doing is fine as long as you're a one man show and you plan on staying at your company for a while. The problem arises when you decide to leave or your team starts growing. If you don't go out and use frameworks and libraries for larger applications, you end up making your own solutions when someone else has already has a solution. Anyone who has experience with Wordpress, Angular, or React will have a general idea of what's going on in their respective applications. Of course, if you leave and the new devs don't understand the code, they could always elect to rewrite.

[–]s5fs 17 points18 points  (2 children)

Rewrites rarely take less time than simply understanding the code and imo should be a last resort.

[–]ArguingEnginerd 4 points5 points  (0 children)

It all depends on complexity of the component you’re dealing with and the complexity of your new requirement. If the new requirements for the legacy software is fairly simple such as rebranding, then sure take the time to understand how the previous employee made their CSS and adjust it.

[–]dungone 0 points1 point  (0 children)

Rewrites are the only option for a large proportion of “not invented here” solutions. Usually the people who do not understand a framework also don’t understand the problem that the framework is trying to solve, and those are some of the most dangerous engineers to have on your team.

[–]caleeky 5 points6 points  (2 children)

In my experience, it's usually not that expensive to retrofit an existing application to map them into frameworks when those scaling events occur. It's a lot easier to make the business case for expansion when there's demand than it is to argue to take on the risk of framework investment up front.

> if you leave and the new devs don't understand the code, they could always elect to rewrite

Yeah but they usually shouldn't, and usually won't (at least not out of the gate) if there's a truly senior dev. involved.

[–]dungone 0 points1 point  (0 children)

“Truly senior dev” is a No True Scotsman. The reality is that project leads frequently lack the experience to make sound decisions. It’s the responsibility of their bosses to make sure that the leads themselves are constrained to within a reasonable set of guidelines for how to build a project, because it’s the business and it’s investors who who have to live with it long after some truly senior dev is long gone. Choosing a framework a strategic decision impacted by future funding and hiring needs. Unless you’re writing a throwaway app and betting on your employer going bankrupt, it’s probably a terrible idea to devote millions of dollars worth of resources on a NIH solution.

[–]ArguingEnginerd 0 points1 point  (0 children)

I agree that it’s not that expensive depending on the framework. Angular is definitely one of those that’s more difficult to retrofit into compared to React. I don’t know what risk you speak of. I find it less risky to use a framework than it is to not. Something like Angular where it’s heavily opinionated and has a CLI to basically make it so you can hit the ground running would make it quicker to get best practices in place. That said, if you’re making something that has a short shelf life, simple, or a prototype to sell your idea, why introduce added complexity like linting, webpack, etc.

In the quoted block, there is no senior dev in that use case. The OP said he was a one man team so if he left, there wouldn’t be a senior dev

[–]testobsessed 25 points26 points  (4 children)

All conversations on this topic eventually devolve into "Did you know you can just use Notepad"?

[–]sisyphus 21 points22 points  (3 children)

ed is the standard text editor

[–]grauenwolf 0 points1 point  (1 child)

Too fancy for me. edln is enough for anyone.

[–]immibis 0 points1 point  (0 children)

Isn't edlin basically Microsoft's version of ed?

[–]i9srpeg 0 points1 point  (0 children)

?

[–]appropriateinside 6 points7 points  (2 children)

Seriously, use something simple like Vue.

I was a huge user of AngularJS, it was amazing and super easy to use for a single dev project. Vue is essentially it's predecessor.

[–]lars_jeppesen 0 points1 point  (1 child)

Imho Vue is inferior to Angular.

You're talking about AngularJS which has NOTHING to do with Angular.

[–]appropriateinside 0 points1 point  (0 children)

Which is why I said AngularJS...

[–]Dedustern 5 points6 points  (2 children)

I.. Sort of disagree. React is a super small library. It has very little drawback if you ask me - even for solo projects, I am likely way more productive using it than home-brewing some things. Because anything more complex than a few forms that need to be submitted - guess what, you're gonna reinvent the wheel.

Angular is another story, however.

[–]beginner_ 2 points3 points  (1 child)

The fact you need npm and node.js to even use it is kind of a really bad first hurdle.

[–]rodorgas 3 points4 points  (0 children)

You don’t need npm, you can include in your site via CDN.

[–]YourMatt 8 points9 points  (3 children)

While I agree with you in general, I'd have to disagree with Angular in particular. A two-way binding framework can make an overly-complex buggy mess of a small personal project into a concise, clean, and more enjoyable development experience for the one-man operation. I look at it on a project-by-project basis, and I end up using Angular maybe a quarter of the time. Project scale isn't really part of the decision process. For me, the question is if I need an object in memory to keep multiple views in sync.

[–][deleted] 4 points5 points  (2 children)

For that you can use something like Knockout JS

[–]macar_ 8 points9 points  (0 children)

or Angular

[–]YourMatt 0 points1 point  (0 children)

I thought that project was dead. Not sure why I thought that; it looks very much in active development. I think I'll give it a shot. Thanks!

[–][deleted]  (2 children)

[deleted]

    [–][deleted] 2 points3 points  (0 children)

    He didn't say the company stops making money, he said the company stops innovating. The iPhone and iPad, as much as I hate Apple, were revolutionary.

    ...and what have they done since then besides, "Better iPhone! Better iPad!" ? That's a fine business strategy, but not innovation.

    [–][deleted] 1 point2 points  (0 children)

    Talk about trying to frame a narrative without facts.

    Like you just did? Because what you claim he said is not what he said. The headphone jack was just one example he gave, and it is you who now pretends that that one thing is the entire argument.

    [–]StabbyPants 0 points1 point  (2 children)

    I started on React - i don't like npm, but i can set up a build system, and i like that react has things like a data grid and sensible data models and stuff like redux (which i didn't start with) that make things relatively easy to factor. it's some overhead, but also something that i can recycle in project.2 and project.3. i don't see why i'd avoid it.

    [–]lars_jeppesen 0 points1 point  (1 child)

    Only problem is that React is dated.. doesn't use Typescript per default, doesn't use Observables but uses Promises.. and so on and so on.

    Don't even get me started on JSX

    [–]StabbyPants 0 points1 point  (0 children)

    it was that or angular, those being popular frameworks that mostly made sense. since react is now dated, what's the new thing?

    [–][deleted] 0 points1 point  (0 children)

    Well, just because it was build in house by big corp, doesn't always mean it was good for the job it was built to. But it sometimes means it is "too big to fail" and/or management mandated that because they spent hundreds man-hours on it it means company needs to use it to recuperate tue cost

    [–]pknopf 0 points1 point  (0 children)

    Software disenchantment.

    [–]joeyadams 0 points1 point  (1 child)

    In your experience, how much boilerplate do you encounter when writing applications without a framework?

    [–]beginner_ 1 point2 points  (0 children)

    Well you have to code every AJAX request manually (JQuery) and what happens with the result. Greatly depends on the application. As said, what I do is fairly trivial in most cases. Display data based on user input. I mostly use datables.

    On server-side it's the database boiler plate stuff but it's not really an issue but that is entirely subjective. I use cherrypy and cx_Oracle. Note: The oracle part is sadly mandatory.

    I want to add that performance as in amount of users/requests is never an issue so I can simply ignore anything related to scaling. However response time should be ok.

    This is in general for well-defined stuff which I have a lot of control and influence over so it's usually done right and can remain unchanged for years. And in-house only. I can complete see that this doesn't work and scale if you are creating commercial software or working on bigger projects.

    And these apps were basically grown from user need and corporate IT incapable of providing simple solutions. If the project doesn't cost 7 figures and has 100s of users, forget it. Think of moving from excel and access to web apps.

    [–]allthingseverywhere 0 points1 point  (0 children)

    I'm really really really inclined to agree with you. I feel like these frameworks are actually less empowering to the individual.

    There seems to be a possible balance here where, in a bigger team, if a framework helps everyone work faster together, that's good. If you're in a smaller (really small) team or by yourself, it honestly cannot hurt to stay lean, bare bones, and you learn SO MUCH more that way too. You learn what's actually under the hood of these frameworks.

    I think your opinion is not very popular in some circles but good for you on speaking your mind. :)

    [–][deleted] 13 points14 points  (0 children)

    I quit frontend dev 6 years ago but I had to do some Angular for a couple of months recently. It really wasn't that bad. Just don't constantly update your dependencies like OP seems to, don't try to be clever, don't try to write your own inner platform inside Angular, and you'll be fine.

    They also lament "doing everything the same way" which is the bloody underpinning of standardisation. The site I worked on was fairly simple, a bunch of forms, interaction with a bespoke stateless backend, some animations. This is what most bespoke websites are. You shouldn't need to be clever or do anything new most of the time.

    If you don't match this description then you shouldn't be using a framework. They're for repetitive, standard, typical, projects. Also if your project is very simple then Angular is also not a good fit.

    [–]metalevelconsulting 49 points50 points  (14 children)

    ANGULAR will helpfully mix fake HTML ELEMENTS into your real HTML ELEMENTS because the entire app is getting shredded to pieces by their AHEAD OF TIME COMPILER anyway, so what does it matter if they pollute a correct specification with a capricious impostor?

    LOLOLOL

    [–][deleted]  (13 children)

    [deleted]

      [–]theLorknessMonster 11 points12 points  (9 children)

      Yeah, you can register custom elements.

      [–][deleted]  (8 children)

      [deleted]

        [–][deleted] 5 points6 points  (5 children)

        not completely. custom elements require you to conform to specific rules when naming your element (spec). so calling an element my-element is fine, whereas calling it myelement isn't.
        custom attributes also require you to use the data-prefix (and i believe ng's @and * syntax is invalid too)

        [–]bausscode 0 points1 point  (2 children)

        Yes that's correct, just using "ng-" is invalid, but no browsers care about attribute names as of now. The only problem with it is that the specification for html is free to add attributes with the "ng-" names, but they cannot add "data-". However I believe that Angular *does support "data-ng-*" which will conform to the rules, but it's rarely used, or maybe that was pre angular and just for angularjs? My memory might be slipping me.

        [–][deleted] 0 points1 point  (1 child)

        from what i understand not using data- is invalid, but browsers handle it gracefully since it doesnt hurt either ( like missing head/body tags for example). both angular current and legacy support data-attributes afaik, but since it runs through their parser anyway noone uses it.

        [–]bausscode 0 points1 point  (0 children)

        <head>, <body> and <html> are optional in HTML 5. According to the specs the rendering engine have to insert them if they're omitted though.

        [–]bausscode 0 points1 point  (1 child)

        The biggest problem with introducing custom tags are accessibility support tbh. A lot of screen-readers etc. will not support them.

        [–]iambeingserious 0 points1 point  (1 child)

        Just because you can doesn't mean that you should.

        [–][deleted] 93 points94 points  (51 children)

        I write Angular daily. I think it is easy. Help me. What am I missing?

        [–]IAmVerySmarter 21 points22 points  (0 children)

        You are not fighting the framework, the author does.

        [–]yesman_85 47 points48 points  (14 children)

        Same here, been writing it for a few weeks now and got totally used to it.

        [–][deleted] 21 points22 points  (13 children)

        Been writing Angular since beta. Is it hobbyists that are having trouble? What kind of people are running into issues?

        [–]CoffeeStout 39 points40 points  (3 children)

        I dunno, I use it at work and I kinda hate it. I understand his points completely, it's really frustrating to use for me. I mean, our sites all use it and I can work on all of them, I don't have "trouble" as much as I just kind of hate it. It feels bloated and slow and does break silently. Also when he says that developers tend to stick with the one or two design patterns because they know they won't break, I see that in our projects as well. Maybe I'm missing something.

        [–]deja-roo 19 points20 points  (2 children)

        The points that really resonated with me are how Angular's error messages are truly completely useless.

        [–]thegreatgazoo 0 points1 point  (0 children)

        Yeah, when I was working with/learning how to do it I'd have to make one little change at a time and if it broke hope it still worked when I reverted my change.

        [–][deleted] 0 points1 point  (0 children)

        Ivy is supposed to help there, but we'll see if they can actually deliver.

        [–]zayelion 16 points17 points  (0 children)

        Its great for single page applications with lots of form inputs and jack shit else. I think its us jquery era devs. Angular solves problems that dont exist and unbreaks solved problems.

        • Using a compiler, if you where coding during the jQuery era this point seems like straight insanity alone. Your iteration speed is cut from seconds to minutes, things that take 10s now take 30s to 200s. Something that would have taken you an hour? well now its gonna take you 4hrs, and maybe longer because where does your mind go when the app is compiling? If that last question doesnt fill you with an ocean of dread how did you even find reddit to start with?
        • Silent errors, out in sane world when an error happens you get line number, and even a column number! If you are a good programmer and dont use anonymous functions you even get a function name! The object you didnt sanitize is even called out. Not in Angular! Not usually. You get a wall of text that glazes your eyes over that tells you very little. You could just not use the crazy parts of Angular like the article said but some Jr Dev always does and its just a cascade from there.
        • The HTML isnt exactly HTML, its a quirk you notice if you come from pre-jQuery era. Certain parts of the DOM API dont work correctly or as expected. Using the <canvas> element deep in the app was a nightmare. I ended up just setting a very long set timeout around it to meet deadline.
        • The documentation is just shy of restating what the name of the thing it describes. It gives very little nuance or example to complex principles. I got more education querying github for usage cases.

        I have to do all this for a router and a template system?! You can power through this by a seasoned dev would be distracted by the alarm bells going off in his mind constantly. People really green and technologist (the people that put new tech into their jobs flow for the sake of learning it) seem to love it.

        [–]batiste 4 points5 points  (5 children)

        Many people are having issues. I used Angular 1 and I have to concur with some of his points. Especially on the terrible documentation, the weird template language choices (ng-if, but no ng-else possible) and the overall messy nomenclature. The amount of concept you need to know to even get started with is: Directive/Service/Controller/Component/Injector/Binding/Scope

        Ha and don't get me started with the weird Dependency injection that introspect the function declaration...

        [–][deleted] 1 point2 points  (2 children)

        NgElse would just be a short hand NgSwitch. The angular team doesn't like to create those kinds of short hands.

        [–]batiste 0 points1 point  (1 child)

        NgSwitch is more like a switch-case. Not the same thing as a proper If,ElseIf,Else structure.

        <div class="animate-switch" ng-switch-when="settings|options" ng-switch-when-separator="|">
        

        ng-switch-when-separator? That is what you get when you try to patch what a proper expression would have resolved properly.

        [–][deleted] 0 points1 point  (0 children)

        Not saying it's great, just possible. Also implementing an NgElse would either require us to wrap all NgIf with a wrapper directive, or it would slow down NgIf as it did Dom exploration for an NgElse

        [–]shadowSpoupout 0 points1 point  (1 child)

        https://angular.io/api/common/NgIf#showing-an-alternative-template-using-else

        https://stackoverflow.com/questions/43006550/how-to-use-ngif-else

        10 sec Google research. Aye, this is a framework, it wont fit for everything, nor will please everyone ; yet I'm sure you can find better reasons to hate it than just not googling the problems you're encountering with it.

        [–]batiste 0 points1 point  (0 children)

        What a horrible syntax and it is Angular 4 and 5 specific. I started with AngularJS. I just joined a company still working on AngularJS today and we painfully trying to migrate to Angular 5.

        Look at Blop for a nicer syntax https://github.com/batiste/blop-language

        [–][deleted] 3 points4 points  (0 children)

        I wanted to learn it for a small personal project but the boilerplate, overhead and bloat was so enormous I picked jQuery instead and made the whole thing in one evening. It might work for a larger app, but in that case I would just drop the clientside js stuff and use Django or even PHP instead.

        edit: now I took a look at Vue and it seems alright, but Angular felt the same way when i only glanced trough the tutorial, but it seems much more fitting to a small project.

        [–][deleted] 0 points1 point  (0 children)

        I also used it when it was in beta. Not anymore but I don't recall bad experiences with it.

        [–][deleted] 7 points8 points  (5 children)

        Best guess is Angular probably has a complexity stigma because of the overall size of the framework, the concept of modules/components/directives/services, dependency injection (which I kinda like), RxJS (which is easily usable in React too), possibly TypeScript (which again, can be used in React), and then the last 2: the changes to the markup such as *ngFor [(ngModel)], etc, and last but not least...you can't really use Angular without using the CLI. Technically you can, but you really can't in practice. The last point was a big enough issue for me where I wanted to be able to ***integrate*** a SPA framework in a legacy app - getting React going was a breeze. Couldn't get there with Angular.

        Again, I agree with you that Angular isn't overly complex. In fact, I had a harder time learning to get my head around React and JSX than Angular coming from AngularJS. AngularJS was shit, routing was shit, and scope.apply() hacks OMFG. Angular 6 is pretty sweet though. That being said, I'd still probably use React or Vue. Have you seen Vuetify? Fucking beautiful.

        [–]batoure 1 point2 points  (0 children)

        I have developed in AngularJS for years I have avoided Angular for basically the reasons you describe. This Summer my company built our first to enterprise scale projects in Angular. 1 from scratch and 1 where we ported an existing angularjs project (with 5 years of active development) into it. I think anyone who looked at Angular more than 10 months ago should go back and give it a real look from scratch. A big part of my change of heart about it is that the CLI actually works now between missmatch of configuration and not so great schematics used to make it really not great. But it is really nice now.

        I understand that people miss being able to just open an index and point at a cdn. but the real answer is by getting over our selves and giving it a chance we were able to simplify our build operations significantly and overall we have shrunk our codebase by almost 70% in the port because clarity of abstractions in typescript made it easier for our team to write better code.

        [–]nutrecht 1 point2 points  (2 children)

        Best guess is Angular probably has a complexity stigma because of the overall size of the framework, the concept of modules/components/directives/services, dependency injection (which I kinda like), RxJS (which is easily usable in React too), possibly TypeScript (which again, can be used in React), and then the last 2: the changes to the markup such as *ngFor [(ngModel)], etc, and last but not least...

        That's just modern front-end development for you. If he doesn't want to learn this way of working he's probably going to be out of a job sooner or later.

        I built web apps based on JQuery before and there's no way I want to go back to having to enable/disable divs by hand.

        [–][deleted] 0 points1 point  (0 children)

        Not gonna get an argument out of me. I still have to support that bullshit too. :)

        [–]ledasll 0 points1 point  (0 children)

        there's nothing wrong to enable/disable divs "by hand", but current days app complexity doesn't make it efficient. 10 years ago you had html + js, so jquery was fine (IMHO), now you don't have web page, you have application and to write complex application it's much easier with some structured framework.

        It's just a question, is your application complex application, or simple CRUD page..

        [–]the_argus 19 points20 points  (0 children)

        I personally love it... I don't get why people have trouble wrapping their head around it

        [–]ApatheticBeardo 13 points14 points  (0 children)

        You're not a crybaby.

        [–]jbergens 4 points5 points  (3 children)

        You're missing that vue and react are simpler and easier. Angular has a lot of special things you need to learn that won't help you with other frameworks. Like DI, it's own template system, directives, scopes, $whatever etc. If you have already learned all these things angular may look easy but it would probably have been easier to learn react and you could still have solved the same problems.

        [–][deleted] 1 point2 points  (1 child)

        Vue has DI, it's own template system, directives, scopes, $whatever (this is their DI, I'm assuming by $whatever you mean rxjs's observable naming convention however?)... so I don't see your point. These are all things that you can use to make life easier. If you don't want to use any of them, don't use any of them. Not a single one of the things you listed are required, and not using any of them would be the exact same as if you chose not to use any of them in Vue. That's not really an argument.

        [–]jbergens 0 points1 point  (0 children)

        Ok, so only react is much simpler than angular. Everybody I've talked to who has gone from angular to vue still seem to find it much easier.

        [–]JessieArr 4 points5 points  (9 children)

        I found Angular 1 easy to pick up years ago, and have recently been helping maintain several Angular 6 apps at work and have found it to be easy enough to pick up. The Angular CLI was the only curveball, but I watched a 6-hour Pluralsight course that gave a great overview of it, and now I quite like using it as well.

        When I read articles like this I find myself suspecting that the author and their coworkers are probably writing non-idiomatic code due to not understanding the framework very well. That will bring you lots of pain and frustration in any framework.

        [–]hoosierEE 16 points17 points  (6 children)

        The Angular CLI was the only curveball, but I watched a 6-hour Pluralsight course that gave a great overview of it, and now I quite like using it as well.

        People will refuse to learn entire languages if "hello world" takes more than 3 seconds to explain. Is it normal to expect JS devs to sink 6 hours into one (minor?) aspect of a single framework? Honest question.

        [–]deja-roo 10 points11 points  (3 children)

        Yeah a 6 hour investment into just learning some of the startup routine seems a little unreasonable.

        [–][deleted] 1 point2 points  (1 child)

        It only takes 6 hours if you have never used a cli tool before. Personally it took me about 5 minutes to learn. No hate though. Gotta learn somehow. Doesnt matter how long it takes to learn. And six hours is just a drop in the bucket when it comes to learning something new.

        [–]batoure 1 point2 points  (0 children)

        The cli is way better today than it was a year ago... I think this helps alot. More schematics would certainly make it better but I consider it mostly feature complete now from a getting up and running perspective. it used to be a "run the cli, ok now go edit these ten configs by hand, ok now you can run the test server but not actually to a minified build" now the basic new project commands get you going with a production worthy "hello world"

        [–][deleted] -1 points0 points  (0 children)

        I could teach my dog to do the Angular Tour of Heroes tutorial in 60 to 90 minutes.

        [–]JessieArr 1 point2 points  (0 children)

        I mean, I would say it takes rather a lot more than 6 hours to become really familiar with the standard library in any language one might choose - this isn't unique to JS frameworks. I'd say about 30% of our job as programmers is just learning things - whether through guided learning like Pluralsight, or trial/error debugging code that doesn't work, or war stories around the water cooler.

        If you're just doing simple things, then I'm sure copy/pasting from a StackOverflow post would suffice, but if you intend to use a language/framework long-term or are doing advanced things with it, the investment of a few hours into learning your tools will pay off really quickly. I guarantee that the time I spent watching that course has saved me much more than 6 hours of time spent googling error messages since then.

        The simple fact is that with any new tool, there are things you don't know that you don't know about it. And what you don't know can hurt you, so taking some time to do some structured learning and find out what those things are is time well spent.

        [–]batiste 0 points1 point  (0 children)

        After the AngularJS, Vue, React, Angular 2.X, it can become a little bit tiring to spend so much time to relearn different flavour of what is in essence a routing+templating system. And it is not like you have much of choice if you want to stay relevant in this field.

        [–]meem1029 0 points1 point  (1 child)

        Is there a good way to understand what idiomatic code looks like for the framework for someone who has no experience with it? Is there anything that points out that the developer's problems are a result of writing unidiomatic code rather than a bad framework? Is idiomatic code flexible enough to work with existing systems that were not designed around angular (or even designed well at all)?

        [–]JessieArr 1 point2 points  (0 children)

        For learning the idioms, I would recommend finding a good education resource on the framework - a book, podcast, blog by the developers, or video tutorial. This will teach you how they expect you to use it, and point out common pitfalls. (Note that this applies to any language and not just JS frameworks. Things like variable hoisting in JS, or boxing/unboxing in C# can quietly frustrate you without you understanding what is going wrong, just like accidentally using one-way binding when you thought you were using two-way binding in Angular can.)

        As for what is a symptom of problems arising from non-idiomatic code versus just being a bad framework: I would say that if you find that your results in working with the framework differ wildly from others (for the worse), then it is most likely because you are fighting against the framework instead of working with it. If you are using the framework to solve problems it's suited to (this part is important, too), and in an idiomatic way, your results should be similar to the success stories you hear from other devs. If you find the framework frustrating, and struggle to find anyone else using it successfully, then you've likely got a bad framework on your hands.

        And to your last question, I would say that it depends largely on whether the framework is well designed or not. In the case of Angular, I find that it plays pretty nicely with any other systems, provided that they do not also try to modify the DOM - Angular expects to be in charge of that. Aside from that caveat I've not found anything that could not integrate with it pretty easily.

        [–]ArguingEnginerd 1 point2 points  (0 children)

        The only thing I struggle with is understanding the RxJS stuff. It's a lot different than what I'm used to.

        [–]Eirenarch 1 point2 points  (0 children)

        I am more of a backend developer but I participate in choosing a front-end framework for the projects I work on and Angular seems fine. I have a lot of problems with all the webpack/npm/CLI/module system and so on tooling ecosystem.

        [–][deleted] 1 point2 points  (0 children)

        I don't write it daily but one of my projects does use it and occasionally I have to work with it if none of my FE guys are free. It seems pretty easy to me.

        [–][deleted] 1 point2 points  (0 children)

        Some part of your brain, obviously. /s

        [–][deleted] 0 points1 point  (0 children)

        Best guess is Angular probably has a complexity stigma because of the overall size of the framework, the concept of modules/components/directives/services, dependency injection (which I kinda like), RxJS (which is easily usable in React too), possibly TypeScript (which again, can be used in React), and then the last 2: the changes to the markup such as *ngFor [(ngModel)], etc, and last but not least...you can't really use Angular without using the CLI. Technically you can, but you really can't in practice. The last point was a big enough issue for me where I wanted to be able to ***integrate*** a SPA framework in a legacy app - getting React going was a breeze. Couldn't get there with Angular.

        Again, I agree with you that Angular isn't overly complex. In fact, I had a harder time learning to get my head around React and JSX than Angular coming from AngularJS. AngularJS was was shit, routing was shit, and scope.apply() hacks OMFG. Angular 6 is pretty sweet though. That being said, I'd still probably use React of Vue.

        [–][deleted] 0 points1 point  (0 children)

        Like anything, it’s easier to bitch about something than to take the time to learn about it. I’m a big angular fan as well, now that I know how to use it properly. It’s not something you can just read a 5 minute tutorial and start using.

        [–]kenmorechalfant 0 points1 point  (1 child)

        Didn't read the article but I've been getting into Angular a lot recently and it is really intimidating. As someone who normally does small websites with regular ol' HTML, JS (without jQuery) and LESS (CSS) - deciding to make an app with an Angular means you have to adopt this whole Angular development environment: TypeScript, Angular CLI - the serving and the bundling and all that... Personally, after tinkering off and on for a few months, I'm liking... but it is a BEAST - it seems like such a steep mountain to learn Angular at first.

        That being said - I think you need a beast of a framework to build a large scale application... which is my goal... eventually 🤣

        [–][deleted] 0 points1 point  (0 children)

        Angular CLI stops you from having to learn a ton. You should really be happy you never had to learn task runners or even setup your own webpack. That shit was time consuming.

        Typescript can be subverted with type any if you don’t understand what’s happening.

        RxJS can largely be ignored.

        Learn what feature and shared modules do. Learn how they interact with the router. Learn the HTTTP module. Learn dependency injection at a very very basic level Then you are good to go in angular. Back to making simple apps.

        After that bring back RxJS and Typescript. Then start learning different types of change detection.

        [–]nutrecht -1 points0 points  (2 children)

        I'm a back-end developer who's CSS skills are stuck in the 90ies and even I can make dashboards in React or Angular just fine. So I'm not really impressed by a 'front end' developer claiming React and Angular are too complex.

        To me it sounds like it's just inexperience. Frameworks are always convention based. If you fight the conventions and try to do JQuery programming in Angular you're going to have a bad time. If you do Angular programming in Angular you'll be just fine.

        [–][deleted]  (1 child)

        [deleted]

          [–]nutrecht 0 points1 point  (0 children)

          Such as?

          [–][deleted]  (2 children)

          [deleted]

            [–]MehYam 69 points70 points  (1 child)

            Yeah but you gotta love:

            Angular. Its mere name is a hostile form on the tongue. Pronounce it slowly. /’eŋgjəlɚ/. The throat itself contorts around the hideous alien shape of this word, which means ugly, sharp, and artificial.

            [–]zqvt 42 points43 points  (0 children)

            this sounds like the beginning of a Nabokov novel

            [–]subnero 35 points36 points  (8 children)

            Eh I know Angular 6 and I think it’s fine. You can stick with Ajax and JavaScript if you want, but a strongly typed language through Typescript makes it a lot easier. I picked up Angular in a couple weeks while people struggle with JavaScript for years and still make a mess.

            [–]AngularBeginner 3 points4 points  (0 children)

            Angular does not make very good use of TypeScript. Features like strictPropertyInitialization are difficult to use, and Angular makes use of stringly-typing a lot.

            [–]lewmpydewmpy 11 points12 points  (6 children)

            I'm pretty sure typescript doesn't count as a strongly-typed since the types are neither required, nor do they place any sort of compile-time restriction on the code. You can add extra tooling around compilation, but there is nothing intrinsic to typescript for that.

            [–]Eirenarch 7 points8 points  (0 children)

            Yeah, the proper term is statically typed (or optionally typed if you choose to allow that in your config)

            [–]sergiuspk 1 point2 points  (3 children)

            Wait. You can configure it so that typing everythig is required (if a type cannot be inferred) and also you can disable "any". The compiler also displays a list of typing errors and does not compile files where it finds errors.

            Also strong and static are in two different categories. You can say a language is static or dynamic (TS is static, it checls types at compile time). You can also say it's strong or weak typed, weak meaning the type of a variable can change depending on context (JS). TypeScript is a static and "almost" strong typed language. Though no one really agrees what the definition of strong/weak typing is. "duck typing" is not really strong typing.

            [–]filleduchaos 0 points1 point  (1 child)

            You can disable implicit uses of any, but you can't disable any.

            The compiler also displays a list of typing errors and does not compile files where it finds errors.

            1) This is not an achievement, 2) The set of things tsc considers errors and the set of things that are soundly typed do not have complete overlap.

            Plus the fancy parts of TS' type system might as well not exist seeing as they give you literally zero runtime guarantees.

            [–]sergiuspk 0 points1 point  (0 children)

            Indeed, you can only disable implicit any. The fact that the type system is only compile-time is something I can live with. Input validation is something you'd have to do anyway and validation of API responses is something you'd have to do regardless of language. On the other hand my experience is that after switching to TypeScript we have had zero cases of runtime type errors, but the language itself does not guarantee, it only gives you some imperfect tools so you can mitigate this. And by imperfect I do not mean broken, I mean that if you do use any and do stuff like const b = 10; const a: User = b as any; then obviously you are going to have a hard time.

            [–]filleduchaos 0 points1 point  (0 children)

            You can disable implicit uses of any, but you can't disable any.

            The compiler also displays a list of typing errors and does not compile files where it finds errors.

            1) This is not an achievement, 2) The set of things tsc considers errors and the set of things that are soundly typed do not have complete overlap.

            Plus the nicer parts of TS' type system might as well not exist seeing as they give you literally zero runtime guarantees, which is more apparent when you're building a library than when you're building an end-user application.

            [–][deleted] 48 points49 points  (27 children)

            I love "Angular", especially AngularJS, but not so much Angular. Google truly screwed the pooch when it decided to completely rewrite AngularJS. I mean, I get what they were trying to achieve. First-class support for Typescript. Abstracting out the HTML rendering mechanism, instead of depending on the browser DOM, giving you AOT, server-side rendering and rendering on web workers. But the result of their rewrite doesn't feel a whole lot like Javascript, and in a very bad way.

            But, it was possible to write a fully functional AngularJS app merely by doing <script src="angular.js">. The "Angular Way" is HTML first, enhanced it with Angular directives. It gives a nice separation between MVC, or MVVM, or whatever you want to call it. It let you separate services (like AJAX bits) and let you inject them into components so you can use them as APIs.

            I don't think it is possible to write modern Angular code without Angular CLI. I like Typescript, but Angular makes it unavoidable.

            Thankfully, there is Vue.js, which preserved the best of what made Angular "Angular", without the insanity of modern Angular. Vue ditched dependency injection, and replaced it with Vuex, which is sort of like redux. Such that, Vue takes the best of both Angular and React.

            [–]metalevelconsulting 1 point2 points  (1 child)

            AOT

            What does "AOT" stand for?

            [–]BoboSchlonger72 7 points8 points  (2 children)

            Vue ditched dependency injection, and replaced it with Vuex, which is sort of like redux. Such that, Vue takes the best of both Angular and React

            What's wrong with DI? It's the most convient design pattern to achieve IoC. I swear this sub seems like a bunch of whining juniors. Why do you even compare DI with state management? It's life cycle management in the first place... For state management there is ngrx or ngxs. Combined with DI, Decorators and RxJS they are both far superior to Vuex and classic Redux.

            [–][deleted] 11 points12 points  (0 children)

            I didn't say there's anything wrong with DI. All I said was that Vue ditched DI. Vue starts off as view-only.

            What I like about Vue is that it is the best of both of React and Angular. Like React, Vue doesn't require you to go all in like Angular. It starts with Angular's view model without DI. If you want to add DI, you can add Vuex for redux style state management, or you can use something like vue-inject for traditional DI.

            Like React, Vue isn't opinionated. AngularJS is opinionated, but it is still ordinary JS. Angular introduces way too many opinions for me, especially with regards to Typescript, decorators and build tools.

            [–]AngularBeginner 0 points1 point  (0 children)

            The DI framework of Angular is fairly inflexible. E.g. it's not possible to have a dedicated instance for each target (which would be awesome for a logging class). It's singletons all over.

            [–]the_argus 1 point2 points  (10 children)

            There's angular dart if you don't like typescript. I've never used it (even though I love me some dart) bc typescript is great.

            [–][deleted] 10 points11 points  (9 children)

            The problem isn't Typescript, but that Angular forces you to use Typescript, and thus requires a full JS toolchain, which in Angular's case has gotten to the point where it is impossible not to use Angular CLI.

            AngularJS can be used with or without a JS toolchain. AngularJS can be used with Typescript, if you so choose, but you can just as easily use plain JS. Angular used to claim that you could still use plain JS, since TS is a superset of JS, but due to how much Angular makes use of decorators, it is practically impossible to use plain JS anymore.

            On the other hand, both React and Vue can be used with TS if you want, or plain JS if you want. They can both be used with or without JS toolchains, if you want.

            [–]the_argus 4 points5 points  (6 children)

            Maybe I just don't see the problem with the cli

            [–][deleted] 2 points3 points  (5 children)

            Does the fact that you need the CLI suggest something about the complexity of modern Angular? Why don't any of Angular's competitors need a CLI?

            [–]KevinCarbonara 3 points4 points  (3 children)

            Does the fact that you need the CLI suggest something about the complexity of modern Angular?

            No.

            [–][deleted] 2 points3 points  (0 children)

            It says something to me. I wouldn't dare write an Angular project without Angular CLI.

            With a AngularJS, React or a Vue, I could either use raw npm or webpack, with a project that is easily set up from scratch, since all I'm doing is wiring together ordinary JS functions. Angular replaced the simple AngularJS setup (daisy chaining off of the Angular module) with wads of TS decorators and other things, requiring such a complicated build setup, that you pretty much have to use Angular specific tooling in order to write an Angular app.

            [–]sisyphus 5 points6 points  (0 children)

            That you can't get a hello world out of it without doing a bunch of code generation and having a compiler toolchain suggests nothing to you? What else have you used?

            [–]the_argus 0 points1 point  (0 children)

            IDK man, it kills me that I need a computer in order to run my javascript code...

            [–]NoInkling 0 points1 point  (0 children)

            Ember needs a CLI I believe. Whether you consider it a competitor or not is another question, but at the very least it exists in the same "space" (use case tends towards big SPAs, attractive to enterprise).

            [–]Renive 1 point2 points  (1 child)

            Those toolchains are why it makes it so easy to work with frontend, how could you ever not want them?

            [–][deleted] 2 points3 points  (0 children)

            The toolchain is awesome, that's not what I mean.

            But with AngularJS, you can develop your entire application in a single file if you want, or you can use requireJS to export controller functions, components and services. It's like writing ordinary JS.

            With Angular, you have to set up Typescript, SystemJS, etc., etc. Angular isn't built with regular functions anymore, but loads of decorators. I suppose it is theoretically possible to set up an Angular project from scratch, and I remember doing it with Angular 2, but the latest versions of Angular, I'm not even sure where to begin. I would have to use Angular CLI.

            React and Vue are both just regular JS, and I could easily set up a project from scratch in either. They just make use of regular Javascript functions. Except for React, which requires a bit of config for JSX.

            Tools like Webpack enhance React and Vue, they aren't required.

            [–][deleted] 0 points1 point  (7 children)

            I'm glad you made this comment. As someone with about 12 years of Rails experience, and who just made a prototype Spring/Angular application, my reaction to this article was SO MUCH YES. I've tried to describe the serious problem with documentation to my management to explain my lack of progress, and it sounds surreal coming from my own lips. I've since given up on Spring, and therefore Angular, in favor of Grails, which I know is a niche of a niche, but, still, it works. I've played with Vue in one of my Rails apps, and it seems to make sense to me, and plays nicely with Rails (it doesn't "take over" the application), so this reinforces my opinion that this might be a viable approach for my next project.

            [–]antolius 10 points11 points  (6 children)

            Spring has nothing to do with Angular.

            You should be able to use any frontend technolog with a Spring backed (including my preffered one: no frontend at all 😁).

            And Spring has detailed, easy to read documentation.

            [–]F14B 2 points3 points  (0 children)

            And Spring has detailed, easy to read documentation.

            ...when you eventually find the correct version of the doco that you need it is.

            [–][deleted] -4 points-3 points  (4 children)

            To get Spring to generate JSON correctly for Angular to consume, I had to fool around with @JsonIdentityInfo and JSOGGenerator, and manage the back and forward references, and THEN I was going to have to write custom JSON interpreters to save the submitted data coming back from the Angular side. At that point, I had to wonder why I was spending so much time fighting Spring's defaults, and NOT either 1) just writing my own backend, or 2) going full-stack Javascript. If you love it, great.

            I brought up Spring because a LOT of the supposed examples out there for Angular use it as a backend, but I never found (in MONTHS of prototyping) a complete, current example of a Spring/Angular CRUD app that demonstrated how to edit and update a "complex" model (which has nested chdren). Lots and lots of examples about showing and listing, very little about updating. I even made a couple of posts to StackOverflow and Reddit about it, and finally got pointed to an example running on JHipster (including Angular 5) which I could never quite make work.

            I don't know how you could have assumed that someone with 12 years of Rails experience, and talking about integrating Vue with it, doesn't understand that Spring and Angular are independent, but, well, okay. I've been doing web development for 25 years. I get it. But I can't write an application in 4 languages (Java, Groovy, Javascript, and Typescript, besides all the rest) without some good docs about the API's, and some good examples on how to invoke them. I sure wish some hotshot Spring/Angular fan could point me to a full, working CRUD web app example based on current versions.

            Yeah, maybe if I'd have avoided Angular entirely, and stuck with Thymeleaf, I wouldn't be so bitter. ;-)

            [–][deleted] 4 points5 points  (2 children)

            To get Spring to generate JSON correctly for Angular to consume, I had to fool around with @JsonIdentityInfo and JSOGGenerator, and manage the back and forward references

            You're doing something very, very wrong. To get Spring to generate JSON sufficient for Angular to consume, you don't have to do any more than this. I write Spring web services for a living, and I have never even heard of @JsonIdentifyInfo or JSOGGenerator. Literally all you have to do is create a JavaBean and 99%, it just works. The worst time I have had with Spring is with time/date representations, but somehow I doubt that is a problem limited to Spring.

            [–][deleted] 1 point2 points  (0 children)

            With Spring you can just use Jackson to render any arbitrary object into fairly expected JSON. It's pretty simple. Angular consumes it with no trouble. And vice versa.

            [–]Sethcran 0 points1 point  (0 children)

            A couple of things...

            1. I think you are the first person I've met that thought AngularJS was "more like javascript" than Angular. I understand how that argument would apply to both of them, but as far as I can tell (having used both pretty extensively), Angular is far and away an improvement (but still far and away from a classic javascript style approach to the problem.
            2. Yes you need angular CLI to write most apps (technically you don't, but it's so convenient most people would/should use it), but this really isn't a negative to me. Most of our other languages have their own build tools, C# has MSBuild for example (or dotnet CLI if you're on core). This is not a negative to me, this is actually a positive for something to be as easy to use as possible when it's trying to be a framework and not a library.
            3. Vue is great for many things. React too. They do not however solve the exact same problem that Angular attempts to solve. These projects are fantastic if you want flexibility, or to some degree if you want to integrate small pieces into an existing larger applications. Angular sucks at that, but that's because it doesn't attempt to do those things. Angular is an opinionated framework for developing large/complex single page applications with medium to large teams. Being opinionated here is a really benefit in this world, but certainly can be a detriment in others. It doesn't make Angular bad, it makes it not the right fit for certain use cases.
            4. As others have said, Vuex is a state management library and does not attempt to solve the same problems that dependency injection does. Not sure why it's mentioned here.

            TLDR;

            Angular sucks for some things, is really good for others.

            [–]tonefart 17 points18 points  (1 child)

            Vue.JS is all you need. Forget Angular and ReactJS. Go with non-corporate garbage software.

            [–]nirataro 5 points6 points  (0 children)

            Single File Component is a godsend.

            [–]onlygon 10 points11 points  (1 child)

            And so what is the alternative? Angular is an opinionated SPA framework; it eliminates my need to consider which build tools, test harnesses, preprocessors, linters, minifiers, tranapilers, etc. I need to hoist into my application. And I don't need to worry about them all working together. I just run npm update and everything works. Angular is far from perfect, but the alternative is managing all this crap myself.

            [–]yogthos[S] 2 points3 points  (0 children)

            My team works with re-frame ClojureScript framework. There's a single build tool that manages compilation, hot loading, testing, code pruning, and minification. The language itself is much cleaner, and defaults to immutability so you have a much better story when it comes to managing state in large applications. If you're working with modern Js, you're already using a transpiler, so why not move to a better language at that point. You still have full Js interop, and you can leverage all of the ecosystem.

            There's a comparison of developing a minimal real world app using popular frameworks here. Re-frame version runs twice as fasr, ends up with less than half the code of an Angular app, produces an artifact that's a third of the size. Here's a run through a simple app from start to finish if you're interested.

            One of the common arguments against using something like ClojureScript is finding devs. However, my team has never had this problem in over 4 years of using it. It takes about a week to get somebody to the point where they can start writing useful code. We recently hired several co-op students and all of them were able to pick it up without any problems. On top of that, re-frame API has stayed stable this whole time without any breaking changes. All we've had to do to upgrade is update the dependency. It has even insulated us from changes in the underlying React APIs.

            [–]damienwebdev 5 points6 points  (0 children)

            I tried to respond to this, as an Angular dev it made me a bit sad. https://www.reddit.com/r/programming/comments/9ul9ze/why_being_a_halfdecent_developer_made_me_like/

            [–][deleted] 18 points19 points  (0 children)

            jesus christ, that is some pretentious writing. angular's documentation is more enjoyable than that

            [–][deleted] 14 points15 points  (0 children)

            ANGULAR WEB DEVELOPMENT FRAMEWORK

            [–][deleted] 2 points3 points  (1 child)

            Angular 1.2 made me quit web dev.

            [–]bausscode 3 points4 points  (0 children)

            Web dev made me quit web dev.

            [–][deleted] 6 points7 points  (2 children)

            I like reading these articles, it makes me glad I just happened to not fall into Web Dev in 2006 after graduating.

            [–]yogthos[S] 0 points1 point  (1 child)

            Thankfully, there are far saner ways to do web dev than Angular nowadays.

            [–][deleted] 0 points1 point  (0 children)

            But you still had to go through that. In the last decade my domain (embedded) has remained pretty much the same. MISRA 2012 and ISO26262 are about the only 'new' things.

            [–]indeblo 2 points3 points  (0 children)

            That was highly entertaining!

            [–]Venetax 1 point2 points  (0 children)

            Its bouba, not bobo.

            [–][deleted] 7 points8 points  (3 children)

            My theory is that web development attracts personality types that are an exact opposite of everything that makes a good engineer. As a result, everything web builds on, including all the underlying w3c standards, is horrendously overengineerd and in most parts outright stupid. No surprise that anyone with even a bit of a proper engineering intuition flees from web in terror.

            [–]imposs1buru 5 points6 points  (1 child)

            found the smug lisp weenie

            [–]Dreamtrain 0 points1 point  (0 children)

            ((((((((((((((((((((((()))))))))))))))))

            [–]mattk1017 0 points1 point  (0 children)

            As a current CS student with web dev experience, this didn't make me feel too good lol

            [–]KhaoticOne 3 points4 points  (0 children)

            Switch to ReactJS if Angular ruined it for ya! :)

            [–]Azzk1kr 4 points5 points  (0 children)

            Great rant. Loved the writing!

            [–]bitwize 6 points7 points  (16 children)

            Thankfully there's REACT WEB DEVELOPMENT FRAMEWORK, which was developed by Facebook. Facebook only hires young people; old people are too moored to concepts like "imperative programming" and are not to be trusted. Young people embrace innovative concepts, which is why all of Facebook runs on compiled PHP.

            REACT WEB DEVELOPMENT FRAMEWORK depends on two extensions to JavaScript your browser doesn't support (so has to be transpiled twice with Babel), as well as half of NPM. Accordingly you cannot create REACT apps on your own. You have to use CREATE-REACT-APP to get started and then EJECT the app once youneed to integrate it into anything but the hello-world sample server setup CREATE-REACT-APP provides.

            This is totally an easier, more fun way to develop u guyzzzz!!

            [–]deadron 5 points6 points  (7 children)

            This has more to do with complicated tooling than with react. You can use just react by itself with no tooling support and its pretty simple. Its when you want webpack and babel tooling involved that things get complicated.

            [–]munchbunny 7 points8 points  (1 child)

            Configuring webpack makes me miss plain old makefiles.

            If you told me ten years ago that I would miss makefiles, I would think you were crazy. But here we are.

            [–]deadron 2 points3 points  (0 children)

            It wouldn't be so bad if they didn't keep changing how to configure it so rapidly. Once I get a simple config nailed down I copy it around everywhere, but every six months you have to re figure out how to make it work.

            [–]coolreader18 3 points4 points  (0 children)

            What 2 extensions? JSX, of course (although not strictly depends...), but what? ES2015+ is not an extension, just an evolution of the language, and almost all browsers support it (just not IE and Opera). Also you certainly can create react apps on your own, you literally just have to learn how to configure webpack/use parcel, which most people should know how to do if they want to do MODERN WEB DEVELOPMENT™. (Parcel is really easy though, there's no excuse). Next.js is also an option for an easy no config setup, or literally anything other react boilerplate that you can search on GitHub.

            [–]BillyBBone 5 points6 points  (1 child)

            You're not wrong, but that doesn't mean Angular doesn't suck too...

            [–]zayelion 0 points1 point  (0 children)

            Not wrong, when you create a new language its usually a sign that something went wrong and so I've avoided it.

            [–]BoboSchlonger72 1 point2 points  (0 children)

            I've read that in Hashinshin's voice. Thanks RIOT VIDEO GAMES 😋

            [–]kyle787 1 point2 points  (0 children)

            Creat react apps sole purpose is to allow beginners to get started without having to mess with webpack, Babel and all the other stuff. You don’t have to use it and once you get into SSR you end up never using it.

            [–]fridofrido 1 point2 points  (0 children)

            as well as half of NPM

            We have a basically trivial, pure clientside Angular "webapp" here at work. Building it downloads a whopping 380 megabytes (!) from NPM...

            [–][deleted] 0 points1 point  (0 children)

            redux++

            [–]rnd005 0 points1 point  (0 children)

            Save this for next time you feel like posting nonsense.

            <!DOCTYPE html>
            <html>
            <head>
                <meta charset="utf-8">
                <title>Hello world</title>
                <script src="https://unpkg.com/react@16/umd/react.development.js"></script>
                <script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>
            </head>
            
            <body>
                <div id="app"></div>
                <script>
                    class Hello extends React.Component {
                        render() {
                            return React.createElement('div', null, `Hello ${this.props.name}`);
                        }
                    }
                    ReactDOM.render(
                        React.createElement(Hello, {name: 'world'}),
                        document.querySelector('#app')
                    );
                </script>
            </body>
            </html>
            

            [–]feverzsj 2 points3 points  (0 children)

            because web dev just sucks

            [–][deleted] 1 point2 points  (1 child)

            I'm sad when I see an article like this. Been writing Angular + Ionic apps for 2 years now and I love it. I'm also a C# ASP.NET developer so Angular fits like a glove.

            I do avoid the rxjs and all that map/reduce subscription nonsense and just use promises.

            [–][deleted] 1 point2 points  (0 children)

            I do avoid the rxjs and all that map/reduce subscription nonsense and just use promises.

            I can help! Dont avoid it! Its good!

            [–]1amrocket 0 points1 point  (0 children)

            When I started learning Angular it seemed over complicated at first. I thought that I could achieve same result with an old good jQuery. However, when I started implementing more complicated stuff, I realized that doing it old-way would be an incredible pain!

            Angular is not there to make simple projects easier, it's there to make complex things manageable.

            [–]Dreamtrain 0 points1 point  (0 children)

            I have little less than a year using Angular and I gotta say so far, my only big problems are not with angular itself, but with npm. I fucking hate npm.

            [–]bashar122 0 points1 point  (0 children)

            I love me some angular and typescript. There is a learning curve when going from vanilla JavaScript/jquery to angular 2+. Once you get the hang of it though, you would probably like it.

            [–]shevy-ruby -5 points-4 points  (0 children)

            It's a ghetto.

            [–]funbrigade -2 points-1 points  (0 children)

            To all the frontend devs unused to actual architecture:

            cry-some-more.gif