I'm kind of new at frontend development, but my issue usually had been the decision makers deciding that too many devices lead to longer testing times, leading to a longer time to deliver the product. This is an issue commonly found in applications for the internal public (the client of the product is the company itself and not the company's client), but not exclusive to it.
So you have a technical team showing all the advantages of something as powerful as Angular to people who are used to (and are fond of) writing Java code mixed with HTML and JavaScript in a JSP page.
They will look at all that sorcery Angular does, won't understand it and won't believe it actually doesn't take that much more time to make it responsive.
Now, if I could decide how to deal with this, wouldn't go desktop-first or mobile-first. I would go both together, but with more attention to the mobile side because a smaller screen is easier to break.
Build both workflows together and it will lower the chance for a feature having to be removed from mobile because "it doesn't fit the screen".
I don't believe in mobile web apps being less powerful than their desktop counterparts.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm kind of new at frontend development, but my issue usually had been the decision makers deciding that too many devices lead to longer testing times, leading to a longer time to deliver the product. This is an issue commonly found in applications for the internal public (the client of the product is the company itself and not the company's client), but not exclusive to it.
So you have a technical team showing all the advantages of something as powerful as Angular to people who are used to (and are fond of) writing Java code mixed with HTML and JavaScript in a JSP page.
They will look at all that sorcery Angular does, won't understand it and won't believe it actually doesn't take that much more time to make it responsive.
Now, if I could decide how to deal with this, wouldn't go desktop-first or mobile-first. I would go both together, but with more attention to the mobile side because a smaller screen is easier to break.
Build both workflows together and it will lower the chance for a feature having to be removed from mobile because "it doesn't fit the screen".
I don't believe in mobile web apps being less powerful than their desktop counterparts.