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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
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.
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.
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.
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.
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.
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.
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! 😄
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.
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.
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.
I think the advancements in CSS and the increasing knowledge of accessibility among developers are making things better for the user. Offline navigation is also a thing that the users notice.
We all have our confirmation biases, I know I do. The amount of tech that has been developed in the JS space in the last 4 years is partly that. I often read developers saying "We're making things better for devs, which makes thing better for the users" but that's not a measurable objective truth. It's partially true, it's partially bias.
There are measurable things like page speed, time to paint, time to first interaction and so on but are websites tracking this over the years? I'm not sure. Can you say with 100% certainty that the web apps you're developing now are 100% better or are you saying that your developer experience is 100% better? Even measurable things can be debated. Let's say I use "tech X" to make the initial time load a little faster, but then I use a service worker to download tens of megabytes of code in the background. Is it really a better user experience if I shave a few milliseconds, even 300 of them, if then I'm going to impact your mobile data plan?
I don't know if we're there yet but as clock speed teaches us, there's an upper limit of how fast you can go, let's say we hit that limit, would we still be able to say that we're improving UX? What about the fact that more JS can result in a lot of CPU usage on the user's computer? No one I know about really measures that.
On the other side of the argument, which I also agree with, is the fact that saying "is it really better?" needs context. All frameworks (including the ones I'm not citing but we all know) are developed to ease the life of the developer. The reasoning is that if my life is easier, then it's easier to deliver features and updates to the user experience. This is true in some cases. But is it really better for all developers? I don't know, that's where the complexity argument comes in by the side entrance.
I've never seen so many courses, tutorials, programs and learning material for frontend programming as I'm seeing these days, that's because it has gotten objectively harder for a single developer to learn "everything they need to know" in frontend. I often joke that backend programming is easier, but a part of me actually believes that. Not because one is better or worse of the other but because backend programming in its current form has been around for a long time, which helps to establish patterns, transferrable knowledge and so on and so forth. So yeah, frontend programming is hard, because it's not as mature as it will be a few years from now.
Unnecessary complexity is also intrinsic gate keeping, but that's probably another whole argument. It's funny because the big frameworks are born out of a need to manage that complexity, but I think we should learn a thing or two from the micro services hype a couple of years ago: yes, micro services are great but if your team is beyond a certain size, otherwise they just add complexity.
Another thing is the bias I was mentioning in the beginning. If I spent a lot of time learning a framework, whatever that is, I'm not going to be happy to know that I wasted time. The other day the Vue core team proposed a new syntax (which would have been additive, not a replacement), the community revolted, they backtracked saying that they are going to offer it as a plugin and support the current system for the time being. Kudos to them for listening, but this episode makes my argument as well :D We all have biases.
How all of this is going to make lives better for the user is anybody's guess. Static site generators are an interesting exception because, at least those who try to be accessible by default, have a direct impact on the user experience. If anybody using them is generating fast and accessible websites that use established patterns that's a great, great thing. I have no idea how accessible and fast a basic "hello world" website generated by Wordpress is, I truly don't know. Maybe it's as good, I haven't used Wordpress in forever.
So, to conclude, it's not all bad, it's not all good, we just need to reject believing our own biases too easily and ask ourselves "what am I doing?" from time to time.
BTW I think we should ask these questions to UX designers as well.
ps. I forgot to talk about developer happiness which is a big factor here, we are curious animals and a lot of us get bored easily. Feeding the brain with new things to learn can improve our productivity level and indirectly making things better for the users, literally because we are happy to implement those changes.
Obviously it's getting better. Nobody could rationally deduce that the front-end community has just been faffing around for the last decade :)
🤣
You think? I'd say it's about half and half.
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.
Angular is great, as many other frameworks, but they are all feel like workarounds, I mean features they implement should be standard and supported by default for the web. We should better agree on the best approaches and make it to be the part of the web specifications supported by default in browsers. And no doubt the browser is the major multiplatform app environment, so make it even more convenient, make it true app engine and not just a web documents reader as it was intended since the beginning, or do we need new web platform?
Do you really think a new platform is going to help? How? Who is going to create it? What are their priorities going to be? How will they assure it's better than what we have? How is it going to get in the hands of as many end users around the world? Why can't we just evolve the platform we have? If we can't agree on how to do that, how will we agree on the right new platform?
I tend to agree with you that the new platform is really hard to push into masses. I can only see 2 major benefits which can motivate people to adopt it: 1. unified platform for apps, as it is already web now, but without all inconveniences of the it in current state. 2. Major security and privacy built in on day 1, including distribution of apps via block-chain, for example.
I agreed until you said block chain.
But I still think it would be... more likely to succeed, maybe... to evolve from the set of shared concepts and based on a common understanding of the benefits and flaws of the web.
One issue is that, respectfully, not everyone who thinks they've nailed the concepts and flaws of the web has. If you can't explain why HTML is important and recognize it needs to evolve and how, you don't have the necessary foundation yet. If you think replacing it with script is the right move, think again. Not to go all "appeal to authority" on you, but even Brenden Eich agrees.
One interesting idea: ultimate "todo app" one-liner (ok... possibly fibonacci categories for runners up placement) compo? :-)
I think in general the 2010-2013 javascript / open source big bang explosion did an interesting phenomena: as driving school analogue, paradigm shift was from ordinary driving school to: "first learn chemistry of metallurgy -- to do the rivets and welds -- THEN do the driving learning part". Whether the dust has settled, and/or formed new interesting and swift galaxies, I'll make space for others to answer.
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.)
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.
IMHO yes, a lot got better.
The first thing that comes to mind are tools like create-react-app and angular-cli. No more manual webpack-configuration. It's very easy to get started.
Another one is that native JS-modules are widely supported. No need to worry about bundling or transpiling until much later in a project (unless you need TypeScript or JSX of course).
How do those affect end users and improve their experiences with front ends for the better?
They don't. They improve developers' lives.
It is better because we have React now.
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?
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.
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.
In my opinion, it's getting better for devs, company and also and users :
Nowadays frameworks allows devs to build stuffs quickly without having to reinvent the wheel, so they can focus on what is more valuable for the end users while having less headaches.
We can now start and deploy a project in a few minutes thanks to many tools.
Also it makes employees more productives and happy because many things became easier, and as we know : happy employees make good company
And with quick valuable products made, it is also more economic for companies.
Like someone said in a previous comment, it is now more easy (thanks to PWA) to build/deploy apps through differents platforms and so reach more end users.
But how are devs reinventing the wheel any less? You can assert that, but is it true? How?
There's incredible churn and increasing complexity in front end development. Especially in the places that most impact end users.
Over the last 6 years a majority of products have probably been rewritten three times to jump on the bandwagon of the current most popular front end framework. Or if not rewritten most devs have probably worked on new products adopting each one.
This means the GUI (modals, dropdowns, accordions, typeaheads, etc) has been recreated in each of those frameworks each time. Has the end users' experiences with those rewritten components improved? Really, honestly changed for the better?
Angular is great, as many other frameworks, but they are all feel like workarounds, I mean features they implement should be standard and supported by default for the web. We should better agree on the best approaches and make it to be the part of the web specifications supported by default in browsers. And no doubt the browser is the major multi-platform app environment, so make it even more convenient, make it true app engine and not just a web documents reader as it was intended since the beginning, or do we need new web platform?
I never like Angular or all the popular frameworks. You can't build a large app with it. (Large is relative) which is why I created nimbleJs. I've just finished up the nimble use. A low code drag drop editor for the runtime.
Nimble is used to build and extend itself. Written in pure JavaScript. You can check it out
nimble-ide.com
Code splitting is better and easier, so frontends don’t grow linearly. Also webpack and js modules make it so you can only use what you need from a given library. I think that saves the user a ton of unnecessary load time and in the aggregate has made the internet faster.