DEV Community

David Wickes
David Wickes

Posted on

Front End: Is Anything Getting Better?

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?

Top comments (62)

Collapse
 
sebalr profile image
Sebastian Larrieu • Edited

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.

Collapse
 
quii profile image
Chris James

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.

Collapse
 
sebalr profile image
Sebastian Larrieu

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.

Collapse
 
amineamami profile image
amineamami

I think it improved for us developers, not users tbh.

Collapse
 
redbanditbot profile image
Que

I think if it improves development then users benefit because developers find it easier to add more features and build more robust software

Collapse
 
oenonono profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Junk

Prove it.

Thread Thread
 
redbanditbot profile image
Que

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 !

Thread Thread
 
oenonono profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Junk

Really? Does it, though?

Thread Thread
 
redbanditbot profile image
Que

Yeah, it does

Thread Thread
 
oenonono profile image
Junk

Can you think of a way that may not be true or that comparison might not apply?

Thread Thread
 
redbanditbot profile image
Que

Nope

Thread Thread
 
oenonono profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Junk

Then don't talk to me, because you have nothing to say worth hearing.

Thread Thread
 
redbanditbot profile image
Que

Bro, you went from "Prove it" to "Can you find any reason..." to "Don't talk to me", Fail!

Thread Thread
 
oenonono profile image
Junk • Edited

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.

Thread Thread
 
redbanditbot profile image
Que

Steady-on, For someone who doesn't want to be spoken to you sure are long-winded !

Thread Thread
 
oenonono profile image
Junk

I'll take that under advisement. As someone with nothing substantive to say, you're surely an expert in brevity.

Thread Thread
 
redbanditbot profile image
Que

Thanks

Collapse
 
darkain profile image
Vincent Milum Jr

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.

Collapse
 
powerc9000 profile image
Clay Murray

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.

Collapse
 
jezmck profile image
Jez McKean

All great, unless you want to be able to provide an offline experience.

Collapse
 
philiphassialis profile image
Philip Alexander Hassialis

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.

Collapse
 
pottedmeat7 profile image
pottedmeat7 • Edited

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.

Collapse
 
gtanyware profile image
Graham Trott

Getting better? Getting more complex, certainly.

To me, frameworks are all solutions to the wrong problem. As I see it, the great majority of web pages can be described in fairly plain English. OK, there are chunks of functionality like Google maps and weather widgets, but these are standard library components that are imported, not created by the main page code. The rest is just a set of boxes within boxes and the description is quite simple. It's HTML (or JSX) which is line for line equivalent to plain English commands.

So the problem isn't with structure, which is what frameworks deal with, but with language. It's simply that JavaScript isn't as good as English when it comes to describing what a web page looks like.

JavaScript is a complex system programming language, but everywhere people are falling over themselves to add frameworks that are at least as complex as JavaScript itself. When did adding complexity become the solution to complexity? Where does it stop?

Programming a web page entirely in JavaScript is like playing golf with a single club. So let's have two clubs. Keep JS - with React and the rest if you choose - for the complex components that once written will never change, and do the UI and the business logic with something simpler.

Over the years a few computer languages have been created that look more like English than any of the mainstream programming languages. I cite HyperTalk, which eventually became AppleScript, and of course SQL. These languages start by asking what domain they are addressing; they don't aim to be totally general-purpose. Instead, they comprise commands specifically designed for the job in hand, making them easy to read and to write. Programs get shorter, leaving fewer places for bugs to hide, and long-term maintenance can be done by any intelligent person.

I write web apps using a high-level scripting language of my own devising, written in JavaScript and inspired by HyperTalk. The compiler and runtime (about 250kB) run in the browser and the scripts are raw text. If a complex item like a GMap is needed I code a 'plugin' that extends the language syntax to deal with the new API, so the main scripts never have a line of JS in them. My pages load quickly and because the system implements load-on-demand there's no limit to the size of app it can handle. And when other programmers see the code they can tell at a glance what it's doing, so who cares if it's a non-standard language?

Keep It Simple, Stupid. Then it really can get better.

Collapse
 
jce profile image
Juan • Edited

The past years have been of “lets invent new ways of writing the same thing to get in the spotlight and render a button 3ms faster”. The improvements are marginal and only benefit a few. The 80% of day to day projects I’ve seen take up all their time setting up the infinite chain of dependencies to build a simple site and as a side effect, making newcomers spend their time learning the frameworks and shielding them from learning real js. If you interview devs in the recruitment process you’ll see this. The big benefit I see is not for devs nor end users. It is for the company itself.

Years ago I remember devs were scarce and hired based on skillsets. Now, with frameworks and libraries companies don’t need skilled devs, they just need devs who know react/angular/etc and that is it. Making the process of moving devs as resources as simple as possible. In effect normalizing the dev. Not saying its a bad thing, but I do see way less creativity, experimentation and innovation going around these react days.

The only change I would say was transforming and positive for devs and users was html5 (geo, audio, canvas, workers, etc) and css3 (animations, transitions, media queries). Those apis allowed us to do new things not possible before, deliver new value for real world users. Not just a new cool way of typing the same thing to deliver exactly the same end value.

Collapse
 
quii profile image
Chris James
Collapse
 
sonarboy profile image
Joshua.C

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! 😄

Collapse
 
codeposse profile image
T.Hunold

Short answer: no.
JS is polluted with "because we can" rather than efficient approaches to development. 2mb of Bootstrap as-is = bloated. 2gb of version specific node_modules = powerful and efficient.

I am currently working in Dart, Angular 4 & 7, React, and Vue on a daily basis (I manage teams) and I think that looking at the outcomes of the majority of the projects I have are needlessly complex to just say we use these technologies.

Collapse
 
minkovsky profile image
Filip

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.

Collapse
 
kspeakman profile image
Kasey Speakman

MVU has made things better for me as a dev. More on that in this comment. The tooling is still a hot mess for SPAs. It's actually gotten markedly more convoluted since Angular first came out. I remember not having to use things like Webpack to build a SPA. I had a minifier / bundler plugin in my IDE that would spit out a bundle for me. It wasn't perfect, but it was far simpler than Grunt/Gulp/Webpack/etc.

I'll put this on the user side, but I think there are more CSS frameworks available that make it easier to get started with a nice user experience. We use Semantic UI, for example. Another similar one I'm keeping my eye on is Bulma.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.