It's been around nine years since Angular JS (the first one) was unleashed on the world. Nine years of single page apps (SPAs) in the browser, and constant innovation in the frameworks used to build them.
Dev.to has a great community of active, intelligent and helpful frontend developers who use a variety of frameworks to build SPAs. Perhaps some of them have been working in this area since the first Angular JS came out.
My question to anyone who's interested: is anything getting better?
Is it getting better for the users of our SPAs. What has improved for them in the last nine years - think of specific things. If you don't think it has improved, tell me - why not?
Is it getting better for the developers of SPAs? Is it easier today to build, say, a todo app than it was nine years ago?
Oldest comments (62)
I think that Angular (with typescript, its inversion of control system and best practices in official doc) is a really great improvement. I personally believe is very difficult to build large and maintainable software without static type checking. Also dependency injection is a must for building decoupled modules... Of course, you could write great things with vanilla js but you have to be an extremely disciplined developer.
Slight nitpick but none of these frameworks are required for DI. DI has existed in the JS world for as long as there were functions.
I know, that's why I wrote 'Of course, you could write great things with vanilla js but you have to be an extremely disciplined developer.'
One thing I like about Angular it's that if you don't know the framework and read the official tutorial, they encourage you to use DI for api request, I thinks that's great for new developers with no experience.
It is better because we have React now.
Could you expand? How is React better for developers? How is React better for the end users?
React is better because it is more popular. Therefore there are more jobs for developers who know it.
As long as you can create a website that works well and solves the customer's problems, no one is going to know whether you used React or not.
Shouldn't we all be writing everything in Java then?
Java isn't hip and new. Also, React is a frontend framework, which Java is not.
React has a great following among developers who rate it as the best thing since sliced bread. I wouldn't dispute that, but I have concerns that once the product is delivered it's usually out of the hands of the developer and into those of a maintainer, who can't be guaranteed to have the same love for the framework or experience in using it.
It's fine if your customer is big, with pockets deep enough to maintain a pool of React (or Angular, Vue etc.) programmers and keep them motivated during those times when no maintenance is needed, but that doesn't cover everyone by a long chalk. For the rest, no, things haven't gotten any better - just more complicated.
React is easy to pick up as it has a small surface API. A maintainer will learn it easily and reason about the code without many issues. It's certainly much easier to maintain than a jQuery or Angular 1 app. Therefore React makes things better.
When you say "easy to pick up" you may be assuming everyone has skills comparable to your own, but this is a risky assumption. Not all maintainers have the high-level coding skills needed to be comfortable with JavaScript, React and their development environment. That's not meant to be a slur; these are fine people doing a difficult job with many different responsibilities to juggle. Maintenance people are expected to jump in and deal with a host of different problems at short notice, not spend 3 months getting to grips with this or that (possibly obsolete) framework first. I've yet to find anyone at the local CodeUp meetings who would claim React to be easy to learn; most seem to struggle with it for several months before achieving any degree of fluency.
Note: I am supported in this view by the author of How Fast Can You Learn React?
How does that improve things for end users? End users generally don't know or care about React.
They don't need to know. React is fast and good at managing state. Developers love it, and can make smooth, performant websites with it. It's not the customers who typically choose the framework, they just want a good website.
They can also make them without React and React is one of the heaviest of current generation of client side front end tools, by itself. Without a router. Without an additional state library like Redux. Un-code-split-able. So what's extra good about React for users that justifies "taxing" users with React?
Kinda playing devil's advocate here, since I do think there are use cases that React is the best choice for. I just also think it's used way too much when it's not.
I think it improved for us developers, not users tbh.
I think if it improves development then users benefit because developers find it easier to add more features and build more robust software
Prove it.
The fact that you're communicating through a browser that wasn't developed until OS's made it easier for programmers to build such complex network software is proof enough !
Really? Does it, though?
Yeah, it does
Can you think of a way that may not be true or that comparison might not apply?
Nope
Then don't talk to me, because you have nothing to say worth hearing.
Bro, you went from "Prove it" to "Can you find any reason..." to "Don't talk to me", Fail!
Says you. In my opinion, you failed, "bro." I'm not interested in wasting my time talking with someone who isn't keeping up, "bro."
First of all, one example proves nothing. Anecdota. As you'd surely be saying if our positions were reversed, with the same "I win!" attitude you have here.
Second, that comparison isn't a good one. Generally--but with so many caveats and sabotaging factors as to be barely worth discussing--more productive developers leads to better software. However, you're comparing networking and operating system APIs (a backend concern, for developers) to graphical user interfaces (a frontend concern, for non-developers). Lower-level APIs for software engineers to hook up program-to-program are not in the same problem space as high-level presentation languages for designers or interfaces for end users to utilize program-to-human.
The latter is a lot harder than the former to bikeshed to death and endlessly reinvent in different programming paradigms, because humans are diverse and subjective and end users don't care about religious wars over programming paradigms. If you were front end, you'd know that, because it'd be your job.
Steady-on, For someone who doesn't want to be spoken to you sure are long-winded !
I'll take that under advisement. As someone with nothing substantive to say, you're surely an expert in brevity.
Thanks
When we talk about cross-platform development, I think it is getting better everyday. It became super easy nowadays to have one application be deployed in multiple environments (web, mobile, etc...) and increase reusability of components built along the way.
So your argument would be one of economics? It's now cheaper to produce the same application on web, mobile and others by reusing components, rather than 'handcrafting' the code for each platform.
Is this a common pattern for all of the frontend SPA frameworks? How often does that cross-platform development get used (any idea of percentages per framework?). What's the overhead if any?
Speaking briefly as a user, I find a lot of the desktop versions of SPAs to be resource hogs - Slack, for instance. Is this getting better?
But web exists on mobile and desktop. It's been easy for a long time to deploy the same stuff to mobile web and desktop web. What hasn't been easy is designing good experiences for the same application across dramatically different contexts. What hasn't been easy is optimizing the same code for dramatically different contexts. I'd argue neither of those has changed much.
In fact, I'd argue that some things devs love about modern development have made those harder.
Obviously there are some specific stand-out projects directly addressing write-once, but have they helped with those two or hidden them under the rug? (Probably varies.)
I still prefer to do everything on the back end. It is significantly faster to push raw HTML to a client and have it simply insert or replace part of the DOM, than to dynamically generate DOM client side from sever data. This still enables single page applications, allows for Http caching, plenty of extensibility on the back end. There are so many tools, tried and true utilities that exist well before these Frameworks that can still can be used with this approach. Additionally, if no JS is available, or is broken, or if you need SEO, or screen readers, these ALL still work, since the entire HTML (not just the replaced content in the container) can be pushed from the server. Everything existing still works beautifully, accessibility is maintained, tools don't need overhauled, and it's significantly easier to program. It's an all out win.
All great, unless you want to be able to provide an offline experience.
Depends on the scope of the application and the target audience. If your bread and butter is intranet apps for the corporate crowd then there is no such thing as offline: if a pc is offline then there is a problem with it or the network infrastructure, essentially you can depend on the clients always be in contact with your server. In these cases all that matters is raw speed of delivery and ssr really shines there.
These are my big reasons for switching to Server side rendering. As well as improved productivity. At least to me, it's much easier to have one monolith with a small team rather than wrangling and deploying 30 different projects.
I think we've reached peak todo, but that's kind of beside the point IMO - but in more complex examples I think we are entering a period where frameworks and platform APIs are really starting to mature and come into their own. Service Workers are not uncommon these days, making it easier to enable offline functionality on a wide range of devices. Frameworks are still evolving - React Hooks and that Vue 3.0 RFC come to mind - but in a way that guarantees backwards compatibility. I think library writers have learned a lot from the mess that was Angular 2, and that's definitely a good thing. And we seem to have settled on virtual DOM based frameworks for the long run, which adds some further stability to what I think has been a pretty chaotic ecosystem just a few years ago. So I'd say that web development is getting easier for the more serious use case.
I love Angular for alot of reasons one of them is because it's not React.
Angular focuses on one very important goal front end templating and dynamic HTML.
React does this too but it also does a bunch of other stuff that I never need or use.
Basically my point and feedback is to keep Angular focused on it's job.
Making the web better is the end goal, there are I'd say a bit, many, more JS libraries then there needs to be to achieve this goal, but to each thier own flavor of the day.
People are even questioning JQueries longevity which I find ridiculous.
JQuery does everything it needs to and it does it wonderfully, same as Angular.
Is it getting better? No.
I have Angular 1 apps in productions that work well, are easy to update and maintain.
The new wave of javascript does not solve my problems other than being able to have isomorphic applications which in honest doesn't matter for B2B.
Two way binding of data just works.
I've moved over to mithril and couldn't be happier. Its a bit more work than Angular 1 but it has an insanely small js footprint, easy to open and read the code, and easy to learn.
React is monster, trying to get people to act conventionally with React is a nightmare.
Angular is more conventional, I wish it didn't borrow so much of them React paradigm
Vue feels like a true successor to Angular 1 is ease of use. I don't like its documentation, or libraries as they are poorly built
In ExamPro we still don't use any javascript framework. It's just not worth it.
I think its all terrible Dave
The Web I Want
Chris James γ» Aug 20 '18 γ» 6 min read
Your article hit the nail on the head! If there would be one thing I think you forgot to bring up in it was the potential vulnerabilities from all these libraries used to build these things...but alas they all need to be Web Apps! π
Angular1/jQuery to VueJs2, drastic reduction in code bundle size and run time performance on mobile devices for end users.
Code isn't awful to read and understand so maintenance costs down features up, plus we don't have to spin up new devs on old tech that they don't want to learn.
We have come a long way since the days of asp classic.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.