> I've given in my resignation at my current place of employment and will be seeking an exclusively back-end role for my next adventure
Oh boy. I sympathise entirely with this post, but the story's exactly the same on the backend.
Kubernetes. Docker. AWS and its gazillion impenetrable product names. The days of security updates, pentests, honeypots and captchas you have to go through in order to put up a webapp that won't be commandeered by (insert bad guy here) within hours. The endless cycle of breakage on your server because LetsEncrypt or whoever have upgraded their crypto libraries to fight against (insert bad guy here).
The need for a lawyer to write you a privacy policy before you can let people log into your site. The endless bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. And even then it's better than dealing with email verification because Gmail/Hotmail will kill your emails anyway.
The complicated web is everywhere. Retreating to the backend is no escape. Sorry.
Some of my colleagues and I were joking recently that the "AWS well architected" framework should've been named "AWS well paid" framework. It's like it's no longer legit to run a small site serving a small community. It has to "scale", be secure against minions who want to usurp your machines, have backups, CI, CD, GitHub events, run on K8sa and be "cloud native", and on and on .. to show some HTML page when an end point is hit. I feel I can't even joke about this any more here.
The stacks run deep on both ends .. but I'm often not sure to what end.
What's funny to me is that whenever I get stuck with docker or docker-compose (or getting our various docker services talking to each other), I'm told by a certain engineer that I ask for help from, "It's really not that complicated.". Then a week later he's asking me for help setting up eslint and vscode auto-correct/format, telling me he's been trying to get it working half the day, emphasizing how terrible JS tooling is. I of course sent him on his way with a working set-up five minutes later.
I guess the difference between us is I'm in JS everyday while he's primarily backend. I've made peace with my tooling as has he. I've also made peace with the fact that my tooling is going to continue to change every few years. From Gulp to Webpack to Parcel to Snowpack and onwards.
I don't think it is, for the business-logic code portion any way.
For backend, the hiring is typically "you know Java" or whichever $backend_language.
For frontend, your job application will be terminated in the early stages of the pipeline because you do not know the latest 2 year old framework (that is written in JS that you know extremely well).
10 years of JS and web experience amounts to nothing because "you do not know Angular". I do not think this applies to backend at all, they just see a "langauge-X developer".
I have a strong impression also that the hysteria accomodated well in the backend world. Folks in the workplace need containers on k8s cluster to deploy a static website. I feel I'll start throwing things on hearing the word "cluster", but wait - the data lakes on the cloud are coming. We need a bloody thunderstorm.
Kubernetes. Docker. AWS and its gazillion impenetrable product names. The days of security updates, pentests,
honeypots and captchas you have to go through in order to put up a webapp that won't be commandeered by (insert
bad guy here) within hours. The endless cycle of breakage on your server because LetsEncrypt or whoever have
upgraded their crypto libraries to fight against (insert bad guy here).
The need for a lawyer to write you a privacy policy before you can let people log into your site. The endless
bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. And
even then it's better than dealing with email verification because Gmail/Hotmail will kill your emails anyway.
I've often heard the term "If bridges were built like software..." to show the fragility and ad hoc building of software.
But let's image "If bridges were built like software" to survive pretty much any kind of malicious attack (like in
"WTF? Why did the bridge collapse when those crazy guys bombed it?").
So maybe, just maybe, not everything should be a web app, and be connected to everything.
Assuming learning is not a big problem, which area would be pleasurable experience? There's not a whole lot there except Back end, front end, embedded, mobile application, ML? Any substantial fields I missed?
This person backends. No seriously though, well said :). If the author thinks backend is all sane, let us welcome them to the world of everything you said plus more stuff. How about working with databases, ORM, API (is there a standard ?), package managers (composer?, gem?), authentication/authorization ? (should I use JWT..ooh thats crazy. cookies anyone??) etc etc
It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically. The complicated web is here because users insist on interaction, and if any web page has more than around 10 interactions on it, the resultant complexity is best handled by a framework. I recently got to do a jQuery job for a client-- it wasn't a pleasant blast from the past but a kludgey swamp to slog through.
The build pipeline complaint also strikes me as hollow. Create React App outputs folder you can drag and drop onto a server and serve, same for Angular and I would assume Vue. Yes, it is a lot of JS from a ton of NPM libraries, but that's the trade-off when you get an entire ecosystem of code for free. If your application is security critical then consider either writing your own libraries or hosting security vetted copies of the libraries.
The real reason to leave this industry is that it's all the same work at the end of the day. Despite what application you build, whether it's a social network, a security application or collaborative tool like Figma or Trello, it all runs together as a mish-mash of views, data and DOM elements. Unless you're really invested in the product, it becomes hard to maintain enthusiasm. You can only roll a CSS library, or auth scheme or API library so many times before you're ready to start some new adventures in coding.
So far I haven't met a user who asked for ads, unmuted
autoplaying videos, popups, tracking, loading screens, and UI
that's basically broken by design. Did Google really redesign
Google Images' UI due to popular demand? I doubt it, because the
new one only works 80% of the time when I try to use it.
Most websites that are obviously built using modern frameworks
and shiny layouts don't let me open links in new tabs, not to
mention they're a nightmare for screenreaders and similar tools.
And considering how often terms like "responsive" are thrown
around it is staggering how easy it is to break many of those
sites just by resizing the browser window.
In some aspects I'm definitely not the typical user, but to
quote Adam Jensen: I never asked for this.
This is a common response to complaints about front end complexity, but how true is it, or how true does it have to be? We're posting on a very successful website that could have easily been built in the early 2000s in terms of technology, if not earlier.
In my day job, I write server-generated HTML for a growing and successful startup, without React, front-end frameworks or a particularly complicated front-end build setup (we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense), and the user experience is comparable with many other web apps I use, some of which are almost certainly full-fledged SPAs, and is well-loved by our users. My team's productivity is easily double what I've experienced at jobs using the latest and greatest technologies.
Could I use this approach to build Google docs? Probably not, but then again, that's not what I'm building, and I don't need a tool capable of building that.
In my not humble at all opinion - user expectations sank to absolute lowest minimum.
Oh my, for example I never asked for smooth scrolling (I've actually disabled it in browser), instead someone insists on it and forces that on me with some javascript. Thanks, but no thanks.
I can't even have my own scrollbars from system theme most of the time (why even this?!).
What we have now is ultra slow interaction because of tons of JS. Constant cpu usage and battery drain. And most importantly boundless memory hogs such as oh so great interacting facebook that easily eats 2.5gigs of memory.
And don't get me started about "effects", animations, fades, stolen keyboard shortcuts, right clicks and every other bit that throws accessibility out of the window.
> user's expectations for the web have grown astronomically.
Agree with everything you're saying, except for this.
I do user research as a job, which means that it is my day job to methodically interview and observe people using everything from web sites to apps to enterprise software. So far, I've had the privilege of doing so with more than 100 users.
What users expect is things that work quickly and reliably to get their job done, and then get out of the way. It doesn't matter whether they're booking a flight, buying cell phones or working in a complex workflow system.
Nobody, on the other hand, really wants bloated pictures, autoplaying videos, and dozens of different features without practical use - except for marketing people and managers.
> The complicated web is here because users insist on interaction
Do they, though? Or is it the product managers who insist on such things? I'd put more weight on them. Some of it might be backed by user data, but generally it feels like they're pushing things unjustifiably or for wrong reasons.
> user's expectations for the web have grown astronomically. The complicated web is here because users insist on interaction,
Nope
Im going all on anecdote. Consider my SO is a youtuber and spends her days doing research for her videos, as do her friends on Tiktok and Insta. Not once has she ever mentioned any expectations despite my asking. She didnt even care about the cool "web app experience" from YT. I don't even think she cares about what I do.
Just because we over-engineer things to justify our absurd but nice salaries in the name of maintainability and More speed - more power does not make the mountain of dung smell any better.
Having been around since the pre-CSS days up to the time of attempting to hack my own build pipeline with the YUI compressor, using npm is like a dream. The first batch of tools like grunt were very rough around the edges and hard to use, but the pace of improvements has been extremely impressive.
> Unless you're really invested in the product, it becomes hard to maintain enthusiasm.
+100 for that one. I spent a lot of time working on some absolutely bleeding edge crazy tech for a shitty client who made some stupid luxury product for rich people. Now I'm working on some 10 year old crufty web app for a non-profit that produces something of genuine public benefit and I'm more satisfied with my work than I have been in a long, long time.
> It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically.
I'm pretty sure that this is not true. You can ship great webapps without any of that overcomplicated nonsense. We're using one such right now.
This is the story you want to believe in. I was doing the exact same kind of interactive apps 10 years ago without any of this crap. Some things are easier, but their are not worth the 10x complexity.
You're not wrong, I think most in this thread won't debate that user expectations are ever increasing. I think the issue is that the complexity doesn't scale with the perceived benefits and it feels totally out of whack right now. There's also a lot of cargo-culting going on with massively complicated tools like Gatsby being deployed to build blogs and static marketing pages.
> It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically.
Users absolutely don't give a shit about you using Grunt, Gulp, Burb, Babel, and the billions of other tools. They just want to pay the meal they ordered online.
As a user I much prefer old style sites like HN, Wikipedia and the old Reddit to the javascripted up ones for most stuff. And I've got a readability extension to turn monstrosities like bloomberg.com into something like a relaxing page of text.
Yeah agreed on all counts. React apps are a real joy to create. The UI just works like magic with reactive updates. Modern js tooling gives me a fun and effortless way to produce user interfaces.
I agree, but I'd add that what really gets bland is just how uninteresting the outcome of all the complexity is in most things. For example, a NextJs app normalized into a hundred components, using redux, styles in js, webpack probably, npm scripts, jest, etc.. with the ultimate output being a probably barely responsive mediocre looking standard webpage with a navigation that doesn't work on a device you didn't anticipate because you re-invented links
This. Every tool that the author complains about serves a purpose and are optional. Using frameworks can help avoid the complexity of configuration too. https://asd.learnlearn.in/use-a-framework/
My place is implementing stuff in React, not for any reason, just because. I have suggesting that server side rendering might make things simpler, but it just assumed that we need React in this day an age.
There's a bit of hyperbole in the article, but it strikes a nerve.
I originally came from Java and was so fed up with the hulking class lib and the arcane build systems sprinkled with Ant snippets and XML galore, so JS felt like a fresh breeze.
AngularJS was a bit convoluted and the syntax was not nice. But OK, data binding was nice. Bit like dependency injection on the Java side made the code much harder to reason about but helped build certain classes of applications.
Angular 4 was just WTF. Somewhat cleaner module system but now with a clunky OOP language instead of the elegant functional expressions that JS had and Java finally adopted. For which reason exactly?
And I tried Vue which is a much lighter framework but like Angular, the build system is just retarded. Instead of many dozens of JARs with dozens of sub-dependencies, modern JS goes for the kill and literally imports several hundred of npm package with thousands of dependencies.
And in the end, I end up having to use "browserify" to have JS running in a browser. It's a clowns world in IT, but modern JS really takes the cake. I'm back in backend, solving real problems instead of wrangling my build chain.
I thought the same a few years ago, when I moved to backend development. I don't feel like the backend was that different, in terms of setting up infrastructure.
In hindsight, I just didn't enjoy writing code for money. When I left my last programming job, I started programming for fun again. It wasn't a deliberate effort, but something that happened on its own.
If you program for fun, you don't have to learn anything. You don't have to use webpack or SCSS if you don't want to. You don't need to write tests. "oops" is a valid commit message and "bugger off" is a valid response to stakeholders.
Apparently the author has always worked on their own projects, with its own (or its team’s) discipline. Let me state this: old-school front-end is a mess once you have to mantain an enterprise-grade application.
npm is pure joy to work with, in comparison with a huge mess of copy-pasted files in a “vendors” directory (if you are lucky enough to have such a directory! currently I’m working on a project where developers copy-pasted the content of JS libraries one after the other in a single “lib.js” file… for years!)
Front-end development has now reached a very fine situation regarding code hygene and modularity — and this makes me very happy to be on the front-end side.
I don't understand these kind of posts that 10 years back was frontend development easier. What is stopping people to use HTML, CSS, vanilla JS, or with jQuery these days? Nobody is forcing us to use React, TS on every project we do. Feel free to use jQuery if you think its the best tool for your project. All these technologies are just tools and you decide what tool you choose to get work done ;).
I can relate, and agree front-end frameworks and tooling feel overly complicated.
The good news is that there is another way. It's completely feasible to develop without any tooling but a static web server and a browser nowadays. Just bundle for production.
I've developed [1] (a +10k LoC chat app) and [2] (a small web app) using just a 600 LoC template library [3] (which I should really extract), and I vastly prefer it over more traditional setups. Being so close to the browser makes it so easy to see what is going on. I've never spent hours or days debugging the infrastructure code because there is barely any, which is usually what ruins the fun for me.
Everybody is different, but for me the accidental complexity of the commonplace front-end stack (webpack, react, typescript, ...) isn't worth what you get out of it.
> I don't want to learn nor use a million different tools.
As much rhetoric as there is about this being the frontend, the backend is worse. "Backend" is just defined as "anything that isn't the frontend" so the word casts a wide net. There's everything from logging and metrics to databases to pipelines and task managers to physical hardware and networking tools.
That said, it's always good to have a variety of knowledge and experience. The backend is nice because it doesn't rely on visual output as much and so you can code more without context switching between the editor and the browser. And it's incredibly easy to get pigeonholed into writing frontend code only. So many companies seem to be unable to let go of the fact that you have some specialization.
As someone who got sick of old school PHP and server-side rendering, mobile development, AngularJS/Angular/TypeScript madness, backend development, pure database development and what not I can tell you one thing: Everything is in our head and it's all because of the fear of staying behind. Once you start listening to yourself and once you start focusing on solving the problems as simple as possible, you will be happy in doing any kind of work. It's OK to be aware of new technologies, but you should use only those that make you happy and that actually solve the problem in a simple way. Why should I feel guilty if I'm not using some technology? Keep in mind that many technologies, frameworks are just products and the main reason behind the hype is money. Focus on general topics like software architecture, clean code, algorithms, best practices, database design skills and make sure to isolate yourself from hype.
I agree with some things. But on the other hand people started using npm (or bower) because they were tired of manually downloading and linking dependencies. Of course you had to do like 5, but now that everything is on npm it turns out that those 5 have 10, and those than have 20, so... CSS preprocessors I don't like that much either, but having an autoprefixer is actually nice. The alternative could be in the future to just not use it. Maybe we're already there?
It used to be difficult to get anything done. It was kind of, at first figure out how you will even get this complicated design to work. And every time you thought you had it, it turned out no, something broke in IE. This part got progressively better, to the point that I don't really test in multiple browsers anymore. But as things got easier, we found ways to make it complicated in other areas. And we can do nice things, but sometimes they don't add that much, yet cost a lot in terms of effort.
There is some pain and friction with colleagues that always want to do something new because others do it. When you get older you stop caring about that, and want to keep things simple and replace things that are an actual problem. As others have pointed out, this is the same in any area. We had a discussion what to do a couple years ago, and one colleague was dead bent on using GraphQL for an API. He's good at his job, but the answer to why was basically "because others do it". We didn't and we're fine -- we didn't need it. So you're going to get that pressure to learn new things everywhere. I don't have a good answer to this other than focusing on learning things that will last, even beyond this one area of work. But figuring out what that is can also be difficult.
I started out my career in a similar fashion as the author (dabbled with HTML/CSS/PHP).
One reason for the growing complexity in UI tooling is that many websites we build today compared to 10 years ago are not "stupid little web pages containing youtube embeds and guest books"
With that being said, many people are still building simple websites, and React/TypeScript/Webpack/Babel/CSS-in-JS/et al. probably isn't solving any "real problems" for them.
I've had to learn and adapt during my whole career, but I'm also more productive today than I've ever been, thanks to the tools that are available to me as a front-end developer.
I still reach out for Vanilla HTML/CSS/JS now and again, but I mostly deal with large and complex UI's that need to be shared across multiple projects and hundres of developers.
From a historical perpsective: jQuery solved a very real problem at it's time: simplifying and doing consistent/reliable cross browser JS development.
Backbone.js later came along to solve the problem that JavaScript apps were now so large and complex that simply dropping a few JavaScript/jQuery files was not a scalable way to build.
As applications became even more complex, React.js made it easier to deal with UI/state changes in large code-bases. All of these abstractions grew out of necessity.
Learn one set of tools really well. Make sure it's here to stay, mature, and has a large community. My fav is Nextjs, but it could be anything. Make sure it comes with everything you need, including a CLI to set up your project. Stay as close as possible to what the stack gives you. Don't build on top of it, unless you're willing to upgrade constantly. Avoid configuring your build system yourself, unless the framework gives you clearly defined escape hatches. (Like Next does.)
Learn the underlying fundamentals. Learn about algos and data structures. That will be relevant forever.
Most importantly, ignore these "20 state management libraries you should learn in 2021" articles. They are poison. And nobody cares.
I think there's been a much bigger change in (particularly front end) web development over the last decade, and that's that the underlying technology is now a lot less experimental.
Wind back to 2010, and websockets was new and fun, webRTC was coming up, there were loads of interesting possibilities about how the web could be used, HTML5 was new/coming, compilers (sass, gulp, etc.) were perceived as a benefit as they took away from common repetitive tasks, KnockoutJS and Ember were trying new approaches (that eventually turned into Angular/React/Vue).
It felt like the possibilities were endless, and the future was ours for the taking.
Now, it feels like we (as the global web community) have entered a period of stability - all of the decisions have been made.
- Frameworks win (and broadly speaking, React, Angular and Vue are all very similar to use, give or take a bit).
- You need to write tests, because front end applications contain more behaviour (which used to belong to the backend)
- Build tools win for a host of reasons (babel allowing future JS features early, type checking, etc.). (As an aside - the logical conclusion of lots of nice build tools is... lots of nice build tools (and therefore boilerplate))
- Experimental technologies (webrtc and web sockets, among others) are "gimmicky" or "niche" - useful in small amounts
- Designs are all the same (hyperbolically speaking) - want a product page? give it a horizontal three-column layout showing a free tier and two pricing options. Use Bootstrap, or roll something out that approximates it.
For me, there used to be an excitement that there could be a new core frontend web technology every few months - that excitement doesn't exist now.
But... that doesn't mean that it's not fun to work in web development anymore. It is the people that have changed and become more limiting, not the technology and possibilities (which have only grown over the last 20 years). And by people, I mean you (you're not 14 anymore), me, clients, managers, users - everyone.
Honestly SCSS is what I middleware-in first even in toy-sandbox projects. Writing CSS without humane //-commenting syntax and hierarchical definitions is so annoying.
install install install
Everyone is okay with installs (yarn helps with caching downloads, which npm failed to do). The hard part is configure configure configure and then deal with the fact that every few months your config gets deprecated, keys renamed, docs not in sync, and most SO answers talk about one of the older, unspecified versions.
I work for a company that mainly does custom enterprise intranet webapps. We mainly use PHP (7+), jQuery, jQuery UI, SSR templates and a really old orm (with custom patches). With all the shit these components usually get, it's been the most comfortable experience with web development I have ever had
I feel their pain to a degree, but this also reminds me a bit of someone who says 'When I was young, I loved building tree houses in my backyard with a couple of boards and some nails, now as a structural engineer, I have to do all sort of awful work like material takeoffs, load analysis, job site scheduling--it just isn't fun anymore!'. That's the nature of real work--small hobby projects or simple gigs are easy for a single person to write, but as soon as you bring multiple engineers, legacy system integrations, infosec reqs, etc. things get complicated quickly. It's a big ecosystem out there though, and people are inventing new way to work all the time (Hotwire and Sapper both have interesting ways of doing things compared to the current status quo). All that to say, I hope they find their bliss, and maybe a chance of scenery will at least help remotivate in the face of fatigue with their current set of frameworks.
I'm in the same boat as OP, although a little older. I started my HTML journey around 2000 and have been working as a "front-end" since graduating in 2007.
I think the complexity in front end has been driven primarily by two things:
1. business demands pushing a lot of innovation in FE. Ultimately this is a good thing but it means more complexity, nowadays i mostly write non-JS JS, that is code that needs to be compiled into "real" JS. So the scope of complexity of non JS is almost unlimited and now webassembly :) - wont be long until i'm asked to edit Rust files that compile into jS haha
2. Node JS pushing us FE guys onto the server side and CLI side of things. Suddenly we are expecting to be masters of UI dev with sense of design and UX and also coding for the server and now also writing tests!!!. - I have exactly zero interest in writing tests.
---
Unfortunately 95% of jobs now at least "expect" you to be comfortable in all these areas. Ultimately we are to blame as we are the ones who are pushing the boundaries of innovation, creating new tools and libraries to make our jobs easier/more complex(?) which feeds into creating more and more unrealistic expectations from us.
I am at the point now reaching my 40s looking for some other field to move into....As I don't think i can do this work much longer unless there is a trend of specialistation that will emerge soon.
Edit: Also one other thing to note, a lot of the new guys entering this field in the last 5-10 years are VERY dogmatic and don't really share the principle of if it works it works. They tend to be very much opinionated on having to do things in a certain way. This is why you get a lot of people who have trouble thinking outside of a "React" box (or whatever) and don't seem to understand most of these libs are progressive and there is nothing wrong with combining different approaches to meet your needs. It's like jQuery or imperative JS is a dirty word nowadays. Or that theres nothing wrong with building a static html file with a little js and css without the need for npm packages or some generator/build process.
It is a do-over for front end development: rather than trying to address the shortcomings of HTML as a hypertext by adding in more javascript, it addresses the shortcomings directly.
I think you will find it to be a much more simple and understandable way to work on front end development.
That being said, the first backend task will be "picking up a language", then "install the package manager for this language", then "install the build tool for this language", then "setup docker to create cloud-ready artifacts for the backend", then... etc.
Of course, it's still possible to fire up a text editor and write your pure HTML / CSS / JS web page by hand, put it on a server, and get things done.
Just like it's possible to fire up a text editor, and write your simple backend code in... wait a sec, no, you at least need a compiler or interpreter for that. Anyway. For which language again ;) ?
Let's hope the author gets more excited by his or her next job.
I kind of sympathize with the author, but when again it is bad requirements that make things complicated. I like to follow the concept of Boring Technology
I built a CRUD dashboard with some data scraping and parsing capabilities for a friend recently, and because I could define what I used, i kept it simple and relatively boring
The stack AppEngine (NodeJS), Google Cloud Tasks, BigQuery, Postgres and FireStore as a redis equivalent for session cookies. The front end has Zero JS, the app does not need anything fancy. I am using Nunjucks for templating and Tailwind for CSS.
The stack seems large, but I have zero devops work, and the DB is the only thing that keeps running all the time.
[+] [-] Doctor_Fegg|5 years ago|reply
> I've given in my resignation at my current place of employment and will be seeking an exclusively back-end role for my next adventure
Oh boy. I sympathise entirely with this post, but the story's exactly the same on the backend.
Kubernetes. Docker. AWS and its gazillion impenetrable product names. The days of security updates, pentests, honeypots and captchas you have to go through in order to put up a webapp that won't be commandeered by (insert bad guy here) within hours. The endless cycle of breakage on your server because LetsEncrypt or whoever have upgraded their crypto libraries to fight against (insert bad guy here).
The need for a lawyer to write you a privacy policy before you can let people log into your site. The endless bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. And even then it's better than dealing with email verification because Gmail/Hotmail will kill your emails anyway.
The complicated web is everywhere. Retreating to the backend is no escape. Sorry.
[+] [-] sriku|5 years ago|reply
The stacks run deep on both ends .. but I'm often not sure to what end.
[+] [-] jaeming|5 years ago|reply
I guess the difference between us is I'm in JS everyday while he's primarily backend. I've made peace with my tooling as has he. I've also made peace with the fact that my tooling is going to continue to change every few years. From Gulp to Webpack to Parcel to Snowpack and onwards.
[+] [-] justsomeuser|5 years ago|reply
I don't think it is, for the business-logic code portion any way.
For backend, the hiring is typically "you know Java" or whichever $backend_language.
For frontend, your job application will be terminated in the early stages of the pipeline because you do not know the latest 2 year old framework (that is written in JS that you know extremely well).
10 years of JS and web experience amounts to nothing because "you do not know Angular". I do not think this applies to backend at all, they just see a "langauge-X developer".
[+] [-] rzzzt|5 years ago|reply
[+] [-] durnygbur|5 years ago|reply
[+] [-] vmception|5 years ago|reply
That reminds me, there should be a mandatory session variable that tells you which of those you actually use to sign up/in
[+] [-] sai_c|5 years ago|reply
So maybe, just maybe, not everything should be a web app, and be connected to everything.
EDIT: Corrected typo.
[+] [-] higerordermap|5 years ago|reply
[+] [-] codegeek|5 years ago|reply
[+] [-] gorpomon|5 years ago|reply
The build pipeline complaint also strikes me as hollow. Create React App outputs folder you can drag and drop onto a server and serve, same for Angular and I would assume Vue. Yes, it is a lot of JS from a ton of NPM libraries, but that's the trade-off when you get an entire ecosystem of code for free. If your application is security critical then consider either writing your own libraries or hosting security vetted copies of the libraries.
The real reason to leave this industry is that it's all the same work at the end of the day. Despite what application you build, whether it's a social network, a security application or collaborative tool like Figma or Trello, it all runs together as a mish-mash of views, data and DOM elements. Unless you're really invested in the product, it becomes hard to maintain enthusiasm. You can only roll a CSS library, or auth scheme or API library so many times before you're ready to start some new adventures in coding.
[+] [-] alpaca128|5 years ago|reply
So far I haven't met a user who asked for ads, unmuted autoplaying videos, popups, tracking, loading screens, and UI that's basically broken by design. Did Google really redesign Google Images' UI due to popular demand? I doubt it, because the new one only works 80% of the time when I try to use it.
Most websites that are obviously built using modern frameworks and shiny layouts don't let me open links in new tabs, not to mention they're a nightmare for screenreaders and similar tools. And considering how often terms like "responsive" are thrown around it is staggering how easy it is to break many of those sites just by resizing the browser window.
In some aspects I'm definitely not the typical user, but to quote Adam Jensen: I never asked for this.
[+] [-] ryanbrunner|5 years ago|reply
In my day job, I write server-generated HTML for a growing and successful startup, without React, front-end frameworks or a particularly complicated front-end build setup (we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense), and the user experience is comparable with many other web apps I use, some of which are almost certainly full-fledged SPAs, and is well-loved by our users. My team's productivity is easily double what I've experienced at jobs using the latest and greatest technologies.
Could I use this approach to build Google docs? Probably not, but then again, that's not what I'm building, and I don't need a tool capable of building that.
[+] [-] hexo|5 years ago|reply
Oh my, for example I never asked for smooth scrolling (I've actually disabled it in browser), instead someone insists on it and forces that on me with some javascript. Thanks, but no thanks.
I can't even have my own scrollbars from system theme most of the time (why even this?!).
What we have now is ultra slow interaction because of tons of JS. Constant cpu usage and battery drain. And most importantly boundless memory hogs such as oh so great interacting facebook that easily eats 2.5gigs of memory.
And don't get me started about "effects", animations, fades, stolen keyboard shortcuts, right clicks and every other bit that throws accessibility out of the window.
[+] [-] twuersch|5 years ago|reply
Agree with everything you're saying, except for this.
I do user research as a job, which means that it is my day job to methodically interview and observe people using everything from web sites to apps to enterprise software. So far, I've had the privilege of doing so with more than 100 users.
What users expect is things that work quickly and reliably to get their job done, and then get out of the way. It doesn't matter whether they're booking a flight, buying cell phones or working in a complex workflow system.
Nobody, on the other hand, really wants bloated pictures, autoplaying videos, and dozens of different features without practical use - except for marketing people and managers.
[+] [-] tomiplaz|5 years ago|reply
Do they, though? Or is it the product managers who insist on such things? I'd put more weight on them. Some of it might be backed by user data, but generally it feels like they're pushing things unjustifiably or for wrong reasons.
[+] [-] vagrantJin|5 years ago|reply
Nope
Im going all on anecdote. Consider my SO is a youtuber and spends her days doing research for her videos, as do her friends on Tiktok and Insta. Not once has she ever mentioned any expectations despite my asking. She didnt even care about the cool "web app experience" from YT. I don't even think she cares about what I do.
Just because we over-engineer things to justify our absurd but nice salaries in the name of maintainability and More speed - more power does not make the mountain of dung smell any better.
[+] [-] catmanjan|5 years ago|reply
Have they? I don't see that in my user stories
[+] [-] tootie|5 years ago|reply
> Unless you're really invested in the product, it becomes hard to maintain enthusiasm.
+100 for that one. I spent a lot of time working on some absolutely bleeding edge crazy tech for a shitty client who made some stupid luxury product for rich people. Now I'm working on some 10 year old crufty web app for a non-profit that produces something of genuine public benefit and I'm more satisfied with my work than I have been in a long, long time.
[+] [-] sneak|5 years ago|reply
I'm pretty sure that this is not true. You can ship great webapps without any of that overcomplicated nonsense. We're using one such right now.
[+] [-] jiofih|5 years ago|reply
[+] [-] jariel|5 years ago|reply
OR - the means by which we produce systems is vastly more complicated than it needs to be.
In other words: HTML is designed for nice, light pages, but it's otherwise a steaming hot mess upon which to build single-page apps etc..
We are building the future on a few layers of archaic tools and the result is massively leaky abstraction.
So yes - our toolsets will inevitably expand to make all sorts of useless complexity - that will always be the case.
But for doing basic/cores stuff, it should be possible to avoid the trap.
[+] [-] jamil7|5 years ago|reply
[+] [-] YorickPeterse|5 years ago|reply
Users absolutely don't give a shit about you using Grunt, Gulp, Burb, Babel, and the billions of other tools. They just want to pay the meal they ordered online.
[+] [-] tim333|5 years ago|reply
[+] [-] braveyellowtoad|5 years ago|reply
[+] [-] brailsafe|5 years ago|reply
[+] [-] j45|5 years ago|reply
Most sites and apps want users to click and engage as much as possible, not necessarily the most efficiently.
[+] [-] asdofindia|5 years ago|reply
[+] [-] collyw|5 years ago|reply
[+] [-] itronitron|5 years ago|reply
[+] [-] mac_was|5 years ago|reply
[+] [-] iSnow|5 years ago|reply
I originally came from Java and was so fed up with the hulking class lib and the arcane build systems sprinkled with Ant snippets and XML galore, so JS felt like a fresh breeze.
AngularJS was a bit convoluted and the syntax was not nice. But OK, data binding was nice. Bit like dependency injection on the Java side made the code much harder to reason about but helped build certain classes of applications.
Angular 4 was just WTF. Somewhat cleaner module system but now with a clunky OOP language instead of the elegant functional expressions that JS had and Java finally adopted. For which reason exactly?
And I tried Vue which is a much lighter framework but like Angular, the build system is just retarded. Instead of many dozens of JARs with dozens of sub-dependencies, modern JS goes for the kill and literally imports several hundred of npm package with thousands of dependencies.
And in the end, I end up having to use "browserify" to have JS running in a browser. It's a clowns world in IT, but modern JS really takes the cake. I'm back in backend, solving real problems instead of wrangling my build chain.
[+] [-] nicbou|5 years ago|reply
In hindsight, I just didn't enjoy writing code for money. When I left my last programming job, I started programming for fun again. It wasn't a deliberate effort, but something that happened on its own.
If you program for fun, you don't have to learn anything. You don't have to use webpack or SCSS if you don't want to. You don't need to write tests. "oops" is a valid commit message and "bugger off" is a valid response to stakeholders.
[+] [-] yuchi|5 years ago|reply
Apparently the author has always worked on their own projects, with its own (or its team’s) discipline. Let me state this: old-school front-end is a mess once you have to mantain an enterprise-grade application.
npm is pure joy to work with, in comparison with a huge mess of copy-pasted files in a “vendors” directory (if you are lucky enough to have such a directory! currently I’m working on a project where developers copy-pasted the content of JS libraries one after the other in a single “lib.js” file… for years!)
Front-end development has now reached a very fine situation regarding code hygene and modularity — and this makes me very happy to be on the front-end side.
[+] [-] flucivja|5 years ago|reply
[+] [-] bwindels|5 years ago|reply
The good news is that there is another way. It's completely feasible to develop without any tooling but a static web server and a browser nowadays. Just bundle for production.
I've developed [1] (a +10k LoC chat app) and [2] (a small web app) using just a 600 LoC template library [3] (which I should really extract), and I vastly prefer it over more traditional setups. Being so close to the browser makes it so easy to see what is going on. I've never spent hours or days debugging the infrastructure code because there is barely any, which is usually what ruins the fun for me.
Everybody is different, but for me the accidental complexity of the commonplace front-end stack (webpack, react, typescript, ...) isn't worth what you get out of it.
1: https://github.com/vector-im/hydrogen-web 2: https://github.com/matrix-org/matrix.to 3: https://github.com/vector-im/hydrogen-web/blob/master/src/pl...
[+] [-] ironmagma|5 years ago|reply
As much rhetoric as there is about this being the frontend, the backend is worse. "Backend" is just defined as "anything that isn't the frontend" so the word casts a wide net. There's everything from logging and metrics to databases to pipelines and task managers to physical hardware and networking tools.
That said, it's always good to have a variety of knowledge and experience. The backend is nice because it doesn't rely on visual output as much and so you can code more without context switching between the editor and the browser. And it's incredibly easy to get pigeonholed into writing frontend code only. So many companies seem to be unable to let go of the fact that you have some specialization.
[+] [-] hellwd|5 years ago|reply
[+] [-] locallost|5 years ago|reply
It used to be difficult to get anything done. It was kind of, at first figure out how you will even get this complicated design to work. And every time you thought you had it, it turned out no, something broke in IE. This part got progressively better, to the point that I don't really test in multiple browsers anymore. But as things got easier, we found ways to make it complicated in other areas. And we can do nice things, but sometimes they don't add that much, yet cost a lot in terms of effort.
There is some pain and friction with colleagues that always want to do something new because others do it. When you get older you stop caring about that, and want to keep things simple and replace things that are an actual problem. As others have pointed out, this is the same in any area. We had a discussion what to do a couple years ago, and one colleague was dead bent on using GraphQL for an API. He's good at his job, but the answer to why was basically "because others do it". We didn't and we're fine -- we didn't need it. So you're going to get that pressure to learn new things everywhere. I don't have a good answer to this other than focusing on learning things that will last, even beyond this one area of work. But figuring out what that is can also be difficult.
[+] [-] danielstocks|5 years ago|reply
One reason for the growing complexity in UI tooling is that many websites we build today compared to 10 years ago are not "stupid little web pages containing youtube embeds and guest books"
With that being said, many people are still building simple websites, and React/TypeScript/Webpack/Babel/CSS-in-JS/et al. probably isn't solving any "real problems" for them.
I've had to learn and adapt during my whole career, but I'm also more productive today than I've ever been, thanks to the tools that are available to me as a front-end developer.
I still reach out for Vanilla HTML/CSS/JS now and again, but I mostly deal with large and complex UI's that need to be shared across multiple projects and hundres of developers.
From a historical perpsective: jQuery solved a very real problem at it's time: simplifying and doing consistent/reliable cross browser JS development. Backbone.js later came along to solve the problem that JavaScript apps were now so large and complex that simply dropping a few JavaScript/jQuery files was not a scalable way to build. As applications became even more complex, React.js made it easier to deal with UI/state changes in large code-bases. All of these abstractions grew out of necessity.
[+] [-] gherkinnn|5 years ago|reply
Learn one set of tools really well. Make sure it's here to stay, mature, and has a large community. My fav is Nextjs, but it could be anything. Make sure it comes with everything you need, including a CLI to set up your project. Stay as close as possible to what the stack gives you. Don't build on top of it, unless you're willing to upgrade constantly. Avoid configuring your build system yourself, unless the framework gives you clearly defined escape hatches. (Like Next does.)
Learn the underlying fundamentals. Learn about algos and data structures. That will be relevant forever.
Most importantly, ignore these "20 state management libraries you should learn in 2021" articles. They are poison. And nobody cares.
[+] [-] shorner|5 years ago|reply
Wind back to 2010, and websockets was new and fun, webRTC was coming up, there were loads of interesting possibilities about how the web could be used, HTML5 was new/coming, compilers (sass, gulp, etc.) were perceived as a benefit as they took away from common repetitive tasks, KnockoutJS and Ember were trying new approaches (that eventually turned into Angular/React/Vue).
It felt like the possibilities were endless, and the future was ours for the taking.
Now, it feels like we (as the global web community) have entered a period of stability - all of the decisions have been made.
- Frameworks win (and broadly speaking, React, Angular and Vue are all very similar to use, give or take a bit). - You need to write tests, because front end applications contain more behaviour (which used to belong to the backend) - Build tools win for a host of reasons (babel allowing future JS features early, type checking, etc.). (As an aside - the logical conclusion of lots of nice build tools is... lots of nice build tools (and therefore boilerplate)) - Experimental technologies (webrtc and web sockets, among others) are "gimmicky" or "niche" - useful in small amounts - Designs are all the same (hyperbolically speaking) - want a product page? give it a horizontal three-column layout showing a free tier and two pricing options. Use Bootstrap, or roll something out that approximates it.
For me, there used to be an excitement that there could be a new core frontend web technology every few months - that excitement doesn't exist now.
But... that doesn't mean that it's not fun to work in web development anymore. It is the people that have changed and become more limiting, not the technology and possibilities (which have only grown over the last 20 years). And by people, I mean you (you're not 14 anymore), me, clients, managers, users - everyone.
With stability come expectations!
[+] [-] wruza|5 years ago|reply
install install install
Everyone is okay with installs (yarn helps with caching downloads, which npm failed to do). The hard part is configure configure configure and then deal with the fact that every few months your config gets deprecated, keys renamed, docs not in sync, and most SO answers talk about one of the older, unspecified versions.
[+] [-] neverbuythesun|5 years ago|reply
[+] [-] tommyderami|5 years ago|reply
[+] [-] mouzogu|5 years ago|reply
I think the complexity in front end has been driven primarily by two things:
1. business demands pushing a lot of innovation in FE. Ultimately this is a good thing but it means more complexity, nowadays i mostly write non-JS JS, that is code that needs to be compiled into "real" JS. So the scope of complexity of non JS is almost unlimited and now webassembly :) - wont be long until i'm asked to edit Rust files that compile into jS haha
2. Node JS pushing us FE guys onto the server side and CLI side of things. Suddenly we are expecting to be masters of UI dev with sense of design and UX and also coding for the server and now also writing tests!!!. - I have exactly zero interest in writing tests.
---
Unfortunately 95% of jobs now at least "expect" you to be comfortable in all these areas. Ultimately we are to blame as we are the ones who are pushing the boundaries of innovation, creating new tools and libraries to make our jobs easier/more complex(?) which feeds into creating more and more unrealistic expectations from us.
I am at the point now reaching my 40s looking for some other field to move into....As I don't think i can do this work much longer unless there is a trend of specialistation that will emerge soon.
Edit: Also one other thing to note, a lot of the new guys entering this field in the last 5-10 years are VERY dogmatic and don't really share the principle of if it works it works. They tend to be very much opinionated on having to do things in a certain way. This is why you get a lot of people who have trouble thinking outside of a "React" box (or whatever) and don't seem to understand most of these libs are progressive and there is nothing wrong with combining different approaches to meet your needs. It's like jQuery or imperative JS is a dirty word nowadays. Or that theres nothing wrong with building a static html file with a little js and css without the need for npm packages or some generator/build process.
[+] [-] recursivedoubts|5 years ago|reply
https://htmx.org
It is a do-over for front end development: rather than trying to address the shortcomings of HTML as a hypertext by adding in more javascript, it addresses the shortcomings directly.
I think you will find it to be a much more simple and understandable way to work on front end development.
[+] [-] phtrivier|5 years ago|reply
That being said, the first backend task will be "picking up a language", then "install the package manager for this language", then "install the build tool for this language", then "setup docker to create cloud-ready artifacts for the backend", then... etc.
Of course, it's still possible to fire up a text editor and write your pure HTML / CSS / JS web page by hand, put it on a server, and get things done.
Just like it's possible to fire up a text editor, and write your simple backend code in... wait a sec, no, you at least need a compiler or interpreter for that. Anyway. For which language again ;) ?
Let's hope the author gets more excited by his or her next job.
[+] [-] ravivyas|5 years ago|reply
I built a CRUD dashboard with some data scraping and parsing capabilities for a friend recently, and because I could define what I used, i kept it simple and relatively boring
The stack AppEngine (NodeJS), Google Cloud Tasks, BigQuery, Postgres and FireStore as a redis equivalent for session cookies. The front end has Zero JS, the app does not need anything fancy. I am using Nunjucks for templating and Tailwind for CSS.
The stack seems large, but I have zero devops work, and the DB is the only thing that keeps running all the time.