I don't want to do front-end anymore(askonomm.com)
askonomm.com
I don't want to do front-end anymore
https://www.askonomm.com/blog/i-dont-want-to-do-frontend-anymore
410 comments
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.
The stacks run deep on both ends .. but I'm often not sure to what end.
It actually doesn't have to.
Serving a static site on S3 can make you hundreds of millions of dollars. Of course thats because you put a metamask plugin and cater to crypto people and don't even have to build a backend to do anything impressive there.
But its scalable enough!
Serving a static site on S3 can make you hundreds of millions of dollars. Of course thats because you put a metamask plugin and cater to crypto people and don't even have to build a backend to do anything impressive there.
But its scalable enough!
Fun trivia: for the longest time, lichess.org - which by any measure is a high traffic, hugely interactive web app - was run on... a single server with 8 CPUs and 24Gb RAM[0]
[0] https://lichess.org/forum/lichess-feedback/hardware-of-liche...
[0] https://lichess.org/forum/lichess-feedback/hardware-of-liche...
Agree! One can still Keep It Simple and Stupid (KISS).
Our latest MVP - https://www.code-scope.com lets one interactively analyze and document GBs of source such as linux kernel.
It runs on Digital Ocean's $5 instance, build just with Jquery - bootstrap4.
The app binary that runs code-scope.com website is < 10MB including all the frontend and backend code.
Good old tech such as jquery works very well for us.
Complex js front-end tooling is a choice, not a requirement for develop web app.
Our latest MVP - https://www.code-scope.com lets one interactively analyze and document GBs of source such as linux kernel.
It runs on Digital Ocean's $5 instance, build just with Jquery - bootstrap4.
The app binary that runs code-scope.com website is < 10MB including all the frontend and backend code.
Good old tech such as jquery works very well for us.
Complex js front-end tooling is a choice, not a requirement for develop web app.
KISS remains one of the most under-appreciated principles out there.
I still annoy people by talking about my time at the high frequency trading firm, because working there was a revelatory experience. They were operating at a scale and velocity far beyond any place I've worked at, with lower tolerance for downtime, and very little hardware, relatively speaking. The traders had fun, of course, but it was frankly kind of boring to work there as a techie, what with everything ticking along so smoothly all the time.
And the way they got there was through an absolutely fanatical devotion to the KISS principle.
I still annoy people by talking about my time at the high frequency trading firm, because working there was a revelatory experience. They were operating at a scale and velocity far beyond any place I've worked at, with lower tolerance for downtime, and very little hardware, relatively speaking. The traders had fun, of course, but it was frankly kind of boring to work there as a techie, what with everything ticking along so smoothly all the time.
And the way they got there was through an absolutely fanatical devotion to the KISS principle.
Too often I see developers not thinking about KISS, produce very complex and slow systems. And as a solution to improve the performance, they decide to throw 10x more cloud infra against it instead of thinking a bit harder.
Especially with the current popularity of scale out as a golden hammer.
I've come to think that scale out is a self-fulfilling prophecy. If you choose a solution that's designed to support scale out, then all the mechanisms and limitations (yes, limitations) it needs to adopt in order to make distributed processing work will impose a burden of overhead that you will need to offset by scaling out.
I've come to think that scale out is a self-fulfilling prophecy. If you choose a solution that's designed to support scale out, then all the mechanisms and limitations (yes, limitations) it needs to adopt in order to make distributed processing work will impose a burden of overhead that you will need to offset by scaling out.
It's actually sad to see that scale-up almost disappeared, especially considering the insanelly powerful HW we have now, just NVMe SSDs are game changer for anything I/O bound.
I remember how few years back there were some people in our company completely floored when they learned that StackOverflow ran on 1 SQL server (quite beefy though, 1TB RAM IIRC). Similar 'cloud' (aka 'someone else's datacenter') setup would cost significantly more, but that seems to be forgotten/forbidden knowledge these days. I guess people need to justify those cloud technologies certificates.
Yes, exactly. I don't want to call it the 'new' generation but many have seem to forgotten how efficient systems can be if you build them properly.
I haven't seen any certificates that replace sweat and hard work yet, except in organizations where they cannot keep track of individual developer performance and simply count certificates.
I haven't seen any certificates that replace sweat and hard work yet, except in organizations where they cannot keep track of individual developer performance and simply count certificates.
[deleted]
Do you happen to know of any best practices guides that might help others achieve similar results? I’m working on an app that might have to scale very quickly at launch, and I want to do my best to help our team do it right.
No, I don't. And the specific practices at this company would be unpalatable to almost anyone. Package managers for dependency management, for example, were banned, because they made it too easy for the dependency list to grow in an uncontrolled manner.
There was a lot of homegrown software where others would use a library. That was deliberate. If you need five features, but choose an off-the-shelf package with 5,000 features, pretty soon you'll find that the list of features you're using has grown to 50, then 500, and so on, even if you don't actually need any of it. If a toy's in the box, the kids will play with it.
Maybe one thing to try is to focus on imposing constraints, and making people live within them. RAM, # of CPU cores, whatever. Software is like a gas. It will naturally expand to fill all available space.
There was a lot of homegrown software where others would use a library. That was deliberate. If you need five features, but choose an off-the-shelf package with 5,000 features, pretty soon you'll find that the list of features you're using has grown to 50, then 500, and so on, even if you don't actually need any of it. If a toy's in the box, the kids will play with it.
Maybe one thing to try is to focus on imposing constraints, and making people live within them. RAM, # of CPU cores, whatever. Software is like a gas. It will naturally expand to fill all available space.
Simple advise. Start with a 5 dollar droplet and increase ram / disk speed when required. If you reach 64 gigs consider spliting.
What I do is put my database on a droplet and my files on another and it can handles millions of requests. Put them on the same machine and I need to increase ram higher than the cost of multiple small droplets.
If you ever reach those limits consider setting up a load balancer.
What I do is put my database on a droplet and my files on another and it can handles millions of requests. Put them on the same machine and I need to increase ram higher than the cost of multiple small droplets.
If you ever reach those limits consider setting up a load balancer.
In https://www.code-scope.com, the source code search engine database is in the same $5 droplet that run webserver - We are cheap. It is part of <10MB app which hopefully anyone can download soon. We figured the SSD can do 1-3GBs/second transfer, no point to slow it down with separate process or worst, separate network node.
All the web queries are responded in <<< 1 second - so far....
All the web queries are responded in <<< 1 second - so far....
This is good, and it works well. The issue (as others may have pointed out) is not that simple apps _can't_ be produced, it's that they _won't be accepted_ when they are. The same thing happened to TCL/Tk ... it "doesn't look right" so is dismissed. By and large, the driving force seems to be those who want to pay for "sexy dashboards", usually but not limited to those whose primary motivation is initial impact. Aesthetics are everything - functionality is secondary. Snake oil sells. Things that "look old" are laughed out of the room. It's unhealthy.
I built a static site served by S3 & cheap Lightsail boxes that serves a $5B/yr business.
That was 4 years ago and beyond basic patching they've barely touched their infrastructure and it runs around $100/mo.
That was 4 years ago and beyond basic patching they've barely touched their infrastructure and it runs around $100/mo.
"that serves a $5B/yr business."
Ok but is that static site primarily generating the $5B in revenue ? That's more relevant to know. Having a static site for a business where the revenue is generated elsewhere is not that big of a deal in my opinion. Yes I get your point that the $5B company is hosting a static site on S3 which is cool but what will be cooler is if THAT static site is the primary revenue driver. I bet it isn't.
Ok but is that static site primarily generating the $5B in revenue ? That's more relevant to know. Having a static site for a business where the revenue is generated elsewhere is not that big of a deal in my opinion. Yes I get your point that the $5B company is hosting a static site on S3 which is cool but what will be cooler is if THAT static site is the primary revenue driver. I bet it isn't.
I think it's more along the lines that a $5B/yr business would typically have gone to a large contracting firm, and the resulting solution would have been over-engineered with all of the front and back-end stuff and resulted in a higher cost to solve the same problem.
^ You got it completely. Thank you.
Actually probably the output would be worse, because there's a significant amount of domain knowledge in building an effective website in this space. The only companies that are effective at it do it in house or go to specialists in the space.
Car dealership advertising is actually extremely similar in this regard. There are just a few big players working with hundreds to thousands of dealers.
Actually probably the output would be worse, because there's a significant amount of domain knowledge in building an effective website in this space. The only companies that are effective at it do it in house or go to specialists in the space.
Car dealership advertising is actually extremely similar in this regard. There are just a few big players working with hundreds to thousands of dealers.
I tried to imagine what kind of website could generate $5B without requiring more than $100/month of hardware. Seems impossible.
Just take a look at the top 10 adwords keywords and let your mind wander. Our business touched 4 out of 10...
Found in a random blog post, top 10 keywords:
- Insurance
- Loans
- Mortgage
- Attorney
- Credit
- Lawyer
- Donate
- Degree
- Hosting
- Claim
Still can't see it. But just to be sure, you're saying that the $100/month website was directly generating most of that $5B?
And not, for example, being just a bridge between users and an army of attorneys?
- Insurance
- Loans
- Mortgage
- Attorney
- Credit
- Lawyer
- Donate
- Degree
- Hosting
- Claim
Still can't see it. But just to be sure, you're saying that the $100/month website was directly generating most of that $5B?
And not, for example, being just a bridge between users and an army of attorneys?
Qualified leads are king in that business.
Keep in mind that a large number of law firms in this space do not try cases and just generate and sell leads.
Yes, obviously there's a lot more that goes into it, but my point was that websites can be extremely simple in their infrastructure and still be extremely effective.
Keep in mind that a large number of law firms in this space do not try cases and just generate and sell leads.
Yes, obviously there's a lot more that goes into it, but my point was that websites can be extremely simple in their infrastructure and still be extremely effective.
The online property only accounts for about 10% of the total ad spend (over $200M/yr). The website accounts for exactly 0% of the bread and butter (high volume, low profit) business, but easily 60% or more of the the rest of it (low volume, absurd profit).
I've talked at length about it before in comments. Not really looking for the repeat discussions.
I've talked at length about it before in comments. Not really looking for the repeat discussions.
This use case is about where AWS cost effective scalability ends, anything more complicated and you are into multiple thousands a month for a redundant solution for a critical web-app with a database. We used to run prod and stage envs in aws but as our stage environment grew we realized we could on-prem some pretty bad-a* hardware for the cost of a few months AWS billing. Now we run prod on aws, staging and dev locally.
There's a cost maintaining a staging environment on-prem while prod is on a cloud. Slightly different versions of databases, different networking, etc... It could create issues. This does depend on how much you buy into the AWS ecosystem, if it's strictly EC2-only it's not as much of a problem.
Not that I wouldn't do it, a lot of times it does make financial sense.
Not that I wouldn't do it, a lot of times it does make financial sense.
Second that.. and hardest thing is you don't really know where you are getting charged. i mean you can look at the billing but boy they do add up to 1000s before you know and you are so hooked into auto scaling, s3, rds with multi-az what not..
You don't exactly need to tell me. I have 10^4 machines in multiple clouds right now plus more n datacenters. Cost effective scaling is hard, but you have to design your applications around it.
Tbh, I find most engineering orgs don't have the competency to pull it off.
Tbh, I find most engineering orgs don't have the competency to pull it off.
It's basically about money. As a tech guy, you choose the technologies with the largest margin. Companies who use AWS are either (1) rich enough to spend huge sums of money, (2) can't calculate or are gullible enough to believe it's the best solution for them. In either case, typically you're more likely to make money on AWS-related technologies than working for more cost-conscious clients who understand the cost structure of the overall infrastructure. That's why people code a Hello World as a React app on AWS, as ridiculous as it may seem.
This is absolute nonsense which reveals more about your ignorance of companies’ technology trade offs than it does anything else.
Consider for a moment that other people might in fact not be idiots, and might have legitimate reasons for choosing particular technology stacks that your snarky attitude has missed.
Consider for a moment that other people might in fact not be idiots, and might have legitimate reasons for choosing particular technology stacks that your snarky attitude has missed.
> Consider for a moment that other people might in fact not be idiots
I've considered it many times, but I continuously find evidence to the contrary.
I've considered it many times, but I continuously find evidence to the contrary.
My guess is that > 90% of people using Kubernetes will never need to scale elastically. My company uses it, cost a ton of developer time. It gives us high availability which is nice, but we have no need for the scaling in the foreseeable future, and that was what was used to sell Kubernetes to our founders.
I see this sentiment a lot online, but k8s for us has been quite simple to learn and use and, like you acknowledged here, solved a lot of availability issues out of the box for us that we previously had to deal with in more manual ways. Better yet, it’s a standardized platform that we can use company-wide and that every engineer understands, including potential hires — that’s very valuable. I feel it has become a common trope to claim k8s is complicated and overkill but we are quite glad we made the move to using it.
Have you ever considered the workforce aspect of technologies? Like, you'll still need devops, and if you aren't at least dabbling in containers and elasticity, you're going to get the luddites.
Yes, though the GP made no reference to Kubes at all and was talking more generally about AWS.
AWS has an absolute tonne of great and not so great services but you can easily use the basic stuff to get quite simple and cost effective solutions. You can YOLO it on the console and not even worry about cloudformation if you want, and if you have no customers it will likely be free tier to boot.
AWS has an absolute tonne of great and not so great services but you can easily use the basic stuff to get quite simple and cost effective solutions. You can YOLO it on the console and not even worry about cloudformation if you want, and if you have no customers it will likely be free tier to boot.
Kubernetes was not mentioned by the comment I replied to, which was about AWS.
Even then, your founders might have made a bad business decision – which isn't unusual, and companies can often make bad business decisions, such as prioritising investment in scalability when it's not a required feature.
They can equally make good business decisions – such as rolling out a relatively standard technology like Kubernetes to gain the workflow and availability features, even though scalability is not required.
I agree that it is important to remember that sometimes "old-fashioned" approaches can be totally suitable for some use-cases, and they can be too often written off. But equally let's try not to assume that everyone who rolls out a particular modern technology stack is a gullible fool.
Even then, your founders might have made a bad business decision – which isn't unusual, and companies can often make bad business decisions, such as prioritising investment in scalability when it's not a required feature.
They can equally make good business decisions – such as rolling out a relatively standard technology like Kubernetes to gain the workflow and availability features, even though scalability is not required.
I agree that it is important to remember that sometimes "old-fashioned" approaches can be totally suitable for some use-cases, and they can be too often written off. But equally let's try not to assume that everyone who rolls out a particular modern technology stack is a gullible fool.
I haven't called anybody idiots. There are genuine reasons for using AWS specifically. I've been consulting to several companies helping them to manage their infrastructure, and more often than not it turned out that they chose AWS "because everybody is doing it", not because they understood the tradeoffs well.
To be more specific: (1) they were not able to calculate the overall costs upfront. Yes there are many calculators, but you know the actual cost only when you receive the bill. Moreover, there is no hard cap on costs - people have been asking for it since 2006, and AWS was first saying they understand it's important and will take care of it, but in the end decided to ignore it.[0] Yes, you can set up alarms but that's not what people want. (2) AWS is marketed as saving on IT staff costs but it's ridiculous: you need competent staff to support it. The AWS infrastructure is huge, it's a whole ecosystem in itself, and it has its particular quirks. You definitely need smart people to run it and stay out of trouble. (3) Very often when you run a cost analysis of a particular aspect (like storage, processing etc.), it turns out the difference between AWS and, say, bare metal is enormous and, consequently, increases radically with the amount of resources used. There are several large companies who decided to move from AWS to bare metal just for this reason, saving enormous amounts of money.
Now, there are several scenarios where it doesn't matter, or it matters but it makes sense to use AWS anyway, but in my personal experience this is minority of cases I had to deal with. I have nothing against AWS per se - also, there are some aspects of AWS infrastructure that are a pleasure to work with. Nevertheless, usually it makes more sense to use a whole ecosystem, and the more you get locked in, the more difficult is to get out, and the sunk cost fallacy is omnipresent among companies of all sizes.
[0] https://forums.aws.amazon.com/thread.jspa?start=50&threadID=...
To be more specific: (1) they were not able to calculate the overall costs upfront. Yes there are many calculators, but you know the actual cost only when you receive the bill. Moreover, there is no hard cap on costs - people have been asking for it since 2006, and AWS was first saying they understand it's important and will take care of it, but in the end decided to ignore it.[0] Yes, you can set up alarms but that's not what people want. (2) AWS is marketed as saving on IT staff costs but it's ridiculous: you need competent staff to support it. The AWS infrastructure is huge, it's a whole ecosystem in itself, and it has its particular quirks. You definitely need smart people to run it and stay out of trouble. (3) Very often when you run a cost analysis of a particular aspect (like storage, processing etc.), it turns out the difference between AWS and, say, bare metal is enormous and, consequently, increases radically with the amount of resources used. There are several large companies who decided to move from AWS to bare metal just for this reason, saving enormous amounts of money.
Now, there are several scenarios where it doesn't matter, or it matters but it makes sense to use AWS anyway, but in my personal experience this is minority of cases I had to deal with. I have nothing against AWS per se - also, there are some aspects of AWS infrastructure that are a pleasure to work with. Nevertheless, usually it makes more sense to use a whole ecosystem, and the more you get locked in, the more difficult is to get out, and the sunk cost fallacy is omnipresent among companies of all sizes.
[0] https://forums.aws.amazon.com/thread.jspa?start=50&threadID=...
This analysis is spot on, and well worth the time to consider.
Linux has far fewer networking and scaling issues as it once had, something that cloud helped with.
VPS servers are more capable than ever, and the manageability might surprise some who know cloud as the only way. It's not the only way, but it can be valid now often than realized.
VPS servers are more capable than ever, and the manageability might surprise some who know cloud as the only way. It's not the only way, but it can be valid now often than realized.
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 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.
Am I the only one that doesn't mind the changes? The move from Gulp to Webpack to Rollup to now Snowpack aren't really big heavy architectural upheavals, but I suppose many people haven't written module bundlers from scratch as a learning exercise.
As is the case with much of the front end tooling, once you peel back the curtain, it isn't too terribly complicated. The biggest issue is following the data transformations through the code base because JS being a dynamic language, a lot of magical transformations can happen, but thankfully TS and other compile-to-js languages are helping a lot on that front.
Meanwhile, trying to peel back the layers of k8s, the authors of which seemingly hellbent on bringing Java-esque levels of over-engineered, over-architectured coding styles to a language which ironically supports simplicity and readability over all is a brain melting exercise. I understand Paxos and SAML better than most modern backend cloud tooling codebases. Then like a parent commentor mentioned, throw in AWS services soup in the mix, call services that have a mixture of async and sync calls with a nice mixture of some responses being consistent, some eventually consistent, some probably consistent, throw some observability, and control and data planes and you got a nice recipe for a big bowl of spaghetti you will truly never understand.
But everyone demands these things now, so what are you going to do.
As is the case with much of the front end tooling, once you peel back the curtain, it isn't too terribly complicated. The biggest issue is following the data transformations through the code base because JS being a dynamic language, a lot of magical transformations can happen, but thankfully TS and other compile-to-js languages are helping a lot on that front.
Meanwhile, trying to peel back the layers of k8s, the authors of which seemingly hellbent on bringing Java-esque levels of over-engineered, over-architectured coding styles to a language which ironically supports simplicity and readability over all is a brain melting exercise. I understand Paxos and SAML better than most modern backend cloud tooling codebases. Then like a parent commentor mentioned, throw in AWS services soup in the mix, call services that have a mixture of async and sync calls with a nice mixture of some responses being consistent, some eventually consistent, some probably consistent, throw some observability, and control and data planes and you got a nice recipe for a big bowl of spaghetti you will truly never understand.
But everyone demands these things now, so what are you going to do.
>> once you peel back the curtain, it isn't too terribly complicated
I am not sure if anyone has mentioned it already but in my experience, oftentimes it is not the particular 'complexity' of what is revealed 'once you peel back the curtain', but rather the sheer number of different curtains that must peeled in order to build a 'modern' solution.
My gut impression is also that the challenges are more about aggregate-quirks across the many tools that comprise a solution than it is due to the aggregate-complexity.
I am not sure if anyone has mentioned it already but in my experience, oftentimes it is not the particular 'complexity' of what is revealed 'once you peel back the curtain', but rather the sheer number of different curtains that must peeled in order to build a 'modern' solution.
My gut impression is also that the challenges are more about aggregate-quirks across the many tools that comprise a solution than it is due to the aggregate-complexity.
This illustrates really nicely how the "Full Stack Developer" is becoming more and more impossible to be. It's not enough to know how to set up a couple of servers with routing and IP blacklisting and load-balancing, you have to build a mountain of microservices with an even bigger mountain of tools.
For frontend it's no longer enough to know HTML, CSS, basic JavaScript and maybe JQuery. It's not enough to render static templates on the server. You have to build a SPA with dynamic bindings and a build pipeline with webpack or whatever else.
It's all just ballooned like crazy and personally I found it incredibly hard to keep up with all of it. So I'm trying to transition into either front or back end, so I'm not trying to learn full stack everything anymore.
For frontend it's no longer enough to know HTML, CSS, basic JavaScript and maybe JQuery. It's not enough to render static templates on the server. You have to build a SPA with dynamic bindings and a build pipeline with webpack or whatever else.
It's all just ballooned like crazy and personally I found it incredibly hard to keep up with all of it. So I'm trying to transition into either front or back end, so I'm not trying to learn full stack everything anymore.
I've just come back to standard web architecture these days. Just use Rails, Laravel, or Phoenix. While your compatriots will still be configuring their prettierrc and eslint, you'll have released your first set of features.
Yeah. It's fine for personal projects or small things but good luck convincing a big company that what they really need is 2009 technology nowadays.
Well they are relying on 1995 technology (JavaScript).
This is a weird statement. You are completely ignoring how the JS API in browsers has evolved.
And the parent was calling Phoenix and Laravel, neither of which even existed in 2009, 2009 technology.
Was referring to rails, but sure.
And yes, I was wrong, rails has been around longer than that, it was just a guess.
And yes, I was wrong, rails has been around longer than that, it was just a guess.
It's still called Rails but it's a radically different framework now. 2009 was before the big merge with Merb (a then competing framework).
Is Phoenix really that mainstream now?
The person you're answering said nothing about Phoenix being mainstream, but it's mainstream enough for Discord and Brex to build unicorns on its back.
The reason I've been teaching it myself, despite Elixir being a young, niche language is that I believe it's an ideal choice for a solo-founder or small team trying to build an ambitious web app. It's a tool I personally want to have at my disposal.
Discord is a great model: start with a simple Phoenix app, ship way faster than the competition, build out more sophisticated infrastructure with scale, and then finally rewrite core loops as NIFs (natively invoked functions) that are implemented in Rust. They were in a crowded market with extremely well-funded competitors and they still built a considerable lead in product and infrastructure.
The reason I've been teaching it myself, despite Elixir being a young, niche language is that I believe it's an ideal choice for a solo-founder or small team trying to build an ambitious web app. It's a tool I personally want to have at my disposal.
Discord is a great model: start with a simple Phoenix app, ship way faster than the competition, build out more sophisticated infrastructure with scale, and then finally rewrite core loops as NIFs (natively invoked functions) that are implemented in Rust. They were in a crowded market with extremely well-funded competitors and they still built a considerable lead in product and infrastructure.
Right. I did hear that Elixir and Phoenix works really well for concurrency
I'll bite: What kind of frontend stuff can't be done without HTML, CSS, basic JavaScript and maybe JQuery?
I am not saying those things are insufficient to build good websites and apps.
I am saying it does not matter if they are sufficient on their own. If you want to find professional work as a frontend dev in 2021 you will be expected to learn larger and more complex toolchains.
I am saying it does not matter if they are sufficient on their own. If you want to find professional work as a frontend dev in 2021 you will be expected to learn larger and more complex toolchains.
As a backend dev I have spent a fair bit of time in the last few years fixing shitty outdated frontend stuff. Angular 1, Dojo at present. It would have been so much easier and more maintainable if these apps had been done with server side rending and a bit of JQuery.
I am sure there are plenty of applications in maintenance mode using simpler tech (or possibly not, because the lower complexity means that there are far less bugs?)
I am sure there are plenty of applications in maintenance mode using simpler tech (or possibly not, because the lower complexity means that there are far less bugs?)
> the story's exactly the same on the backend
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 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 don't think it is, for the business-logic code portion any way.
This fine song includes the name of 168 AWS services: https://youtu.be/BtJAsvJOlhM
Brilliant! Tom Lehrer would approve I reckon.
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.
Theory: data lake
Reality: data leak
I'm also tired of all those hyped technologies. Sure, containers, "serverless" etc. are neat and powerful things, but in most cases it reminds me of Top Gear's kitchen blender powered by a V8 engine. Yes, I could use TypeScript, React and a couple other libraries to build that website. But then I also need to handle 3 configuration files and their interactions, wait for the incremental compilation to run through after every change, waste time debugging because the incremental builds got the whole amalgamation into an undefined state and deploying the project now requires its own toolchain and scripts.
Reality: data leak
I'm also tired of all those hyped technologies. Sure, containers, "serverless" etc. are neat and powerful things, but in most cases it reminds me of Top Gear's kitchen blender powered by a V8 engine. Yes, I could use TypeScript, React and a couple other libraries to build that website. But then I also need to handle 3 configuration files and their interactions, wait for the incremental compilation to run through after every change, waste time debugging because the incremental builds got the whole amalgamation into an undefined state and deploying the project now requires its own toolchain and scripts.
>it reminds me of Top Gear's kitchen blender powered by a V8 engine.
sadly, there is no kitchen blender powered by Node.js in the V8 engine.
sadly, there is no kitchen blender powered by Node.js in the V8 engine.
> The endless bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days.
That reminds me, there should be a mandatory session variable that tells you which of those you actually use to sign up/in
That reminds me, there should be a mandatory session variable that tells you which of those you actually use to sign up/in
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.
So maybe, just maybe, not everything should be a web app, and be connected to everything.
EDIT: Corrected typo.
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?
Game development! You can choose whatever tech you are most familiar with and you get to be creative, work on probably the most interdisciplinary area of technology possible.
How do you start with game dev as someone who already knows programming? I've tried to get into it at least 3 different times with different approaches, and could never reach a point where I could make even the most basic of games after hours of Unity articles / Unity projects / YouTube videos / Godot documentation, whatever.
Every time I try I feel like I must be missing something because everyone says it's easy to get into, but all the information I can find is completely useless.
Every time I try I feel like I must be missing something because everyone says it's easy to get into, but all the information I can find is completely useless.
Because game dev isn't about programming for the most part, making game engines is. But that's a whole different beast where hardcore math and all kind of tricks and hacks often considered 'wrong|unmaintainable|bad practices' here on HN rule supreme.
Make a game in the programming language that you know.
Big frameworks like Unity make difficult things easier, but easy things more complicated. I would recommend starting with a simple game, in the programming language you are most fluent with. An example of a simple game would be a minesweeper. An example of a complicated game would be a massive online multiplayer strategic 3D shooter with artificial intelligence... in Unity ;)
Computer games have a few things different than usual applications; you probably don't want to encounter all those differences in your first project. The user interface is generally completely different: instead of dialogs with buttons and input fields, you typically have one window with canvas, where you paint things. (If you also want buttons and input fields, you probably have to implement them yourself on top of that.) Things are in motion, they appear and disappear, interact with each other. You probably want to clearly separate updating of the game state from displaying the game state. (You probably also want to save and load the game state.) In addition to algorihms, there is lot of data: design of the levels, different units which are kinda the same thing but with different parameters and different pictures. (Will you also make a level editor? Or design a clever system for easily describing the level in a plain-text file?) Plus the details that still require lot of work, like the intro screen, help screen, option screen, high score table, etc. Plus you sometimes need to care about performance; a one-second delay to e.g. calculate the proper path through a maze may be unacceptable, because it would make the game freeze for a moment every time you command a unit to go somewhere. For network games, performance is even more complicated. You need to make semi-arbitrary choices about object dimensions, bitmap resolutions, etc. For a professional looking game, you also need music and sound effects.
None of this is rocket science. But each of these things requires some thinking and experimenting, when you do them for the first time. You might want to create a demo for each of them separately. Definitely don't use all of them in your very first game.
Start with a simple game, such as minesweeper. Open a game dialog with a canvas. Load bitmaps from resource files. Place the mines randomly in a memory array, then paint that information on the canvas. When user clicks mouse, convert the mouse coordinates to the click field, update the memory array accordingly, then repaint the canvas. That's all, but you need to think about all possible game states: each field can be "hidden", "hidden with mark", "hidden with question mark", "open", "open with number", "open with a bomb that killed you". Also, when you are killed, you cannot click anymore (other than the restart button).
As a next game, just make a simple animated demo: balls bouncing within a rectangle. (To keep it simple, balls only bounce from the boundaries of the rectangle, not from each other.) Your game state is where the balls are (x, y) and what is their speed (sx, sy). You need a method that will update the state when some times has passed; the time interval is provided as a parameter. The coordinates need to be floats, even if ultimately they will be rounded to int when you paint the balls. A linear movement is simple: add "time × sx" to "x"; if you passed a boundary, fix "x" and flip the sign on "sx" (and do the same for "y" and "sy".) Make a loop that waits for some time interval, updates the state, and repaints the state. Congratulation, you made your first animation! Now try supporting the mouse; when a user clicks find out if any ball was clicked, if yes, change its color.
When you have these two parts mastered, you are ready to make a simple animated game. On a very abstract level, there is a game state, a method that updates the game state when a time interval has passed, a method that updates the state when a mouse was clicked or a key was pressed, and a method that paints the state. And an infinite loop of: wait, update for time, update for mouse and key events, repaint; and again. For a more complex game, the game state is more complex, but the essence remains. (Plus you may want a method to save the state to a file, and load the state from a file.)
Moving a player character can be done the same way. You have an object with coordinates "x", "y" and speed "sx", "sy". When time passes, "x" and "y" update based on "sx" and "sy". (To implement friction, make also "sx" and "sy" move slowly towards zero based on time passed. To implement gravity, increase "sy" based on time passed.) When an arrow key is pressed, "sx" or "sy" is either increased or decreased. When the object hits an obstacle, it bounces. When the player object overlaps another object (a collectible item, or a missile), the other object is destroyed and the game state is updated accordingly (score increased, key collected, or hit points reduced).
How to implement shooting? The shots are also objects with their own "x" "y" "sx" "sy", which are generated when you press a key, and disappear when they hit something or get out of the screen. How to implement enemies? For starters, make them bounce off the boundaries of the screen, and shoot at random moment in a random direction. Check when your missile collides with an enemy (destroy the missile, reduce enemy hit points, destroy enemy if hit points get to zero), check when enemy missiles collide with you.
The next step would be to load levels from files. For example, imagine a rectangular maze M×N, loaded from a text file (where walls are represented by "x" characters, and empty squares by spaces), and your task is to walk from the start to finish. Optionally, add colored keys and doors (specified in the text file e.g. as "a" "b" "c" for keys, and "A" "B" "C" for doors), where you need to collect a key in order to be able to walk through the corresponding door. Make 10 levels like this; completing a level starts the next level. The easy way is to do this without animation: your positions are integers in the maze grid, and they update only when you press a key.
Now make the same version, but more alive. Make a rectangular maze with walls loaded from file. Make yourself and the enemies bounce from the walls (this will require a little math, but quite simple). Add shooting. (To keep it simple, enemies do not bounce from each other. Neither do you bounce from an enemy, but your collision removes hit points from both.)
Now all you need is to add more sophisticated behavior to the enemies. The constraints are that the enemy has a state, and the method that updates the state of the game will also update the enemy state. (The algorithm for enemy is implemented in small pieces. For example, instead of a loop "choose a random place on the screen, walk there", you would specify small increments, such as "if you have a place chosen, move towards it time×sx steps; if you reached the place, choose another"... essentially write a code which executed many times repeatedly will produce the desired behavior, but at each time only does a tiny part of it.) Make multiple enemies, specified in a configuration file: they will differ by bitmaps, amount of hitpoints, and maximum speed.
...and when this is done, you are ready for Unity. What Unity does for you is providing 3D graphics and 3D physics (it will calculate the bouncing and collisions for you).
Computer games have a few things different than usual applications; you probably don't want to encounter all those differences in your first project. The user interface is generally completely different: instead of dialogs with buttons and input fields, you typically have one window with canvas, where you paint things. (If you also want buttons and input fields, you probably have to implement them yourself on top of that.) Things are in motion, they appear and disappear, interact with each other. You probably want to clearly separate updating of the game state from displaying the game state. (You probably also want to save and load the game state.) In addition to algorihms, there is lot of data: design of the levels, different units which are kinda the same thing but with different parameters and different pictures. (Will you also make a level editor? Or design a clever system for easily describing the level in a plain-text file?) Plus the details that still require lot of work, like the intro screen, help screen, option screen, high score table, etc. Plus you sometimes need to care about performance; a one-second delay to e.g. calculate the proper path through a maze may be unacceptable, because it would make the game freeze for a moment every time you command a unit to go somewhere. For network games, performance is even more complicated. You need to make semi-arbitrary choices about object dimensions, bitmap resolutions, etc. For a professional looking game, you also need music and sound effects.
None of this is rocket science. But each of these things requires some thinking and experimenting, when you do them for the first time. You might want to create a demo for each of them separately. Definitely don't use all of them in your very first game.
Start with a simple game, such as minesweeper. Open a game dialog with a canvas. Load bitmaps from resource files. Place the mines randomly in a memory array, then paint that information on the canvas. When user clicks mouse, convert the mouse coordinates to the click field, update the memory array accordingly, then repaint the canvas. That's all, but you need to think about all possible game states: each field can be "hidden", "hidden with mark", "hidden with question mark", "open", "open with number", "open with a bomb that killed you". Also, when you are killed, you cannot click anymore (other than the restart button).
As a next game, just make a simple animated demo: balls bouncing within a rectangle. (To keep it simple, balls only bounce from the boundaries of the rectangle, not from each other.) Your game state is where the balls are (x, y) and what is their speed (sx, sy). You need a method that will update the state when some times has passed; the time interval is provided as a parameter. The coordinates need to be floats, even if ultimately they will be rounded to int when you paint the balls. A linear movement is simple: add "time × sx" to "x"; if you passed a boundary, fix "x" and flip the sign on "sx" (and do the same for "y" and "sy".) Make a loop that waits for some time interval, updates the state, and repaints the state. Congratulation, you made your first animation! Now try supporting the mouse; when a user clicks find out if any ball was clicked, if yes, change its color.
When you have these two parts mastered, you are ready to make a simple animated game. On a very abstract level, there is a game state, a method that updates the game state when a time interval has passed, a method that updates the state when a mouse was clicked or a key was pressed, and a method that paints the state. And an infinite loop of: wait, update for time, update for mouse and key events, repaint; and again. For a more complex game, the game state is more complex, but the essence remains. (Plus you may want a method to save the state to a file, and load the state from a file.)
Moving a player character can be done the same way. You have an object with coordinates "x", "y" and speed "sx", "sy". When time passes, "x" and "y" update based on "sx" and "sy". (To implement friction, make also "sx" and "sy" move slowly towards zero based on time passed. To implement gravity, increase "sy" based on time passed.) When an arrow key is pressed, "sx" or "sy" is either increased or decreased. When the object hits an obstacle, it bounces. When the player object overlaps another object (a collectible item, or a missile), the other object is destroyed and the game state is updated accordingly (score increased, key collected, or hit points reduced).
How to implement shooting? The shots are also objects with their own "x" "y" "sx" "sy", which are generated when you press a key, and disappear when they hit something or get out of the screen. How to implement enemies? For starters, make them bounce off the boundaries of the screen, and shoot at random moment in a random direction. Check when your missile collides with an enemy (destroy the missile, reduce enemy hit points, destroy enemy if hit points get to zero), check when enemy missiles collide with you.
The next step would be to load levels from files. For example, imagine a rectangular maze M×N, loaded from a text file (where walls are represented by "x" characters, and empty squares by spaces), and your task is to walk from the start to finish. Optionally, add colored keys and doors (specified in the text file e.g. as "a" "b" "c" for keys, and "A" "B" "C" for doors), where you need to collect a key in order to be able to walk through the corresponding door. Make 10 levels like this; completing a level starts the next level. The easy way is to do this without animation: your positions are integers in the maze grid, and they update only when you press a key.
Now make the same version, but more alive. Make a rectangular maze with walls loaded from file. Make yourself and the enemies bounce from the walls (this will require a little math, but quite simple). Add shooting. (To keep it simple, enemies do not bounce from each other. Neither do you bounce from an enemy, but your collision removes hit points from both.)
Now all you need is to add more sophisticated behavior to the enemies. The constraints are that the enemy has a state, and the method that updates the state of the game will also update the enemy state. (The algorithm for enemy is implemented in small pieces. For example, instead of a loop "choose a random place on the screen, walk there", you would specify small increments, such as "if you have a place chosen, move towards it time×sx steps; if you reached the place, choose another"... essentially write a code which executed many times repeatedly will produce the desired behavior, but at each time only does a tiny part of it.) Make multiple enemies, specified in a configuration file: they will differ by bitmaps, amount of hitpoints, and maximum speed.
...and when this is done, you are ready for Unity. What Unity does for you is providing 3D graphics and 3D physics (it will calculate the bouncing and collisions for you).
I hear game dev is the worst paid as well!
Mobile games are quite lucrative. Those leading games typically have large bonuses.
AAA game development is the very definition of misery, pain and suffering.
Are there entry level positions in game dev outside of the, notoriously horrible to work at, AAA studios?
I feel like I'm misunderstanding your question, because there's tons of other work when it comes to programming. Desktop UI programs of many different types (ex, web browser, chat, games, etc), command line utilities, compilers, operating systems, data bases... the list is long.
I recently got really into databases. However, coming from the "web dev world", I'm still struggling to decide whether the time invested is really worth it. From an educational point of view, it damn sure is. But in order to make a transition into this area professionally, I'm not sure given the low number of companies that are working in this area (worse here in Europe).
Wondering if databases are worth learning? SQL is still one of the most in demand tech skills and has been for decades (for good reason in my opinion).
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
Yes, as a full stack dev I think the front end is easier than backend.
We joked at my old place that the best thing for a web dev's sanity long term is to retire into SQL
We joked at my old place that the best thing for a web dev's sanity long term is to retire into SQL
I sympathize differently: I just want to work. Change for change's sake gets really, really old.
In 2007, I was already long past done. DHTML [1997] and AJAX [1999] were distant memories. (Had to check wiki.) I mercifully forget what the hotness was during the final years of the Bush Admin.
Sure, some things get better. Fonts on the web are now pretty terrific. But React? Please kill me. Components? Code generation? Meta meta languages? Ya, no thanks.
But I am happy the kids are now finally rediscovering (reinventing) server side includes. Full circle.
Good times.
In 2007, I was already long past done. DHTML [1997] and AJAX [1999] were distant memories. (Had to check wiki.) I mercifully forget what the hotness was during the final years of the Bush Admin.
Sure, some things get better. Fonts on the web are now pretty terrific. But React? Please kill me. Components? Code generation? Meta meta languages? Ya, no thanks.
But I am happy the kids are now finally rediscovering (reinventing) server side includes. Full circle.
Good times.
I think once you have been working in tech for a decade or so, you start to see the fashion show for what it is. Constant churn for the sake of it. Sure some stuff is genuinely useful, but the majority of it gets forgotten about pretty quickly.
> Oh boy. I sympathise entirely with this post, but the story's exactly the same on the backend.
I was thinking exactly the same thing while reading the conclusion of the post. You leave frontend complexity for even more complexity, are you nuts!
The good old single PHP page is gone long time ago as well.
I was thinking exactly the same thing while reading the conclusion of the post. You leave frontend complexity for even more complexity, are you nuts!
The good old single PHP page is gone long time ago as well.
The thing is a LAMP stack would serve most businesses needs fine and would take a fraction of the effort to implement. Server side rendering and a bit of jQuery. Actually matching technology to requirements is going to make me unemployable in the future.
Neither is retreating to B2B. Personally I can deal with B2B than with B2C because it's not all about The New Shiny Thing™.
But then you get to integrate with some weird funky SAP extension some company wrote and they can't even configure their web service URLs right.
If you work in IT, you'll have to perpetually fight against people and technology. It's why people hate people who work in IT, because they always say "no".
But then you get to integrate with some weird funky SAP extension some company wrote and they can't even configure their web service URLs right.
If you work in IT, you'll have to perpetually fight against people and technology. It's why people hate people who work in IT, because they always say "no".
My impression is that backend changes more slowly (and is easier to control) than frontend. At least when you're doing backend you can choose your whole stack (vs. frontend where you have to deal with a huge array of different types of computers and such).
Plus IMO you set up your framework for building once or twice and just reuse it everywhere, so doesn't end up as difficult as the faster changing front end work.
Plus IMO you set up your framework for building once or twice and just reuse it everywhere, so doesn't end up as difficult as the faster changing front end work.
> But the story's exactly the same on the backend. Kubernetes. Docker. AWS and its gazillion impenetrable product names.
Not in my experience. I made the switch from front-end to back-end about 5 years ago and I never worked with k8s or AWS, and Docker very little only for spinning up local envs; those were always the job for devops. I guess it just depends on the company. I mainly read code and wrote code.
Not in my experience. I made the switch from front-end to back-end about 5 years ago and I never worked with k8s or AWS, and Docker very little only for spinning up local envs; those were always the job for devops. I guess it just depends on the company. I mainly read code and wrote code.
> The endless bullshit of dealing with "Log in with Facebook/Google/Apple"
Do you have some sources for that? Just curious.
I personally avoid having to login via FB, Google etc.
Do you have some sources for that? Just curious.
I personally avoid having to login via FB, Google etc.
Native iOS is relatively simple toolwise, esp. with Swift and SwiftUI, yet at the same time very deep and powerful.
[deleted]
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.
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.
User expectations or client expectations?
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.
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.
>So far I haven't met a user who asked for ads
By voting with their feet in favor of free ad-supported services, they are essentially asking for ads.
Perhaps this will change in the future. Twitter is said to be experimenting with offering subscriptions, akin to what Substack or media companies do. But the general arc of the internet up until now has been toward free-with-ads.
By voting with their feet in favor of free ad-supported services, they are essentially asking for ads.
Perhaps this will change in the future. Twitter is said to be experimenting with offering subscriptions, akin to what Substack or media companies do. But the general arc of the internet up until now has been toward free-with-ads.
IMO, phone apps changed users’ expectations for websites. They want the same interactivity on Facebook.com that they get on the Facebook app. Same with Kayak (or whatever travel site people use these days). Same with Google Maps. However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible.
But that does not mean expectations of web users have to be thrown under the bus. Such as, you click on something by mistake and try to fix it by using Back button. With facebook nope, if you forgot to open the link in a new tab, the original view is irretrievably lost. You sometimes can't even scroll back to review something, whole page gets reloaded and it vanishes.
Supposedly one-page apps are meant to improve latency and interactivity, but FB is slow as molasses and frustrating regardless.
Supposedly one-page apps are meant to improve latency and interactivity, but FB is slow as molasses and frustrating regardless.
FB's terrible back functionality is their own fault since libraries like React Router give you a ton of control over back/forward behavior.
As for FB's slowness, SPAs are hard to do well when you have a lot of live data all over the page. You can get clever with optimistic backend calls and caching, but in the end you still have frequent state changes.
Users want infinite scroll to be fast, so you need over-eager loading _in case_ they scroll. Add over-eager loading all over the page (in case they click on a user profile, in case they click on FB Marketplace, etc.) and you have a recipe for a CPU hog.
As for FB's slowness, SPAs are hard to do well when you have a lot of live data all over the page. You can get clever with optimistic backend calls and caching, but in the end you still have frequent state changes.
Users want infinite scroll to be fast, so you need over-eager loading _in case_ they scroll. Add over-eager loading all over the page (in case they click on a user profile, in case they click on FB Marketplace, etc.) and you have a recipe for a CPU hog.
Well, this goes even deeper.
Historically, the Web started out as hypertext: static text documents which were interlinked. But right off the bat, there was this drive to create "Rich Web Applications": the browser as an alternate to applications which you don't need to install on a "gatekept" operating system (Windows and OSX).
Flash, Silverlight, Java Web Applets,... All those browser plugins were exactly meant to achieve this. But none of them quite fully lived up to the potential of the idea.
There's a good reason why Microsoft in the 90's wanted to dominate the browser market: because it was a potential threat to lose control over what users could or couldn't do with their computers.
Things changed when mobile devices landed, and Google jumped into the browser market. Suddenly, building a web experience no longer wasn't as "trivial" as making sure your CSS worked on Explorer, Safari and Firefox.
At the same time, the "Application Wars" moved into the mobile realm where there was this battle between "native applications" and "web based applications". The latter was the notion that you could get the same functionality without having to install an app from an app store on your device.
Those dynamics of competition were - and still are - a driving force behind innovation that made browser engines ever more powerful and complex.
"Front-end" as a dedicate discipline didn't truly exist before the 2010's. You were a web master, a web developer, a web designer or something of the sort. But as soon as that complexity did hit, "front end engineering" became a specialization. Where it is really a cottage industry build on top of those complex browser engines, API's and sprawling specifications. For better or worse.
> However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible.
Exactly. And that's still a completely valid use case.
The problem is how the industry has shoehorned an entire generation of front-end developers into believing that you need all those gizmo's to write HTML, CSS and JS.
When you're a budding front-end engineer and you land your first job from your internship, you're not even going to question the tools used by your employer. You're just going to use them because all you see is a big black box of complexity and nobody explains the history that has created that box.
I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.
Historically, the Web started out as hypertext: static text documents which were interlinked. But right off the bat, there was this drive to create "Rich Web Applications": the browser as an alternate to applications which you don't need to install on a "gatekept" operating system (Windows and OSX).
Flash, Silverlight, Java Web Applets,... All those browser plugins were exactly meant to achieve this. But none of them quite fully lived up to the potential of the idea.
There's a good reason why Microsoft in the 90's wanted to dominate the browser market: because it was a potential threat to lose control over what users could or couldn't do with their computers.
Things changed when mobile devices landed, and Google jumped into the browser market. Suddenly, building a web experience no longer wasn't as "trivial" as making sure your CSS worked on Explorer, Safari and Firefox.
At the same time, the "Application Wars" moved into the mobile realm where there was this battle between "native applications" and "web based applications". The latter was the notion that you could get the same functionality without having to install an app from an app store on your device.
Those dynamics of competition were - and still are - a driving force behind innovation that made browser engines ever more powerful and complex.
"Front-end" as a dedicate discipline didn't truly exist before the 2010's. You were a web master, a web developer, a web designer or something of the sort. But as soon as that complexity did hit, "front end engineering" became a specialization. Where it is really a cottage industry build on top of those complex browser engines, API's and sprawling specifications. For better or worse.
> However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible.
Exactly. And that's still a completely valid use case.
The problem is how the industry has shoehorned an entire generation of front-end developers into believing that you need all those gizmo's to write HTML, CSS and JS.
When you're a budding front-end engineer and you land your first job from your internship, you're not even going to question the tools used by your employer. You're just going to use them because all you see is a big black box of complexity and nobody explains the history that has created that box.
I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.
> I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.
This is why I'm optimistic that some small companies or startups will look at this black box, go "nope" and look at simpler alternatives : maybe hotwire or htmx, or some other tech or architecture allows them to build the things they need to build quickly and efficiently and outpace their complexity-bound competition - much like Rails was the alternative back in 2004 to the J2EE behemoths of the day that the industry considered the "right" way to build a web app.
This is why I'm optimistic that some small companies or startups will look at this black box, go "nope" and look at simpler alternatives : maybe hotwire or htmx, or some other tech or architecture allows them to build the things they need to build quickly and efficiently and outpace their complexity-bound competition - much like Rails was the alternative back in 2004 to the J2EE behemoths of the day that the industry considered the "right" way to build a web app.
I think it's more likely that faster CPUs will make CPU hog pages less noticeable. Companies keep making bloated pages but users will decreasingly care.
It's not about the cost of the end-user bloat (although that's a problem), but the cost of development and maintenance required by complex front-end frameworks and architectures.
I would say both. User in the sense that people expect the web to behave and be just as rich and fluid as a native app (and will often leave or mistrust you otherwise) and Client in the sense that having a rich web experience drives revenue and whatever other business metrics.
> it is staggering how easy it is to break many of those sites just by resizing the browser window.
I should say that a responsive website does not actually mean a website that responds to resizing the browser window - and that should not be taken to mean it's "broken". Saying that makes you sound like a typical sweatshop PM or stakeholder :) - i won't belabour the actual meaning here.
> it is staggering how easy it is to break many of those sites just by resizing the browser window.
I should say that a responsive website does not actually mean a website that responds to resizing the browser window - and that should not be taken to mean it's "broken". Saying that makes you sound like a typical sweatshop PM or stakeholder :) - i won't belabour the actual meaning here.
> I should say that a responsive website does not actually mean a website that responds to resizing the browser window
It does though, at least indirectly. If the point is to handle different screen sizes and resolutions properly that also has the side effect of handling window resizing; and if one doesn't work correctly the other will most likely have issues as well in some situations.
You can pick apart words and meanings as much as you want - a UI that stops fully functioning after the user makes a valid input I consider it broken. Hopefully you wouldn't call it "working as intended" either when a site becomes unscrollable, freezes up or literally moves sideways out of the browser's viewport when you type in a text field.
Resizing a window is not a weird edge case, it's been a basic UI feature for decades, supported even on some smartphones and tablets, and desktop applications have been able to handle it fine.
It does though, at least indirectly. If the point is to handle different screen sizes and resolutions properly that also has the side effect of handling window resizing; and if one doesn't work correctly the other will most likely have issues as well in some situations.
You can pick apart words and meanings as much as you want - a UI that stops fully functioning after the user makes a valid input I consider it broken. Hopefully you wouldn't call it "working as intended" either when a site becomes unscrollable, freezes up or literally moves sideways out of the browser's viewport when you type in a text field.
Resizing a window is not a weird edge case, it's been a basic UI feature for decades, supported even on some smartphones and tablets, and desktop applications have been able to handle it fine.
No what you are talking about is called fluid design not responsive. So whether a website responds fluidly to browser resizing is a design decision and not indicative of something being broken. This is such a common and frustrating misconception.
Sure, you can call not supporting one of the most
basic UI features a "design decision", but it's a terrible
decision and it won't protect you against valid complaints from
users, just like apps like Skype got complaints for mishandling
the window's close button.
Intentionally broken is still broken.
Intentionally broken is still broken.
> and will often leave or mistrust you otherwise
Oh bullcrap.
This is just a rationalization from people who like the shiny.
Oh bullcrap.
This is just a rationalization from people who like the shiny.
> 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.
What does that have to do with React and others? Tracking and ads are a regulation problem, pop-ups and auto-start videos are user-agent problems, and wait... loading screens? I don't understand, where do you see a loading screen in a normal web page? I mean in an SPA, sure but that's just bringing rendering to the client and people have been doing it since the invention of AJAX.
React and others didn't make the impossible possible, they just increase the development speed and make it much easier to manage complex state.
So, the post is against the complexity in development, you are against the complexity in the average website. I'm suggesting that the first one is neither the reason for the second, nor the enabler, and you can see that kind of user-hostility even in web-sites made with mootools, let alone jQuery or react.
What does that have to do with React and others? Tracking and ads are a regulation problem, pop-ups and auto-start videos are user-agent problems, and wait... loading screens? I don't understand, where do you see a loading screen in a normal web page? I mean in an SPA, sure but that's just bringing rendering to the client and people have been doing it since the invention of AJAX.
React and others didn't make the impossible possible, they just increase the development speed and make it much easier to manage complex state.
So, the post is against the complexity in development, you are against the complexity in the average website. I'm suggesting that the first one is neither the reason for the second, nor the enabler, and you can see that kind of user-hostility even in web-sites made with mootools, let alone jQuery or react.
To be honest, I see those even less in modern SPAs. Usual suspects are sites which load every possible js lib in the universe until some integration works and they can display all the ads.
There seems to be a confusion here.
There seems to be a confusion here.
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 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.
> we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense
Injecting HTML into the DOM is literally what React does...
You can even server render that HTML and then hydrate the DOM with interactivity after the fact.
I don't understand why people make the distinction between server rendered and client rendered HTML when React can do both anyway.
The main value of React is being able to easily manage client state and efficient updating of the DOM.
If not a framework, how do you add interactivity to your pages? Vanilla JS?
Injecting HTML into the DOM is literally what React does...
You can even server render that HTML and then hydrate the DOM with interactivity after the fact.
I don't understand why people make the distinction between server rendered and client rendered HTML when React can do both anyway.
The main value of React is being able to easily manage client state and efficient updating of the DOM.
If not a framework, how do you add interactivity to your pages? Vanilla JS?
> Injecting HTML into the DOM is literally what React does...
The key part of that phrase is "server-rendered", not AJAX. Which yes, is possible with React as well, but it's incredibly rare to see a React app that utilizes actual browser navigation for the majority of it's interactions (posting forms, sessions via cookies, little to no JSON interaction).
There's certainly nothing stopping me from using React as a templating language, I don't but whatever, it's a fine choice. When I'm talking about "React apps", I guess I can be a bit more precise and say apps where control flow is dictated by the front end and the backend largely serves as an API (and maybe occasionally bootstraps a view).
> If not a framework, how do you add interactivity to your pages? Vanilla JS?
Mostly, yeah. We used a bit of Vue early on, but didn't see much benefit, there's still some code kicking around due to be transitioned. We'll use Stimulus when it makes sense, otherwise it's just vanilla JS and maybe helper libraries (checking our package.json, the only libraries we're using that aren't for CSS or third-party things like stripe are stimulus, codemirror, debounce, trix, and vue).
The key part of that phrase is "server-rendered", not AJAX. Which yes, is possible with React as well, but it's incredibly rare to see a React app that utilizes actual browser navigation for the majority of it's interactions (posting forms, sessions via cookies, little to no JSON interaction).
There's certainly nothing stopping me from using React as a templating language, I don't but whatever, it's a fine choice. When I'm talking about "React apps", I guess I can be a bit more precise and say apps where control flow is dictated by the front end and the backend largely serves as an API (and maybe occasionally bootstraps a view).
> If not a framework, how do you add interactivity to your pages? Vanilla JS?
Mostly, yeah. We used a bit of Vue early on, but didn't see much benefit, there's still some code kicking around due to be transitioned. We'll use Stimulus when it makes sense, otherwise it's just vanilla JS and maybe helper libraries (checking our package.json, the only libraries we're using that aren't for CSS or third-party things like stripe are stimulus, codemirror, debounce, trix, and vue).
I don't really see a big difference between POSTing with a form vs a request or between sessions and tokens.
Flow control is definitely different between React apps and standard server rendered websites, but you are still effectively implementing the same thing in both cases.
I guess I'm not understanding how your team's productivity is "easily double" when to me, it sounds like you're describing run of the mill stuff that could easily be done in React or a backend framework.
Flow control is definitely different between React apps and standard server rendered websites, but you are still effectively implementing the same thing in both cases.
I guess I'm not understanding how your team's productivity is "easily double" when to me, it sounds like you're describing run of the mill stuff that could easily be done in React or a backend framework.
Oh, we're absolutely using a backend framework, I didn't mean to imply that we're building everything with raw CGI scripts or something like that.
In terms of increased productivity, things I've noticed that have helped with productivity:
- Using native browser functionality for navigation and form submission allows the browser itself to take on some of the work that would otherwise be filled in by custom code like maintaining browser history.
- A standard SPA requires that you maintain an API for the front end to talk to, which a server rendered framework has no need for (we do have an API, but it's specifically for customer usage and doesn't need to cover all use cases we need for our application)
- The backend is a 100% known environment, and while you always have to think about browser / device capability, this is greatly reduced when you have small amounts of Javascript, particularly when it's not essential for your page to function - there's also far lower demands on client machines since the bulk of the work is performed by the server.
Changes can often be applied in a single "layer". If I need to add a new field to a view, I can just add it to a template, whereas in an SPA I'd need to modify my React components as well as my API, potentially needing to care about API versioning, etc.
- More of a broader thing, but I find that environments that use front-end frameworks heavily tend to become more specialized quicker, and environments where you have specialization between front-end and back-end leads to increased needs for coordination for any non-trivial work, which ends up being a pretty big tax on velocity compared to having full-stack developers who can work on anything.
In terms of increased productivity, things I've noticed that have helped with productivity:
- Using native browser functionality for navigation and form submission allows the browser itself to take on some of the work that would otherwise be filled in by custom code like maintaining browser history.
- A standard SPA requires that you maintain an API for the front end to talk to, which a server rendered framework has no need for (we do have an API, but it's specifically for customer usage and doesn't need to cover all use cases we need for our application)
- The backend is a 100% known environment, and while you always have to think about browser / device capability, this is greatly reduced when you have small amounts of Javascript, particularly when it's not essential for your page to function - there's also far lower demands on client machines since the bulk of the work is performed by the server.
Changes can often be applied in a single "layer". If I need to add a new field to a view, I can just add it to a template, whereas in an SPA I'd need to modify my React components as well as my API, potentially needing to care about API versioning, etc.
- More of a broader thing, but I find that environments that use front-end frameworks heavily tend to become more specialized quicker, and environments where you have specialization between front-end and back-end leads to increased needs for coordination for any non-trivial work, which ends up being a pretty big tax on velocity compared to having full-stack developers who can work on anything.
There's no shortage of hn clients with increased interaction and none have seemed to be used more than the site itself.
Too often interactivity can seem forced where the primary use is consumption of information, like hn.
The lack of distractions in the ui allows folks to focus on the conversation to some extent in a way that might be different.
Too often interactivity can seem forced where the primary use is consumption of information, like hn.
The lack of distractions in the ui allows folks to focus on the conversation to some extent in a way that might be different.
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.
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.
A lot of these gripes seem to be aimed at either poor imitations of well designed and implemented marketing pages or just straight up poor designs. From my experience as a front ender, I want to make the user experience as welcoming as possible instead of replacing native scrolling, stolen keyboard shortcuts, etc. It’s a designer that tries to impose their mock-up on browser defaults and only with front end pushback do we get a mediocre middle ground.
There are certainly poor front-end led sites but I think that can go away quickly after some experience in the field. Design is largely shielded from that if they stay in the land of Sketch or Figma instead of interacting with the real web.
This problem is as old as time: even in print, it takes experience and planning to visualize a digital composite as a physical object that lives up to your expectations.
There are certainly poor front-end led sites but I think that can go away quickly after some experience in the field. Design is largely shielded from that if they stay in the land of Sketch or Figma instead of interacting with the real web.
This problem is as old as time: even in print, it takes experience and planning to visualize a digital composite as a physical object that lives up to your expectations.
> 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.
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.
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.
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.
>user's expectations for the web have grown astronomically
Have they? I don't see that in my user stories
Have they? I don't see that in my user stories
Users just want it to work. I think the problem is too many developers trying to impress each other for status.
IMO, what matters most is coding efficiency, how fast can business problems be solved with a low enough error threshold.
IMO, what matters most is coding efficiency, how fast can business problems be solved with a low enough error threshold.
It's a combination of whimsical requirements from PMs and designers, plus FOMO and resume-driven development among developers. None of which have anything to do with actual end-user needs.
There's also a Large Corp dynamic, where to maintain consistent user experience across the product portfolio, a common UI platform is built. The platform is then mainly driven by the requirements of the most dynamically interactive applications, leading to a complexity creep - even though most of the products could be simple CRUD web pages.
"resume-driven development"
I think you nailed it.
I think you nailed it.
And on top of that, most users want it to work the same it worked yesterday. Nothing drives me up the wall more than neverending stream of updates for anything and everything, be it PC, mobile, web, even cars. I understand it's great for job security and/or resume-filling, I just wish those developers would consider the difficulty of,for example, trying to explain to 60 years old nurse why the thing that worked yesterday doesn't work anymore or why it suddenly behaves differently.
Companies overhire devs after raising money so it looks like they're doing a lot of interesting stuff. PMs and managers need to find stuff for these devs to do, hence they come up with overcomplicating their existing tech, redesigns, etc.
[deleted]
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.
> 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.
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.
Hacker News is purposely utilitarian and that's fine but I don't think general audiences would tolerate it. You have to manually check if someone responded to your comment. I don't think its too unreasonable to say that most users expect a notifications system on a platform like this. Editing a comment takes you to a separate screen and leaves you there once you're done, you have to manually navigate back to the discussion you were on. Reddit lets you edit your comment in place and continue from where you left off straight away.
These features could be feasibly implemented using jQuery or plain JavaScript but the more niceties like that you add, the more you can make the argument for UI frameworks.
These features could be feasibly implemented using jQuery or plain JavaScript but the more niceties like that you add, the more you can make the argument for UI frameworks.
When reddit switched to their new 'featureful and rich' ui they provided a way to access the old user interface which is much more utilitarian and flat.
I expect most experienced reddit users still use the old ui toggle. I expect new reddit users don't know it exists but would probably prefer it once they got over the 'change is bad hump'.
The fact that years later the old ui toggle is still present is a testament to how much the new richer ui failed for their power users.
I expect most experienced reddit users still use the old ui toggle. I expect new reddit users don't know it exists but would probably prefer it once they got over the 'change is bad hump'.
The fact that years later the old ui toggle is still present is a testament to how much the new richer ui failed for their power users.
It seems to me you're confusing HN's lack of some common forum features with the way that those features would be implemented; I would imagine that if HN did get, say, notifications, they would largely work without javascript, or some big complicated frontend build process.
old.reddit.com is another good example. Not everything needs to be an SPA.
old.reddit.com is another good example. Not everything needs to be an SPA.
The parent suggested HN as an example of an application that didn't need a lot of client code. I think its still fair to say that it doesn't have many of the features that ordinary users have come to expect.
Old reddit is a much more reasonable suggestion. It is fairly feature rich and is used by a large group of users. It seems to deliver ~340KB of Javascript. It's pretty nicely minified so I can't tell what its all related to but at least some of it must be related to the interactivity that HN is missing.
Like I said in my previous comment, you can do as old Reddit did and build up Javascript to solve these problems but at some stage it might make sense to jump to an SPA. Reddit made that decision. I think many would argue that they prefer old Reddit which is fair enough.
I think its hard to say if the Reddit team made the decision based on a legitimate and provable technical need and their old solution just wasn't cutting it or if they went the SPA route because "its what everyone else does" and "its easier to hire React devs".
Old reddit is a much more reasonable suggestion. It is fairly feature rich and is used by a large group of users. It seems to deliver ~340KB of Javascript. It's pretty nicely minified so I can't tell what its all related to but at least some of it must be related to the interactivity that HN is missing.
Like I said in my previous comment, you can do as old Reddit did and build up Javascript to solve these problems but at some stage it might make sense to jump to an SPA. Reddit made that decision. I think many would argue that they prefer old Reddit which is fair enough.
I think its hard to say if the Reddit team made the decision based on a legitimate and provable technical need and their old solution just wasn't cutting it or if they went the SPA route because "its what everyone else does" and "its easier to hire React devs".
old.reddit.com works without javascript, notifications and all.
I tried there and upvotes, replying to comments and editing comments don't work. I can't speak to notifications but I'll accept that they work.
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.
" The complicated web is here because users insist on interaction, "
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.
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.
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.
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
Efficient interactions might not be the same as effective interactions.
Most sites and apps want users to click and engage as much as possible, not necessarily the most efficiently.
Most sites and apps want users to click and engage as much as possible, not necessarily the most efficiently.
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.
complex UIs don't require complex frameworks
What _do_ they require?
They require identifying all the interaction paths that a user can take through the application so that any function associated with an interaction can correctly update the state of the application's data model. Vanilla JS, HTML, and CSS.
Do you think that's feasible for a website like Facebook? It seems like it would be much more difficult than using a framework.
Developers that have experience creating native applications are used to writing code that manages the application state and it's relation to UI interactions and data updates. In native-land, the UI frameworks are primarily the UI widgets and all of the application logic is written by the application developers in their chosen language. The corollary to this for web development is that HTML and maybe a few specialized graphics libraries like D3.js provide the UI thingies and the application logic (event handling, data fetching, etc.) is written in Javascript.
I'm not familiar with the Facebook website but I can't imagine that it needs any particularly complex application logic under the hood.
I'm not familiar with the Facebook website but I can't imagine that it needs any particularly complex application logic under the hood.
Why would it not be possible? What cant you do with js that other fancy frameworks can?
I didn't say not possible, I said feasible.
Pretty much anything is possible given enough time, but spending time building a complex application in vanilla JS, HTML and CSS doesn't seem like the most productive use of time when you can leverage a framework.
Pretty much anything is possible given enough time, but spending time building a complex application in vanilla JS, HTML and CSS doesn't seem like the most productive use of time when you can leverage a framework.
Agree!
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 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.
If you like functional JS then you should be using React. This is exactly why it's still the most popular JS framework. If you want a simpler build system then you should try esbuild. It's a single Go binary.
You can use Vue.js 2 without build system by just loading into the browser.
Can confirm. I built 2 VueJS apps that are 100% static, and it was not a problem at all.
A 100% static site doesn’t run any JS, right? What did you need Vue for, then?
A static site may use JS, but doesn't require server-side logic (PHP, databases, or any other type of dynamic content). In this case OP implies that it doesn't even require a build (because you may create a static site through a build process -like Jekyll does, for example-).
Static from the server perspective. It only serves files in a directory without any parsing or processing.
You can still do this with Vue 3! The CodePen embeds they use in their "Getting Started" docs are all still just loading in an external library and making use of it with vanilla JS.
https://codepen.io/team/Vue/pen/KKpRVvJ
https://codepen.io/team/Vue/pen/KKpRVvJ
Sure you can, but then the moment you want to use an external library with it, it's basically a coin flip whether they ship it in the correct format for that. If they don't, you have to import it - but you can only import from modules. So you modify your page to load your code as a module instead, but now you can't access the global state. So you refractor everything and realize, that your page takes a minute to load because each of those modules contains like a 100 dependencies and half of them overlap.
TL;DR: it's there, but it's really only usable in like 5% of scenarios
TL;DR: it's there, but it's really only usable in like 5% of scenarios
[deleted]
I don't understand why so many devs seem to want to use Functional programming.
It's the exact same thing to me as what this article is complaining about. Everyone jumping on the latest and greatest bandwagon.
Angular is easy, and OOP is very easy to work with for business needs.
It's the exact same thing to me as what this article is complaining about. Everyone jumping on the latest and greatest bandwagon.
Angular is easy, and OOP is very easy to work with for business needs.
OOP is very easy to misuse where it hurts the most - on architectural level. It's very possible to write bad, unreadable FP code, but worst case isn't as bad or far reaching as with OOP.
I suppose so, I've seen that myself. I always take the time to design anything I do thoroughly though so it's all clear and concise.
Also the only time I used FP it was a seemingly awful implementation.
Perhaps I'll mess around with F# or something some time to see how I feel about it more.
Also the only time I used FP it was a seemingly awful implementation.
Perhaps I'll mess around with F# or something some time to see how I feel about it more.
In the case of React, I find functional programming excellent when it comes to mapping views from state. For state management, functional programming just seems like a massive time sink and a convoluted way of achieving the same things that OOP just gives you.
> For state management, functional programming just seems like a massive time sink and a convoluted way of achieving the same things that OOP just gives you.
Huh? function(state(A)) = state(B), always.
Huh? function(state(A)) = state(B), always.
Right, I don't know much about React myself, but that must be why Redux was created right?
On the bright side, with native web components and web assembly gaining traction things may be looking up in the future, as a lot of these ideas get rolled into the browser natively.
yeah, web components gaining tractions since 2011...
lol. web components are a waste of time unless someone wants to write a widget with ShadowDOM. Its clear. Svelte has won and is the last thing web can give us. Lets all go home
What's wrong with the regular DOM?
Shadow DOM having better performance is a myth.
Google it.
Shadow DOM having better performance is a myth.
Google it.
There is no „wrangling the build-chain“ if you use the available clis all frameworks come with in advance.
Well since there's a plural in "CLIs", that goes into the "wrangling" category for me. If the dev/dep process involves more than one bespoke tool (looking at you js/Node monstrosities) and learning the arcana of their interactions, I'm out.
Well, I guess you‘re out of programming as a whole then, no? Most languages and dev process involve a lot of configuration or „bespoke tools“ and learning the arcane of their interactions.
Java? Gradle. JUnit. Maven. JavaDoc. etc.
C/CPP? Make. CMake. Various dependency management tools. Maybe your OS native dependency manager
Your OS? Brew / Yay / pacman / app-get / vim config / IDE configuration / environment tools / ...
Deployment? Docker. Jenkins. Travis. Kubernetes.
Coming back to „js monstrosities“, if you ever had the fun to poke around in the literal arcane magicks that are C++ dependency management systems and giant CMAKE files, you‘d love node. In fact, most cli tools are just for templating projects or generating boilerplate for components. They aren‘t arcane or complicated at all.
Configuration is half of programming or dev ops. If you don‘t like it, maybe it just isn‘t for you.
Java? Gradle. JUnit. Maven. JavaDoc. etc.
C/CPP? Make. CMake. Various dependency management tools. Maybe your OS native dependency manager
Your OS? Brew / Yay / pacman / app-get / vim config / IDE configuration / environment tools / ...
Deployment? Docker. Jenkins. Travis. Kubernetes.
Coming back to „js monstrosities“, if you ever had the fun to poke around in the literal arcane magicks that are C++ dependency management systems and giant CMAKE files, you‘d love node. In fact, most cli tools are just for templating projects or generating boilerplate for components. They aren‘t arcane or complicated at all.
Configuration is half of programming or dev ops. If you don‘t like it, maybe it just isn‘t for you.
I understand what you mean but disagree. I merely appreciate tools that make some effort to standardise their UX. Of course configuration is going to be a major part of the system; however that doesn't mean I must use fragmented tools to manage them.
For instance, I avoid touching those Java tools you mention (or Javascript), preferring leiningen et al. from the Clojure ecosystem. If I don't want to deal with CMAKE or whatever the hell php or perl or erlang or go use, I can use my distro's package manager (coincidentally, yay) to abstract them away. If something goes wrong (which rarely happens these days!) it's even money that the problem comes from some Node/JS intermediate abomination which doesn't even show you the curtesy of being tractable in its scope or mode of operation.
And your last line is uncalled for. I'm happy you like the current state of affairs, but my very subjective view is that I'm not affected by the JS-land Stockholm syndrome. Doesn't mean I don't enjoy dealing with the domain problems :)
For instance, I avoid touching those Java tools you mention (or Javascript), preferring leiningen et al. from the Clojure ecosystem. If I don't want to deal with CMAKE or whatever the hell php or perl or erlang or go use, I can use my distro's package manager (coincidentally, yay) to abstract them away. If something goes wrong (which rarely happens these days!) it's even money that the problem comes from some Node/JS intermediate abomination which doesn't even show you the curtesy of being tractable in its scope or mode of operation.
And your last line is uncalled for. I'm happy you like the current state of affairs, but my very subjective view is that I'm not affected by the JS-land Stockholm syndrome. Doesn't mean I don't enjoy dealing with the domain problems :)
It's like you've never seen a webpack "config file"...
I have. Compared to what most back-end languages have to offer (CMake and the like), it‘s a joy to use, pretty straightforward and well documented.
C/C++ != "most backend languages". Python, Ruby, Go and, Rust are much more commonly used on the backend and none of them have build systems as ugly as C nor as over-engineered and messy as JS.
> Python, Ruby, Go and, Rust are much more commonly used on the backend
Uhhh. They are popular nowadays, but the sheer volume of old CRUD backends in Java or C++ still outweighs these systems. If not, they are at least equal I'd wager.
However, they may be overengineered or not. We don't know, because they had enough time to mature and decide on industry standards. In fact, the newer JS buildsystems are, the less surface level APIs they expose. Take the newer CRA versions for example. Like cargo or pip, most of the complicated things are abstracted away.
I also don't think they are over engineered. When building software for browsers, you need to adress many different things at once. Most build systems compile some form of templating, CSS syntax and JavaScript flavours. They need to target different browsers and their versions for example. Furthermore, you can't build JS and output it into an universally understood binary format. You have to care for different browsers, their level of ECMAScript they support, if or if not they support specific CSS syntax, bundle size, how images are imported, how SVSs are imported, more assets management and so on. For most backend things, you just pack things into one huge binary and its fine.
I'm not saying modern JS bundlers and build systems are the best we can do. I'm just saying what's there works for the majority, and we're getting there eventually.
Uhhh. They are popular nowadays, but the sheer volume of old CRUD backends in Java or C++ still outweighs these systems. If not, they are at least equal I'd wager.
However, they may be overengineered or not. We don't know, because they had enough time to mature and decide on industry standards. In fact, the newer JS buildsystems are, the less surface level APIs they expose. Take the newer CRA versions for example. Like cargo or pip, most of the complicated things are abstracted away.
I also don't think they are over engineered. When building software for browsers, you need to adress many different things at once. Most build systems compile some form of templating, CSS syntax and JavaScript flavours. They need to target different browsers and their versions for example. Furthermore, you can't build JS and output it into an universally understood binary format. You have to care for different browsers, their level of ECMAScript they support, if or if not they support specific CSS syntax, bundle size, how images are imported, how SVSs are imported, more assets management and so on. For most backend things, you just pack things into one huge binary and its fine.
I'm not saying modern JS bundlers and build systems are the best we can do. I'm just saying what's there works for the majority, and we're getting there eventually.
Do people not re-use previous configs as a starting point for new projects?
Webpack is difficult to figure out at first, but if you have an existing config it should be a lot easier.
Webpack is difficult to figure out at first, but if you have an existing config it should be a lot easier.
It's not always that easy. Most of the pain around webpack configs comes from dealing with them later, not when starting the project. It might've been written by someone before you and modified by multiple people. Now you have to figure out how to add something new, intended for a different pipeline, into your existing pipeline, which has years of changes you probably don't understand in it.
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.
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.
My advice to anyone that starts off loving code: focus on maximizing your revenue, minimizing your cost, and be careful with your commitments. One day you will hate working with these damn machines, and it isn't the machine but everything else.
My target goal is to retire soon-ish, and I'll dick around with my own stupid programming language around board games: http://www.adama-lang.org/
I don't intend to rally stake-holders about it.
I fully expect to tinker on this for a decade without any love, and that's just fine with me.
I don't intend to defend my decisions, or justify why this thing exists.
My target goal is to retire soon-ish, and I'll dick around with my own stupid programming language around board games: http://www.adama-lang.org/
I don't intend to rally stake-holders about it.
I fully expect to tinker on this for a decade without any love, and that's just fine with me.
I don't intend to defend my decisions, or justify why this thing exists.
Now I make home-cooked apps [1]. I think you'll like this article.
[1] https://www.robinsloan.com/notes/home-cooked-app/
[1] https://www.robinsloan.com/notes/home-cooked-app/
The few backend devs I've talked to have agreed that the world spins a bit slower in the back-end side of things, without having weekly "chapter meetings" to discuss how the code we wrote last week is now obsolete. Backend devs are also much more versed in writing decent, performant code, to my experience - whereas the majority of front-end devs I've worked with have no idea why you should try to avoid writing loops in loops. But of course, everything can be bad, and it also varies from org to org, so here's to hoping my first back-end role won't suck because otherwise I'd be pretty sad.
When React and Angular became popular I realized with great sadness that I was no longer a full stack dev and that I would never ever be one again. There's a whole group of us at work. The young devs laugh at our front-end abilities but they also look up to us because of our ability to elegantly hide our loops within loops within loops, with Linq.
I haven't seen a performant LOB app in years.
I haven't seen a performant LOB app in years.
My last frontend job was a few years ago, but I'm still writing VueJS apps the same way I used to. I don't feel like anything has really changed since then. I just got better at using the same tools.
The only meaningful change from my perspective is that browsers can do more things.
Backend is nice because you have greater control over the environment, and because testing data flows is easier than testing user interfaces. However, I was not a big fan of devops and cloud stuff, which felt too abstract to me.
The only meaningful change from my perspective is that browsers can do more things.
Backend is nice because you have greater control over the environment, and because testing data flows is easier than testing user interfaces. However, I was not a big fan of devops and cloud stuff, which felt too abstract to me.
Slower perhaps, but it has definitely accumulated its share of complexity and ceremony along the way.
Much of it is basic CRUD, built on top of a tower of complexity, crammed into a container and served by whatever cloud provider.
I spend most of my time plugging and praying/crying.
Much of it is basic CRUD, built on top of a tower of complexity, crammed into a container and served by whatever cloud provider.
I spend most of my time plugging and praying/crying.
My work feels like 5% analysis, 5% writing algorithms, 20% writing boilerplate code, 70% integration with some complex ill-documented monstrosity and debugging.
The Kubernetes ecosystem is proof that backend engineers are perfectly capable of overcomplicating things too, thank you very much.
You can still deploy stuff on a plain application server or whatever. The tools I've worked with haven't really required touching any kind of cluster management or other overhyped (albeit in some cases necessary) and complicated backend stuff if you didn't want to. (My backend experience is with Java and Python, though. I don't know how things are with other backend languages.)
When I started looking into putting together a simple but modern frontend in my own time after having done only backend for years, it seemed like there's quite a lot of tooling and associated complexity that you kind of have to deal with just to get your frontend deployed, whether you need a complex architecture or not.
When I started looking into putting together a simple but modern frontend in my own time after having done only backend for years, it seemed like there's quite a lot of tooling and associated complexity that you kind of have to deal with just to get your frontend deployed, whether you need a complex architecture or not.
> "oops" is a valid commit message and "bugger off" is a valid response to stakeholders.
I'm thinking about making a T-shirt with this phrase. Because it's important.
I'm thinking about making a T-shirt with this phrase. Because it's important.
> "bugger off" is a valid response to stakeholders.
Sometimes "bugger off" is a valid response to stakeholders, even in a professional context: you just have to know how to say it.
I really started to feel like, after three and a half years, I was succeeding the other day when one of my product managers told a stakeholder to bugger off and they did without even challenging it.
Sometimes "bugger off" is a valid response to stakeholders, even in a professional context: you just have to know how to say it.
I really started to feel like, after three and a half years, I was succeeding the other day when one of my product managers told a stakeholder to bugger off and they did without even challenging it.
> In hindsight, I just didn't enjoy writing code for money.
This is the almost inevitable path of those who started their career thinking: how lucky am I that my hobby coincides with a well paying job.
This is the almost inevitable path of those who started their career thinking: how lucky am I that my hobby coincides with a well paying job.
It's something I was willing go sacrifice to avoid doing something else that paid worse.
> I just didn't enjoy writing code for money
I think you've touched on something essential here. It may explain the continuous appeal of open source.
Maybe it also explains how even though work is perpetually exhausting, somehow I still find energy to work on side projects, just so I can feel some uninhibited creativity.
I'm also reminded of a cynical quote from my dad. When I was young I asked him "Was work fun?" to which he responded "If work was fun they wouldn't pay you."
I think you've touched on something essential here. It may explain the continuous appeal of open source.
Maybe it also explains how even though work is perpetually exhausting, somehow I still find energy to work on side projects, just so I can feel some uninhibited creativity.
I'm also reminded of a cynical quote from my dad. When I was young I asked him "Was work fun?" to which he responded "If work was fun they wouldn't pay you."
Oh please stop.
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.
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.
Yes, the grass on the other pasture is always greener.
I especially found his hand-waving wrt language funny.
> The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn.
If thats what he thinks, then he really only experimented with very similar languages...
And the quantity of strangely applied software patterns like using statemachines to hide a simple switch-case... it would be hilarious if it wasn't so sad.
I especially found his hand-waving wrt language funny.
> The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn.
If thats what he thinks, then he really only experimented with very similar languages...
And the quantity of strangely applied software patterns like using statemachines to hide a simple switch-case... it would be hilarious if it wasn't so sad.
The difference between MIT Scratch and FORTH is superficial; it's all just mutable LISP when you get down to it.
Not every application needs to be "enterprise grade". Yet, many design teams seem to approach them all the same way. Stop the needless bloat!
This. The quality of developers has gone down in the past 10 years and it's really hard to teach maintainable Javascript to developers. They just don't understand even delegation and how to do complex UI's in plain Javascript. Either way you wouldn't really want to because it just turns to crap. The frameworks have been great for companies.
> The quality of developers has gone down in the past 10 years
Well, there we go. Why would that be? It seems a very sad state of affairs. A genuine question: what has happened here? Constructively, we need frameworks for different skills - why are we expecting designers and UI experts to deal with dependency management? Let's let them do what they are good at.
"Developers" is too wide a term, for a start. Cutting through the abstraction and thinning down the frameworks so we can achieve the same thing with less is a very different discipline to making a site look nice. Let's all work together.
Well, there we go. Why would that be? It seems a very sad state of affairs. A genuine question: what has happened here? Constructively, we need frameworks for different skills - why are we expecting designers and UI experts to deal with dependency management? Let's let them do what they are good at.
"Developers" is too wide a term, for a start. Cutting through the abstraction and thinning down the frameworks so we can achieve the same thing with less is a very different discipline to making a site look nice. Let's all work together.
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 ;).
You're usually not the one deciding which stack to use and evem when you are, if you don't use the latest shiny framework and put it on your CV, you're not getting your next job.
A big problem is also support by libraries. Back in the day, you could find dozens of libraries to do what you wanted and they worked regardless of your stack because it was all JS anyways (the exception were jQuery plugins, but jQuery is pretty good about not fighting native APIs, so you could still integrate those even if you weren't using jQuery elsewhere). These days, it's pretty hard to find modern libraries that just give you a CDN URL and an init function - most don't even build shippable sources because they expect you to use webpack or whatever, not to mention, that you can find the exact same component ported to Vue, React, Angular etc. but very rarely also to "native DOM", for lack of a better term.
A big problem is also support by libraries. Back in the day, you could find dozens of libraries to do what you wanted and they worked regardless of your stack because it was all JS anyways (the exception were jQuery plugins, but jQuery is pretty good about not fighting native APIs, so you could still integrate those even if you weren't using jQuery elsewhere). These days, it's pretty hard to find modern libraries that just give you a CDN URL and an init function - most don't even build shippable sources because they expect you to use webpack or whatever, not to mention, that you can find the exact same component ported to Vue, React, Angular etc. but very rarely also to "native DOM", for lack of a better term.
I don't think that's realistic for the majority of front-end developers working at companies. Even for freelancers the client will often have existing tech in place or a preference.
For personal projects of course, we can do whatever we want. But I don't make a living with personal projects. I do that by working for a company 8 hours mon-fri, and there I am not in charge of the tech stack used.
Good thing too because otherwise these retro hipster devs would block every new feature with the excuse "Its not possible to do that without reloading the page in raw html"
Having your site work with "raw html" pays off several times over in my opinion, even if you completely ignore people who actually turn off Javascript:
- Page navigation becomes easier if you know the server can handle any route you throw at it as a launch point.
- You can get by with cheaper end-to-end tests for critical flows by not using Javascript in your test suite (although you should be careful to use it when it's important)
- You get a degree of protection if something does go wrong on the front end that you get a non-JS experience to fall back to.
- Pages that genuinely don't need Javascript (think like simple CRUD forms) don't have to pay the SPA tax.
- Page navigation becomes easier if you know the server can handle any route you throw at it as a launch point.
- You can get by with cheaper end-to-end tests for critical flows by not using Javascript in your test suite (although you should be careful to use it when it's important)
- You get a degree of protection if something does go wrong on the front end that you get a non-JS experience to fall back to.
- Pages that genuinely don't need Javascript (think like simple CRUD forms) don't have to pay the SPA tax.
Thats true. But I guess for big project there was a reason to choose some framework. Usually with big projects without any framework you would end up with your own custom framework anyway to speed up development and it would cause onboarding new team members would be harder. But sometimes this is also necessary, look at FB, they built React because they needed it and later it was adopted by community and other companies. Its realy just about what your project needs. Btw. with backend development its same or maybe worse. There are as many languages and frameworks for backend development as stars on the sky :D.
Absolutely! The article conflates hobbyist and professional web development. Having a play as a teenager in your free time? By all means, use single html, css and js file. With javascript modules, it's much nicer these days than it used to be in 2007 anyway. Working on a project in a company? You probably want all the guiding rails that package managers, type checking or bundling will give you anyway. Frameworks? With web components, you might not need them.
This. But, I would extend it to say that if you are solo dev it may also make sense to just use base JS to get stuff out quicker. If you have a team, then frameworks start making more sense b/c it extends best practices farther into the app.
One of the problems I've seen is when your manager/client/executive has heard of docker/AWS/k8s/React/SPA/thecloud/etc and the specification for the new system says it must use docker/AWS/k8s/React/SPA/thecloud/etc regardless of whether it's even vaguely appropriate.
Part of being a good engineer is pushing back when clients and managers start making bad engineering decisions.
Also part of being a good engineer is working well on a team, and if fashion dictates that everyone uses overly complex SPA apps, you're not going to be successful being the lone voice fighting against current trends.
> All these technologies are just tools and you decide what tool you choose to get work done
Setting priorities is hard and developers want to try new shiny stuff for fun and also to feel up-to-date.
It usually goes like this, some developers pitch framework X, promising to improve metric Y. In the process many parts of the system change, making it incredibly hard to validate the improvement on metric Y. There's also lack of incentives to validate tech choices. On the other hand being familiar with many frameworks makes some devs feel more senior compared to their colleagues or competition.
Backend development suffers from this as well, you'll be surprised to learn how many nano-scale companies, employing a handful of developers practice buzzword-driven development, with a stack consisting of microservices, Kafka, NoSQL, lambdas.
Setting priorities is hard and developers want to try new shiny stuff for fun and also to feel up-to-date.
It usually goes like this, some developers pitch framework X, promising to improve metric Y. In the process many parts of the system change, making it incredibly hard to validate the improvement on metric Y. There's also lack of incentives to validate tech choices. On the other hand being familiar with many frameworks makes some devs feel more senior compared to their colleagues or competition.
Backend development suffers from this as well, you'll be surprised to learn how many nano-scale companies, employing a handful of developers practice buzzword-driven development, with a stack consisting of microservices, Kafka, NoSQL, lambdas.
That may be true in isolated cases but I don't think that wide-scale adoption of these technologies is some form of mass hysteria. I think it is because they solve real problems. I am not really a fan of the modern JS ecosystem for a variety of reasons but building stuff in React seems infinitely easier to me than writing plain HTML/CSS. I'm sure if you cut your teeth writing HTML/CSS (I didn't, have mostly been a backend developer) then you don't need to fancy new tools, but I hear an echo of "why does anyone need a garbage collector?" or "why use C when you can just write in assembler?" in these sorts of comments.
There's nothing stopping anyone using simple straightforward project setup, but you don't see them complaining here because there is nothing to complain about.
What’s forcing people to use these frameworks is compatibility with the rest of the world. It’s like an arms race where if you don’t use typescript, you can’t use the library you want because they do. And so on and so forth. It’s like wanting to stay on Ubuntu 12, with only security fixes. You can’t because whatever else you need to install requires Ubuntu 16, etc etc.
Management hires by heuristic, people are cargo culting. Those are two reasons I can think of why you have to use React/TS on everything atm. Unless you're building your own project not at work of course.
My own project is in C++ :) Not that it makes anything easier, but I'm not OP, just a full-stack web dev, so ... :P
My own project is in C++ :) Not that it makes anything easier, but I'm not OP, just a full-stack web dev, so ... :P
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.
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...
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...
The increased brittleness of so many JS components is a real maintenance issue that can impact progress.
> 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 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.
It’s not necessarily worse but it could be as tangled and bad because of other reasons. The rapid pace in the evolution of Js frameworks created a lot more problems than on the back end IMO
Remember that JS is used in the backend too (Node.JS / Deno). But I agree, the situation there at least is moving slowly compared to the frontend world.
> There's everything from logging and metrics to databases to pipelines and task managers to physical hardware and networking tools.
Sure, but nobody in marketing is bothering you to use Javascript-framework-du-jour on the backend so they can put it on their sales slide.
You can write the backend in totally boring technology and no one will ever know or care.
Sure, but nobody in marketing is bothering you to use Javascript-framework-du-jour on the backend so they can put it on their sales slide.
You can write the backend in totally boring technology and no one will ever know or care.
> marketing is bothering you to use Javascript-framework-du-jour on the backend so they can put it on their sales slide.
I’ve worked in frontend for five years and this has never been a thing that happened. If a framework is important to your marketing, that would be because your customers have to use it to interface with your product. The same would be true if your customers had to interact with your backend; they would want an API in popular languages, trendy languages and frameworks too.
I’ve worked in frontend for five years and this has never been a thing that happened. If a framework is important to your marketing, that would be because your customers have to use it to interface with your product. The same would be true if your customers had to interact with your backend; they would want an API in popular languages, trendy languages and frameworks too.
I work in one of the big old industries and we commission web shops to build first versions of web apps that internal IT then takes over for maintenance and future iterations.
We have standardized on Angular on the frontend and require providers to use it. The backend tech is less critical, it can be one of Java, JS, or Python and the important point is a JSON/REST interface with Swagger documentation.
We have standardized on Angular on the frontend and require providers to use it. The backend tech is less critical, it can be one of Java, JS, or Python and the important point is a JSON/REST interface with Swagger documentation.
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.
As much as I completely agree with your attitude, and try to live it myself, software engineers don't get to make their own tooling choices. That is the fundamental problem here.
We don't get to choose the technology(framework) that will result in the least amount of hassle and easiest to maintain software artifact. Instead, we get stuck using what someone else chose for us.
We don't get to choose the technology(framework) that will result in the least amount of hassle and easiest to maintain software artifact. Instead, we get stuck using what someone else chose for us.
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.
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.
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.
I don't quite get the frustration.
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.
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.
Surely this line of thinking has the potential to lead to "I know NextJS best so every problem looks like a NextJS problem" ? If you limit yourself to the surface area of one tool, you become reliant on the authors of that tool to solve the problems you need solved. Then if that tool declines for some reason you have to look for another tool that solves all the same set of problems for you. Not to mention you'll probably find your job opportunities limited if you're all in on one tool.
I think you are spot on when you say learn the underlying fundamentals but that should be extended to the web platform. Learn how to manage state outside of your favorite library. Learn how to cache your assets and HTTP responses using service workers. Learn the general ideas behind MVVM views so you can look at another library, get the gist and get going.
My best lecturer in college told us that he wasn't teaching us specific algorithms or MVC or the DOM APIs. He was teaching us how to learn. That there are common patterns and fundamentals and "new" things are usually similar to existing things in some way. Usually when I see some new frontend library, I see a concept that has been recycled or stolen from some other library and presented as new. I don't believe there is much novel work being done put out there. Even stuff that qualifies as somewhat novel like Svelte is really just a refinement of the road React started us down.
It probably takes a bit of work, and sometimes luck, to figure out what's transient and whats important universal stuff but once you start looking at things that way, it makes it a lot easier to appraise the new stuff and figure out if its worth your time or not. Then if you need to solve a problem its not about how NextJS can be twisted to fit it but just taking the components you need and assembling them in a way that makes sense.
Maybe this approach just requires more learning than is reasonable for most people, I don't know. I personally like learning, seeing what makes things tick and how everything fits together.
I think you are spot on when you say learn the underlying fundamentals but that should be extended to the web platform. Learn how to manage state outside of your favorite library. Learn how to cache your assets and HTTP responses using service workers. Learn the general ideas behind MVVM views so you can look at another library, get the gist and get going.
My best lecturer in college told us that he wasn't teaching us specific algorithms or MVC or the DOM APIs. He was teaching us how to learn. That there are common patterns and fundamentals and "new" things are usually similar to existing things in some way. Usually when I see some new frontend library, I see a concept that has been recycled or stolen from some other library and presented as new. I don't believe there is much novel work being done put out there. Even stuff that qualifies as somewhat novel like Svelte is really just a refinement of the road React started us down.
It probably takes a bit of work, and sometimes luck, to figure out what's transient and whats important universal stuff but once you start looking at things that way, it makes it a lot easier to appraise the new stuff and figure out if its worth your time or not. Then if you need to solve a problem its not about how NextJS can be twisted to fit it but just taking the components you need and assembling them in a way that makes sense.
Maybe this approach just requires more learning than is reasonable for most people, I don't know. I personally like learning, seeing what makes things tick and how everything fits together.
Yes, you are right. I might have phrased it without looking at it over a longer term.
Are you too young to have missed the mootools > jquery > handlebar > mustache > backbone > knockout > angular > react years?
Or have you already forgotten that what is "here to stay, mature, and has a large community" seems to change every few years in javascript?
Or have you already forgotten that what is "here to stay, mature, and has a large community" seems to change every few years in javascript?
To be fair, you could have gone through those years with an every-other approach: I know I basically did
- Very late MooTools (almost none) - jQuery - Backbone - React
It's not like these projects shift community blessing that quickly; it might feel like it, but these things in reality are well supported past their "peak" for at least a year or so. Your projects will still work. If you have enough of a handle on vanilla JS, these changes weren't really too obstructive.
I think that's probably the most important message for the JS community here: change can be fine, good, even - but change doesn't need to happen at warpspeed.
- Very late MooTools (almost none) - jQuery - Backbone - React
It's not like these projects shift community blessing that quickly; it might feel like it, but these things in reality are well supported past their "peak" for at least a year or so. Your projects will still work. If you have enough of a handle on vanilla JS, these changes weren't really too obstructive.
I think that's probably the most important message for the JS community here: change can be fine, good, even - but change doesn't need to happen at warpspeed.
On the frontend I try to stick to react as much as possible, for SPAs of course but also static-sites through Gatsby or mobile applications with react-native. This isn't through devotion, I just find it easy to work with and do what I want to do, plus the wealth of high-quality components that I can just pull in is a major bonus.
Maybe it's because I lack skill but I struggle with raw browser languages. I fight with CSS and it the end it always looks and feels clunky, and HTML doesn't offer any solutions for component reuse. I've worked with pug to get consistent interfaces, but it's still a bit clunky. Funnily enough I don't mind raw DOM manipulation with JS or using jQuery but overall am still more productive with react.
Regarding the state management solutions (and hype generally) I think it's worthwhile being aware that they exist. My suggestion is to know what they're for but resist the urge to just "try them out" even if a potential use-case arises. When you're tearing your hair out trying to do something using your current toolbox, consider the appropriate technologies in your reading list (mobX, redux, kubernetes, etc.) and try them out on your toughest problem. Going the opposite direction is recommended too, remove redux/MobX where a simple useState passed down from the parent will do.
Maybe it's because I lack skill but I struggle with raw browser languages. I fight with CSS and it the end it always looks and feels clunky, and HTML doesn't offer any solutions for component reuse. I've worked with pug to get consistent interfaces, but it's still a bit clunky. Funnily enough I don't mind raw DOM manipulation with JS or using jQuery but overall am still more productive with react.
Regarding the state management solutions (and hype generally) I think it's worthwhile being aware that they exist. My suggestion is to know what they're for but resist the urge to just "try them out" even if a potential use-case arises. When you're tearing your hair out trying to do something using your current toolbox, consider the appropriate technologies in your reading list (mobX, redux, kubernetes, etc.) and try them out on your toughest problem. Going the opposite direction is recommended too, remove redux/MobX where a simple useState passed down from the parent will do.
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.
With stability come expectations!
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!
And with expectations come new jobs, no matter how well automation delivers. Robots and software aren't gonna make us jobless because expectations will fill up and overflow any volume of possibilities.
Plus - someone's got to make those robots!
Then we're into the "AI" conversation, where I think the general public think we're a lot closer to AI than we really are... Just because we have 90% reliable speech recognition and it can convert that to a basic google request, and parse some likely results, does not make Siri/Alexa/etc "intelligent".
Then we're into the "AI" conversation, where I think the general public think we're a lot closer to AI than we really are... Just because we have 90% reliable speech recognition and it can convert that to a basic google request, and parse some likely results, does not make Siri/Alexa/etc "intelligent".
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.
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.
You can finally write what is essentially just HTML and JavaScript!
To be fair, it is html+js that is: hot-reloadable, so you don’t have to click here and there again and again; modular so you don’t have to write a mile long htmls with 80-column indents; you can import other’s work and reuse it; not care about missing features in a “cross-platform” “browser”; not depend on cdn latency and availability; have a proper debugger.
That said, personally I don’t understand this react/redux madness. I understand how it works and how to do things in it, but the general idea misses me. It is all hand-wavy funkchyonal rhetoric with learning curves and budgets that are beyond all reason. Seems like a young religion.
In defense of component frameworks, try making a proper input field that accepts “1 000 00”, formats it into “10,000.00” at focus-out without interfering with a user while they are editing it, yields 10000 into your model in real-time, and present a hint when they try to enter “qwe”, without breaking your data model with NaN. Then we’ll talk about raw html+js or jquery.
To be fair, it is html+js that is: hot-reloadable, so you don’t have to click here and there again and again; modular so you don’t have to write a mile long htmls with 80-column indents; you can import other’s work and reuse it; not care about missing features in a “cross-platform” “browser”; not depend on cdn latency and availability; have a proper debugger.
That said, personally I don’t understand this react/redux madness. I understand how it works and how to do things in it, but the general idea misses me. It is all hand-wavy funkchyonal rhetoric with learning curves and budgets that are beyond all reason. Seems like a young religion.
In defense of component frameworks, try making a proper input field that accepts “1 000 00”, formats it into “10,000.00” at focus-out without interfering with a user while they are editing it, yields 10000 into your model in real-time, and present a hint when they try to enter “qwe”, without breaking your data model with NaN. Then we’ll talk about raw html+js or jquery.
> ... try making a proper input field [...]. Then we’ll talk about raw html+js or jquery.
Quick Google search and 15 seconds later: http://www.decorplanit.com/plugin/ (one of many, I picked one that closest resembled your reqs)
I find your lack of faith in jQuery disturbing.
Quick Google search and 15 seconds later: http://www.decorplanit.com/plugin/ (one of many, I picked one that closest resembled your reqs)
I find your lack of faith in jQuery disturbing.
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
That actually sounds kind of wonderful. I’m sick of the technology treadmill.
Same here. But with Smarty templates.
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.
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.
I think you should answer yourself what you don't like about writing tests in FE. I personally like writing them (at least for my personal project), but I think tools are still evolving in FE testing. E.g. I have recently found out about Playwright and it is step forward compared to Puppeteer: automatic waits and codegen tool is what makes Playwright the joy to work with.
I'm still looking how to improve FE testing but it is something what absolutely makes my life easier.
I'm still looking how to improve FE testing but it is something what absolutely makes my life easier.
My comment was actually around Node JS. Writing unit and integration test for async server code and god forbid some kind of critical or secure code is not something I'm comfortable doing.
As far as FE testing I don't have any issue with that as long as the value and trade-offs are well understood and not just writing tests for the sake of it.
As far as FE testing I don't have any issue with that as long as the value and trade-offs are well understood and not just writing tests for the sake of it.
Oh. Sorry I must have misread your comment then :-) For Node BE code I either end-up writing pseudo e2e tests (e.g. using supertest like here https://github.com/daliusd/cardamon/blob/master/app.test.js) and/or testing individual components by separating them out from express stuff.
I would like to invite you to try htmx:
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.
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.
I'm trying htmx after years of frustration with all other SPAs and build tools and changes.
after reading the site I still feel I need a little more information, is there known projects made with htmx somewhere for me to study?
Thanks for the great work!!
after reading the site I still feel I need a little more information, is there known projects made with htmx somewhere for me to study?
Thanks for the great work!!
It's pretty new but people are starting to publish information on using it:
https://www.mattlayman.com/blog/2021/how-to-htmx-django/
https://www.jerriepelser.com/blog/using-htmx-with-aspnet-cor...
You can also join the discord server if you have questions:
https://htmx.org/discord
https://www.mattlayman.com/blog/2021/how-to-htmx-django/
https://www.jerriepelser.com/blog/using-htmx-with-aspnet-cor...
You can also join the discord server if you have questions:
https://htmx.org/discord
Great. Thanks!
Sad for the author.
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.
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.
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.
I like javascript.
It’s lightweight and very flexible.
No other language has async built in at such a fundamental level.
It’s incredibly easy to throw anonymous functions around.
It’s destructuring is incredibly powerful.
JavaScript code is concise.
Recent versions such as es6 have made it better.
It’s lightweight and very flexible.
No other language has async built in at such a fundamental level.
It’s incredibly easy to throw anonymous functions around.
It’s destructuring is incredibly powerful.
JavaScript code is concise.
Recent versions such as es6 have made it better.
I think the author would agree. They are bemoaning Typescript which is everything but lightweight and the build chain.
JS for me was a very nice change from the heavyweight OOP languages but now what the usual stack implies is just as bloated and obtuse.
JS for me was a very nice change from the heavyweight OOP languages but now what the usual stack implies is just as bloated and obtuse.
This was my main reason to switch to mainly front-end: to get away from clunky, badly written C# and Java back-end programming. 2/3 of a code file are just the coder wrangling the OOP typesystem instead of just coding the functionality that is needed.
I do like Typescript if you just use it minimally: you can type (I prefer interfaces usually) argument types and rely on the compiler to infer types.
But then the OOP fundamentalists got their hands on it and now they want strict type checking and believe that it makes their code bulletproof https://indepth.dev/posts/1402/bulletproof-angular
I do like Typescript if you just use it minimally: you can type (I prefer interfaces usually) argument types and rely on the compiler to infer types.
But then the OOP fundamentalists got their hands on it and now they want strict type checking and believe that it makes their code bulletproof https://indepth.dev/posts/1402/bulletproof-angular
Strict type checking does make your code bulletproof. Unfortunately, TypeScript doesn't provide anything close to that. It's easier to mask errors with TypeScript than auto-detect them. Its strict typing should be considered hints for the programmer.
Real strict type checking (as in, eg, Haskell ) does indeed make your code resistant to a certain type of bug. But the kind of type checking Typescript gives you is mostly useful as autocomplete.
(and, if I'm not mistaken, at run time, you can still add or remove properties from an object and re-introduce bugs. Which can happen with 3rd party libraries, for example.)
(and, if I'm not mistaken, at run time, you can still add or remove properties from an object and re-introduce bugs. Which can happen with 3rd party libraries, for example.)
At runtime, you can pass primitives to a function that expects a very specific DOM object (say), and it'll just plough on ahead like JavaScript does, until you get an exception that nothing catches because FooFunction doesn't raise any exceptions, and everything breaks.
Oh, and did I mention that virtually every browser API these days is potentially optional, with the undefined primitive replacing bits and pieces of them at seemingly random, depending on browser version and configuration, and the presence or absence of certain extensions…? I like the idea of TypeScript, I really do, but don't even try to use it for FFI (where “foreign” is anything outside your TypeScript module).
Oh, and did I mention that virtually every browser API these days is potentially optional, with the undefined primitive replacing bits and pieces of them at seemingly random, depending on browser version and configuration, and the presence or absence of certain extensions…? I like the idea of TypeScript, I really do, but don't even try to use it for FFI (where “foreign” is anything outside your TypeScript module).
Yeah the setup-project boilerplaye stuff is a mess.
Luckily for backend it's super easy to set up typescript as the default are good enough for weekend projects/prototypes:
``` mkdir my-project cd my-project npm init -f npm i -D typescript ts-node @types/node npx tsc init touch index.ts npx ts-node index.ts ```
Luckily for backend it's super easy to set up typescript as the default are good enough for weekend projects/prototypes:
``` mkdir my-project cd my-project npm init -f npm i -D typescript ts-node @types/node npx tsc init touch index.ts npx ts-node index.ts ```
I do agree indeed! It has its quirks, but all-in-all easy to use and get stuff done. Not to mention no need to set-up a compiler or anything. It just works.
> No other language has async built in at such a fundamental level.
I'm not sure that that is true. Rust and Python both have built-in async; while they both have their own takes on what that means, I wouldn't say JavaScript's “syntactic sugar on top of promises, which are object sugar on top of callbacks” is any more of a fundamental level.
I'm not sure that that is true. Rust and Python both have built-in async; while they both have their own takes on what that means, I wouldn't say JavaScript's “syntactic sugar on top of promises, which are object sugar on top of callbacks” is any more of a fundamental level.
Rust does have syntactic support for async but that's not the only thing you need to use async. You also need an async executor runtime, for example tokio. This can cause all sorts of headaches in practice when you want to use libraries which rely on incompatible async runtimes.
You only need an async executor to deal with threading issues; you can completely side-step it if everything's single-threaded (coöperative multi-tasking) or thread-agnostic (Send + Sync). And an executor like smol has no compatibility issues with anything; you just run it.
Python has an async executor, yes, but only to let you do things you can't do with coöperative multi-tasking.
JavaScript has an executor, too. The only difference is that you can't turn it off. It's actually less capable than (most of the) Rust implementations, because JavaScript's single-threaded. (Python's an in-between case, thanks to the Global Interpreter Lock; good JavaScript engines should be able to match Python's concurrency capabilities.)
Executors are only important for things like timers. JavaScript's promises rarely make use of them, except when they schedule their callbacks based on something external to the JavaScript (your “primitive” promises on top of which everything is built). Both Python and Rust work the same way.
The only difference with JavaScript is that it Just Works™ (or, rather, just works; because it does) – but that comes at the cost of sticking JavaScript with a permanently single-threaded runtime.
Python has an async executor, yes, but only to let you do things you can't do with coöperative multi-tasking.
JavaScript has an executor, too. The only difference is that you can't turn it off. It's actually less capable than (most of the) Rust implementations, because JavaScript's single-threaded. (Python's an in-between case, thanks to the Global Interpreter Lock; good JavaScript engines should be able to match Python's concurrency capabilities.)
Executors are only important for things like timers. JavaScript's promises rarely make use of them, except when they schedule their callbacks based on something external to the JavaScript (your “primitive” promises on top of which everything is built). Both Python and Rust work the same way.
The only difference with JavaScript is that it Just Works™ (or, rather, just works; because it does) – but that comes at the cost of sticking JavaScript with a permanently single-threaded runtime.
I think Kotlin beats JS on all those metrics by a long way. And you can compile Kotlin to JS if you want.
You can still write PHP and jQuery. Most clients don’t care what stack you use as long as it works and it’s fast.
I still haven’t found a good use case for React and I’m doing just fine.
SASS is great, I wish native CSS was like that, but it’s not that nice to be worth a preprocessor.
Same with typescript. Sure would be nice to have optional types in JavaScript, but not important enough to go through all these hoops.
I still haven’t found a good use case for React and I’m doing just fine.
SASS is great, I wish native CSS was like that, but it’s not that nice to be worth a preprocessor.
Same with typescript. Sure would be nice to have optional types in JavaScript, but not important enough to go through all these hoops.
Personally I find VueJS a joy to work with on the FE. It eschews some of the complexities that come with React and gives you a comprehensive and simple state based component rendering framework.
Vue's cli tool means that you don't have to worry about installing all the dependencies, just answer the setup questions about how you like to work and it installs everything for you: Typescipt, sass, babel, eslint.. all of it installed for you.
I absolutely do not yearn for the SSR template days. Sure when you're composing green field it's straight forward, but when you're coming into a complex project 3 years later, figuring out where on earth the JS is that's impacting this particular screen (or causing this particular bug) can be an absolutely nightmare. I'll be sticking with Vue and Typescript and not reverting to jQuery, thank you very much.
Vue's cli tool means that you don't have to worry about installing all the dependencies, just answer the setup questions about how you like to work and it installs everything for you: Typescipt, sass, babel, eslint.. all of it installed for you.
I absolutely do not yearn for the SSR template days. Sure when you're composing green field it's straight forward, but when you're coming into a complex project 3 years later, figuring out where on earth the JS is that's impacting this particular screen (or causing this particular bug) can be an absolutely nightmare. I'll be sticking with Vue and Typescript and not reverting to jQuery, thank you very much.
I agree, Vue has made me interested in frontend development for the first time since jQuery!
As someone who started a few years earlier, and speaking as full-stack programmer, as it's called today, I can tell you it was always like that - an ever increasing complication graph. However, I like it. I don't miss the tcl, perl, coldfusion, php files all mixing everything up. I don't miss FTP as a means of deployment. I don't miss configuring the first Apache webserver, or setting up the Sun servers and using csv text files as databases.
I embrace the complexity because it's there for a reason. Most of it. Some of it at least. It solves problems we already forgot we had. And it's cyclical. We'll soon forget what the problem was, go back to square one, and given some time arrive back to where we are today and then some.
My advice - embrace the complex, reject the complicated.
I embrace the complexity because it's there for a reason. Most of it. Some of it at least. It solves problems we already forgot we had. And it's cyclical. We'll soon forget what the problem was, go back to square one, and given some time arrive back to where we are today and then some.
My advice - embrace the complex, reject the complicated.
This. It's a cycle of bundled complexity to unbundled "simplicity" and back. I'm not so sure it's even entirely unique to software.
Fortunately a lot of these frameworks provide tools that set up your project for you. I totally agree that having to configure your own webpack from scratch is hell, and not what I signed up for, but there are tools that can help us make use of the tools we need to do our jobs.
And on the backend, not everything is trivial either. Do you enjoy configuring Spring? What cloud stack do you deploy to? Or do you need a UI framework? And all the complaints I hear about npm these days, I also heard about maven 15 years ago.
The only way to avoid it is to write everything yourself, and not make use of frameworks that do most of the heavy lifting for you. Write simpler applications, I guess, or at least in a simpler environment. With complexity come the tools to manage that complexity.
And on the backend, not everything is trivial either. Do you enjoy configuring Spring? What cloud stack do you deploy to? Or do you need a UI framework? And all the complaints I hear about npm these days, I also heard about maven 15 years ago.
The only way to avoid it is to write everything yourself, and not make use of frameworks that do most of the heavy lifting for you. Write simpler applications, I guess, or at least in a simpler environment. With complexity come the tools to manage that complexity.
I have a very similar career trajectory, but starting a few years earlier. Remember web rings?
Anyway I think there were two phases of the complicated web:
- there are build tools emerging (grunt, gulp, etc) and now web apps have a build step to automate certain complexities like minification, but you write more or less plain HTML/CSS/JS or maybe transpile if you prefer.
- the build tools are your entire process and the languages you write in are constructed by an infinitely configurable set of inscrutable plugins.
I didn’t intentionally shift toward backend, but it did happen gradually between those two phases. Having spent the last few months getting reacquainted with frontend, the phases feel very distinct. I know HTML, I’ve gotten caught up on CSS. I’m perfectly comfortable with React and I love JSX for the most part. But I spend most of my time appeasing/fighting with tooling.
Even though I’m writing in the same language (TypeScript) that I’ve used for years and feel very comfortable with on Node, all the frontend types feel like a funhouse mirror reflection of the language I know. I’ve lost entire days just trying to satisfy types on a HOC.
I’m not giving up because I’m excited about my project but I can honestly understand the author’s feelings. I sincerely don’t think it has to be this difficult. And I can’t imagine being new to programming walking up to the current frontend process.
Anyway I think there were two phases of the complicated web:
- there are build tools emerging (grunt, gulp, etc) and now web apps have a build step to automate certain complexities like minification, but you write more or less plain HTML/CSS/JS or maybe transpile if you prefer.
- the build tools are your entire process and the languages you write in are constructed by an infinitely configurable set of inscrutable plugins.
I didn’t intentionally shift toward backend, but it did happen gradually between those two phases. Having spent the last few months getting reacquainted with frontend, the phases feel very distinct. I know HTML, I’ve gotten caught up on CSS. I’m perfectly comfortable with React and I love JSX for the most part. But I spend most of my time appeasing/fighting with tooling.
Even though I’m writing in the same language (TypeScript) that I’ve used for years and feel very comfortable with on Node, all the frontend types feel like a funhouse mirror reflection of the language I know. I’ve lost entire days just trying to satisfy types on a HOC.
I’m not giving up because I’m excited about my project but I can honestly understand the author’s feelings. I sincerely don’t think it has to be this difficult. And I can’t imagine being new to programming walking up to the current frontend process.
Weird that the author says all languages are very similar. Strongly suggest trying something like Elm (although I do not recommend it for any large production use, small areas are fine.) to see how brilliant the experience in another paradigm can be.
I've used Elm at 2 places for large production use, and in a large personal project. It would be my preferred technology by far. I'll add that Elm is actually what converted me from a backend (fullstack at times) engineer to front end. Also realizing that thinking about how people interact with computers and solving those problems well is actually a fun challenge.
Me too! Loving Elm. And there are others that break from the pain that frontend otherwise is:
* Purescript
* Kotlin/JS + KVision
* Rust + Yew
* Haskell + Miso
* ReScript + ReReact or TEA
* F# + Elmish
Hell even TypeScript + TEA would be a great alternative: https://github.com/typescript-tea/core
A hot topic still is CSS that non of these solve, so an additional lib is needed there. TailwindCSS has been my go to lately, and I really start to get the hang of it (great docs also!!).
* Purescript
* Kotlin/JS + KVision
* Rust + Yew
* Haskell + Miso
* ReScript + ReReact or TEA
* F# + Elmish
Hell even TypeScript + TEA would be a great alternative: https://github.com/typescript-tea/core
A hot topic still is CSS that non of these solve, so an additional lib is needed there. TailwindCSS has been my go to lately, and I really start to get the hang of it (great docs also!!).
Not necessarily solved, and I assume you know about it, but for anyone reading this, elm-ui is definitely worth checking out for at least an exploration of an alternative to CSS.
For a talk about this: https://www.youtube.com/watch?v=Ie-gqwSHQr0
For a talk about this: https://www.youtube.com/watch?v=Ie-gqwSHQr0
I would personally recommend Elm for production use after 3 years of development with it.
I regularly engage in refactoring efforts that would be prohibitively time consuming in React, which I also have production experience with.
I regularly engage in refactoring efforts that would be prohibitively time consuming in React, which I also have production experience with.
Yeah, just use Elm.
I feel the friction. I'll toss another perspective your way though. I'm a software engineer that primarily works in infrastructure and systems engineering. I end up writing tools that users mostly use in their shell.
Sounds pretty uncomplicated right? Write a command, include some flags, produce some output. Not quite!
Some notable demands I've received over the years:
- Backwards compatibility between incompatible CLI's
- Roaming profiles and persistence
- Command/flag/value auto-completion
- Hierarchical consumption of defaults/profile/flags/environment variables
- CLI's generated from backends
There's lots of interesting frameworks and tools you can use to design all these and more, however, as users add demand I found myself having to integrate all of them quite curiously, then they all became bespoke projects. The only consistent way that I have to manage this level of uncertainty is through testing. I have very finely scoped and defined unit, integration, and E2E tests that all run various functionality and ensure my contracts so that while I'm writing a feature I don't need to be constantly worrying I have broken some behavior by rewiring all of these components again.
The only other tool I have against the chaos is inline documentation. I rarely use consolidated documentation sources anymore, because it always turns into another task that has to be done as an after-thought with this level of complexity.
I do also work on big infra products, and these run into many of the same problems the author described.
Sounds pretty uncomplicated right? Write a command, include some flags, produce some output. Not quite!
Some notable demands I've received over the years:
- Backwards compatibility between incompatible CLI's
- Roaming profiles and persistence
- Command/flag/value auto-completion
- Hierarchical consumption of defaults/profile/flags/environment variables
- CLI's generated from backends
There's lots of interesting frameworks and tools you can use to design all these and more, however, as users add demand I found myself having to integrate all of them quite curiously, then they all became bespoke projects. The only consistent way that I have to manage this level of uncertainty is through testing. I have very finely scoped and defined unit, integration, and E2E tests that all run various functionality and ensure my contracts so that while I'm writing a feature I don't need to be constantly worrying I have broken some behavior by rewiring all of these components again.
The only other tool I have against the chaos is inline documentation. I rarely use consolidated documentation sources anymore, because it always turns into another task that has to be done as an after-thought with this level of complexity.
I do also work on big infra products, and these run into many of the same problems the author described.
Well, I have enjoyed doing backend, but it isn't really what I'm good at. I guarantee that there are thousands of people that can do better servers than me. My stuff does tend to be solid and high-quality, though; just not as ruthlessly efficient as a dedicated backend engineer can do.
I am fairly good at writing SDKs. That seems to be where my strengths lie, in the backend arena.
But I really enjoy doing frontend. The difference for me, is that I am not a Web/site designer. I do applications, using compiled and linked native language (Swift, on Apple).
I'm big on usability, localization, and accessibility. I enjoy writing a powerful application that can be localized to an entirely new audience by simply sending a single text file to a translator. I also enjoy writing stuff that is usable. One of the things that I do, is fail to provide documentation to users of my applications, during development, so I can see how they understand, model, and use them. I sometimes make fairly big adjustments, because users fail to understand an affordance, or misinterpret a user interface element.
I also enjoy interfacing with devices (Bluetooth, TCP/IP, USB, etc.).
I am fairly good at writing SDKs. That seems to be where my strengths lie, in the backend arena.
But I really enjoy doing frontend. The difference for me, is that I am not a Web/site designer. I do applications, using compiled and linked native language (Swift, on Apple).
I'm big on usability, localization, and accessibility. I enjoy writing a powerful application that can be localized to an entirely new audience by simply sending a single text file to a translator. I also enjoy writing stuff that is usable. One of the things that I do, is fail to provide documentation to users of my applications, during development, so I can see how they understand, model, and use them. I sometimes make fairly big adjustments, because users fail to understand an affordance, or misinterpret a user interface element.
I also enjoy interfacing with devices (Bluetooth, TCP/IP, USB, etc.).
I also switched away from React to iOS/Swift full-time roughly 2 years ago, although I was doing it on the side and as a hobby for longer. Couldn't be happier honestly. It's not without it's own issues but I find it much more manageable.
So young and already jaded.
To me the problem with frontend, and why most people I know want to avoid it, is that compared to backend the specifications are never clear, change more often, require a lot more boilerplate and is in general more verbose.
If I look at code I've written, the backend/"useful" code is always fraction of length and complexity of the UI code, no matter the stack (be it gtk, swiftUI, jquery, pure JS or a reactive framework).
UI often requires a lot of custom code because there is always that one bit that the framework doesn't support. An example would be a table displaying some data with metadata. Adding more stuff on the backend is easy, just update your endpoint with one more field in the response. On the frontend it might make each line too large for screens, so now you have to figure out how to place it in a way that fits. Sometimes it may not be as simple as just extending the line a bit.
To me the problem with frontend, and why most people I know want to avoid it, is that compared to backend the specifications are never clear, change more often, require a lot more boilerplate and is in general more verbose.
If I look at code I've written, the backend/"useful" code is always fraction of length and complexity of the UI code, no matter the stack (be it gtk, swiftUI, jquery, pure JS or a reactive framework).
UI often requires a lot of custom code because there is always that one bit that the framework doesn't support. An example would be a table displaying some data with metadata. Adding more stuff on the backend is easy, just update your endpoint with one more field in the response. On the frontend it might make each line too large for screens, so now you have to figure out how to place it in a way that fits. Sometimes it may not be as simple as just extending the line a bit.
Although I can relate, I find the reasoning in the post a bit odd. For example:
> Starting a new project? Make sure to write your project idea down because by the time you are finished setting up the vast boilerplate you have probably forgotten it.
If it's a personal project (it doesn't sound like the author is talking about work-related projects), what's stopping the author with writing just good old HTML, CSS and JavaScript?
I said I could relate because a couple of years ago I was in a similar position, but a comment on Hacker News in a thread about JavaScript fatigue says that it doesn't have to be that way (apologies, it's been too long and I was a lurker back then and don't have it bookmarked). That was a liberating moment for me and I now just do whatever it's best on a case-by-case basis.
> Starting a new project? Make sure to write your project idea down because by the time you are finished setting up the vast boilerplate you have probably forgotten it.
If it's a personal project (it doesn't sound like the author is talking about work-related projects), what's stopping the author with writing just good old HTML, CSS and JavaScript?
I said I could relate because a couple of years ago I was in a similar position, but a comment on Hacker News in a thread about JavaScript fatigue says that it doesn't have to be that way (apologies, it's been too long and I was a lurker back then and don't have it bookmarked). That was a liberating moment for me and I now just do whatever it's best on a case-by-case basis.
It's even easier to go with good old JavaScript now than back in 2007 because of all the tooling. We have profilers right in the browsers now. How cool is that!
Another goodie is how modern browsers support modern JavaScript. Basically everything I needed transpiler few years ago just works: const, lambdas, classes, even imports. Supporting only modern browsers when you start sounds like a good idea and if you ever need old browsers, you can always transpile to ES5 later.
Also don't forget that while CSS is still lame, it got few goodies as well, like CSS variables.
The only thing that I personally miss is how to set up Chrome to be a proper IDE. I know that I can edit files from the disk, it has autocomplete, but this whole UI is kind of weird. May be I just need some tutorial.
Also don't forget that while CSS is still lame, it got few goodies as well, like CSS variables.
The only thing that I personally miss is how to set up Chrome to be a proper IDE. I know that I can edit files from the disk, it has autocomplete, but this whole UI is kind of weird. May be I just need some tutorial.
For me, it is the desire to write non-flakey automated tests and easily pop a debugger into them.
I hate front end work, but not for the reasons given here. I actually don’t think the boilerplate stuff is a big deal unless you’re starting new things all the time instead of maintaining an existing project.
The real reason I hate front end work is because you spend so much time programming meaningless stupid shit that is only complicated because you have to achieve a certain aesthetic or UX. Imagine spending a day getting some borders to render correctly for some custom widget. Borders!
With backend work though, things you write are usually much more important and you spend less time tweaking and tinkering to get something “just right”. And you don’t have to deal with designers.
The real reason I hate front end work is because you spend so much time programming meaningless stupid shit that is only complicated because you have to achieve a certain aesthetic or UX. Imagine spending a day getting some borders to render correctly for some custom widget. Borders!
With backend work though, things you write are usually much more important and you spend less time tweaking and tinkering to get something “just right”. And you don’t have to deal with designers.
Welcome to the club, my friend. I am pretty happy with my backend/DevOps position. I hope you'll find a new job more suitable.
> will be seeking an exclusively back-end role for my next adventure, starting April
gigglesnort
ooooh boy
> The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn.
BAHAHAHAAAHAHA
Enjoy pretending not to have memorized Grokking the System Design Interview front to back, ah man what do you mean instagram doesn't even look like that anymore and even Snapchat is a $100B company after getting ripped to shreds by competitors, it doesn't matter!
of course you'll only be periodically adding rest endpoints for poorly designed startups using whatever came after express, this is just for the interview!
gigglesnort
ooooh boy
> The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn.
BAHAHAHAAAHAHA
Enjoy pretending not to have memorized Grokking the System Design Interview front to back, ah man what do you mean instagram doesn't even look like that anymore and even Snapchat is a $100B company after getting ripped to shreds by competitors, it doesn't matter!
of course you'll only be periodically adding rest endpoints for poorly designed startups using whatever came after express, this is just for the interview!
I'm a fullstack developer and I started picking up more modern frontend frameworks 3 months ago. Has this person try to manage a large complex site with just HTML, CSS, and JavaScript/Jquery? It's a mess, a complicated mess. Sure, for small sites and small codebases, use basic tools. However, how many companies are building basic sites now? React, Typescript, SCSS, and all these other technologies came around not to make your life more difficult. It popped up because for specific use cases it makes your life a whole lot better. Also, backend is not any easier...
I share the opinion of the author of this article. However this resort at the end of this article might be an illusion, the backend also suffers from complexity, you have package managers there as well (Composer if you use PHP), complex frameworks like Symfony/Laravel, cumbersome ORMs and for deployments you need Docker, Kubernetes, specific cloud tools, Elastic Search. It's also very complex these days. Personally I no longer enjoy modern web development at all. There is also the hyve-mind, if you dissent you get mocked, ridiculed and you encounter all kinds of aggression. It's all very depressing. I still love to code, so I started creating my own programming language Citrine (for which I got death threats by the way) - so that project is kind of my escape where I can still do things the way I want it. To be honest I don't know what happened to web development. At a certain point in time, I had the impression the web community consisted mainly of bright, intelligent and most of all, open-minded people. Today, it looks all enterprisey and there is a lot of peer pressure, maybe even dogma to conform to the norm. So, sorry for the personal notes here, but I guess I can relate to the story of the author very much. I personally think it's time for me to close this chapter and look for another line of work, because coding in an enterprise situation is just not something I want to do with the rest of my life as well. I would like to thank the author for this article, it's good to know I am not the only one who feels this way.
Even though I'm not a front-end developer, I dealt with WordPress advanced custom development for a certain amount of time to realize web development - as we currently know it - is not worth it...like *at all*!
As an OCD person I cannot count the number of times I got panic attacks for realizing how many tests I needed to go through to test:
It's not worth it anymore.
It's SO FREAKING STRESSFUL!
I decided to stop dealing with web development as a whole and I'm playing with C and C++ now, like the good ol' days.
I can't do multiple things at once.
I live and breathe the UNIX philosophy: Do one thing and do it well.
[1] https://www.netsparker.com/blog/web-security/private-data-st...
As an OCD person I cannot count the number of times I got panic attacks for realizing how many tests I needed to go through to test:
* have I checked my PHP code, packages, and settings? Are they all good?
* is Composer and my various packages updated?
* what about npm and yarn packages? are they updated?
* wait...do I need worry about CSS as well now, to look for extra security measurements? WHY?! Oh yeah, CSS injection [1] /facepalm
It's not worth it anymore.
It's SO FREAKING STRESSFUL!
I decided to stop dealing with web development as a whole and I'm playing with C and C++ now, like the good ol' days.
I can't do multiple things at once.
I live and breathe the UNIX philosophy: Do one thing and do it well.
[1] https://www.netsparker.com/blog/web-security/private-data-st...
I started back the days of CASE and RAD developing Windows apps against a database then eventually am middle tier. You could build something useful, stable, and production ready in a couple of days or weeks depending on the complexity.
Sadly you will find the same thing on backend, and even on infra, so better to think in switching to do something else not computer related if you don't like it.
On the frontend, people are crazy with React, redux, css-in-js,etc,etc, on the backend, same thing with dozens of different languages all of which we're migrating away to Go, microservices, grpc, graphql apis, etc, and on infra with kubernetes, more Go, all the amazon ecosystem, ingestorwhatevers, etc.
As I've said many times, everyone wants to have fun.
You can still do things The Old Ways... it still works... but yeah, pretty difficult to do it that way at work, so that is something mostly for your side projects, etc.
Also, to some extent, some of this is necessary. For example, I like a lot the "modern old ways" of doing frontend, such as the way it can be done with Hotwire, intercooler, htmx, Unpoly, etc... but I agree that once you're part of a larger team, React, Redux, etc... provides a more streamlined way to build your application (once the gazillion decision of the tooling is made). Doing it the "old way" doesn't scale with people, as everyone will have its own supercool shiny idea of how to do things.
Also, the "webpck, babel, etc are too complicated" are not a valid argument anymore in my opinion. Those are pretty low level tools, compilers, etc. Just look for a high level tool... in React you have Next, in Vue you have Nuxt, if doing plain js you have Parcel....
And, again, once the honeymoon is over you'll feel the same about backend and infra at the very least (I've been there)...
On the frontend, people are crazy with React, redux, css-in-js,etc,etc, on the backend, same thing with dozens of different languages all of which we're migrating away to Go, microservices, grpc, graphql apis, etc, and on infra with kubernetes, more Go, all the amazon ecosystem, ingestorwhatevers, etc.
As I've said many times, everyone wants to have fun.
You can still do things The Old Ways... it still works... but yeah, pretty difficult to do it that way at work, so that is something mostly for your side projects, etc.
Also, to some extent, some of this is necessary. For example, I like a lot the "modern old ways" of doing frontend, such as the way it can be done with Hotwire, intercooler, htmx, Unpoly, etc... but I agree that once you're part of a larger team, React, Redux, etc... provides a more streamlined way to build your application (once the gazillion decision of the tooling is made). Doing it the "old way" doesn't scale with people, as everyone will have its own supercool shiny idea of how to do things.
Also, the "webpck, babel, etc are too complicated" are not a valid argument anymore in my opinion. Those are pretty low level tools, compilers, etc. Just look for a high level tool... in React you have Next, in Vue you have Nuxt, if doing plain js you have Parcel....
And, again, once the honeymoon is over you'll feel the same about backend and infra at the very least (I've been there)...
While I don't (yet) hate svelte/vue/react/etc and their tooling, I recently found out about htmx[1] and I must say that it's definitely changed the way I'll build applications going forward.
It's the epitome of applying the KISS principle for building interactive web applications, not in small part because it allows the developer to keep the UI code in a single place, backend templates, instead of spreading it around[2]. In my particular experience, I've found that htmx pairs really well with my backend microframework of choice, flask.
In fact, using htmx means that there isn't a division between backend and frontend as much as there's a backend with some extra attributes in some of the tags in the templates, and a few extra rules deciding which template to serve at specific endpoints.
[1]: https://htmx.org/
[2]: Having spent most of my professional life deep within js/ts frameworks, I thought that progressive enhancement was either a pipe dream or required duplicating at least a significant portion of the UI code on both ends. Htmx showed to me that such ain't necessarily the case; `hx-boost` in particular is a godsend.
It's the epitome of applying the KISS principle for building interactive web applications, not in small part because it allows the developer to keep the UI code in a single place, backend templates, instead of spreading it around[2]. In my particular experience, I've found that htmx pairs really well with my backend microframework of choice, flask.
In fact, using htmx means that there isn't a division between backend and frontend as much as there's a backend with some extra attributes in some of the tags in the templates, and a few extra rules deciding which template to serve at specific endpoints.
[1]: https://htmx.org/
[2]: Having spent most of my professional life deep within js/ts frameworks, I thought that progressive enhancement was either a pipe dream or required duplicating at least a significant portion of the UI code on both ends. Htmx showed to me that such ain't necessarily the case; `hx-boost` in particular is a godsend.
The problem lies in what you actually want to create. For your simple html,css websites with gifs please don't use React with Typescript!
But if you are writing an application, something which is supposed to replace desktop software, and allow for storing data in a database, retrieve it quickly, manage some sort of complicated systems then I'm sorry Html + css is not good enough. Use the tools you need, don't pick react for landing pages.
Edit: typo
But if you are writing an application, something which is supposed to replace desktop software, and allow for storing data in a database, retrieve it quickly, manage some sort of complicated systems then I'm sorry Html + css is not good enough. Use the tools you need, don't pick react for landing pages.
Edit: typo
I have the same opinion except it's not that programming is more complicated than before, but that enterprise programming is more complicated than week-end programming. Side-projects are fun because they're free of so much of the bullshit. How much of this bullshit is actually a necessity to build something serious and maintainable is not entirely clear, but it's not 0 nor 100%.
I totally identify with all this, having originally been a flash developer back around that time (even easier than html).
BUT, I have recently discovered the joy of react. I hated it at first of course (what's with this stupid jsx language that my text editor doesn't even understand how to error check?)
But now I've finally got my shit together with Visual Studio and the right plugins, it's really kinda neat.
BUT, I have recently discovered the joy of react. I hated it at first of course (what's with this stupid jsx language that my text editor doesn't even understand how to error check?)
But now I've finally got my shit together with Visual Studio and the right plugins, it's really kinda neat.
I feel the pain here. Most the people I know who have been in the game for a good while every so-often remark: what was so bad about js, html, and css? ;)
Of course, the reality is far more nuanced than that.
All this said, I would strongly recommend anyone who's running into this front-end burnout phase to give Svelte a serious look. And no, I'm not on the take here, it's just my personal experience.
Now, Svelte won't solve all of the OP's woes, cause yeah, you still need some tooling, and to get up to speed with some new hotness. But Svelte is about the closest 'framework' I have messed with that feels like simple js, html, and css - without loosing all of the hard fought advances in front-end. All of the new-skool tech without the feeling of over-engineered BS.
For context, our ui team (just 3 people) have built a component library for our entire org, which includes many teams and deliver ui modules seamlessly across vast legacy applications. I can't imagine pulling this off with any of the other stuff I have used.
Of course, the reality is far more nuanced than that.
All this said, I would strongly recommend anyone who's running into this front-end burnout phase to give Svelte a serious look. And no, I'm not on the take here, it's just my personal experience.
Now, Svelte won't solve all of the OP's woes, cause yeah, you still need some tooling, and to get up to speed with some new hotness. But Svelte is about the closest 'framework' I have messed with that feels like simple js, html, and css - without loosing all of the hard fought advances in front-end. All of the new-skool tech without the feeling of over-engineered BS.
For context, our ui team (just 3 people) have built a component library for our entire org, which includes many teams and deliver ui modules seamlessly across vast legacy applications. I can't imagine pulling this off with any of the other stuff I have used.
I've been doing front-end work recently and absolutely hate it. It constantly feels like I'm developing on quicksand where I can't trust the layers below me.
But I think web development has actually improved a lot. Frankly 10 years ago it was even worse.
Had we chucked Javascript in the bin a decade or two ago and built something new from scratch we'd probably be better off for it.
But I think web development has actually improved a lot. Frankly 10 years ago it was even worse.
Had we chucked Javascript in the bin a decade or two ago and built something new from scratch we'd probably be better off for it.
I think our worst enemy now is backward compatibility. I wish we could use other technologies/langs to target FE development without transpoling to js. I hope that webassembly will deliver.
Having been through all that myself for years, and now happily programming for grad school on a thing that IS JUST A THING, I totally sympathize. (One program, two languages, that's it. Ahhhhhh, it's fun again!) WebAssembly may be somewhat of an escape hatch. I was interested to see in a diligence I was conducting how well Microsoft Razor was working for a firm we examined, so that all their frontend is C#, using the same backend code they already developed, and one build pipeline. It is making them happy and productive, can't fault them on that. I've done the whole thing on the front end, dating back to the old days of Dojo and Ajax through pixels, though NG, React, Reframe, etc, and even now, it's such a gong show. Just try mentoring a brand new dev and you realize the stack of elephants for tooling is such a stupid, awful situation.
Spoiler alert: nobody does. We're only doing it for the money.
I feel the same fatigue. But on the other hand: looking at the boiler plate to get a web backend running I honestly don't see that much of a difference. Granted my experience is mostly limited to the Java ecosystem (specifically Spring) but just by looking at alternatives like Laravel (PHP) or Elixir (Erlang) or Django (Python) I don't see much difference when it comes to boilerplate.
Developers seem to have this romantic notion that everything used to be so simple but it seems like history is just repeating itself. I'm sure programmers of the 70s and 80s said the same about desktop development in the late 90s.
That being said: It's baffling to me that browser vendors can't agree on advancing the technology on their own. Why do we have to wait for the ECMA and CSS standard to evolve and instead use shims to get where we clearly want to go?
Developers seem to have this romantic notion that everything used to be so simple but it seems like history is just repeating itself. I'm sure programmers of the 70s and 80s said the same about desktop development in the late 90s.
That being said: It's baffling to me that browser vendors can't agree on advancing the technology on their own. Why do we have to wait for the ECMA and CSS standard to evolve and instead use shims to get where we clearly want to go?
The first sin of computing was platform diversity: the greatest leap forward in computing was platform diversity.
Ever since, we've been trying to grapple with that problem and opportunity.
If browsers didn't evolve incompatibly during the early days of web scripting, much of this never would have come into being. But then we would have had to wait another couple decades for AJAX, etc.
Unfortunately, I do get a sense that the younger generation looks at the polyfill complexity produced by the 90s and assumes that's the baseline by which things should be done.
... and, not to put too fine a point on it (and with deference to all the folks working in front end who know more about computer science than I ever will!), front end web development has a huge amount of developers who lack formal, in depth and breadth computer science education. Those who never learned the past, doomed to repeat it, etc.
Ever since, we've been trying to grapple with that problem and opportunity.
If browsers didn't evolve incompatibly during the early days of web scripting, much of this never would have come into being. But then we would have had to wait another couple decades for AJAX, etc.
Unfortunately, I do get a sense that the younger generation looks at the polyfill complexity produced by the 90s and assumes that's the baseline by which things should be done.
... and, not to put too fine a point on it (and with deference to all the folks working in front end who know more about computer science than I ever will!), front end web development has a huge amount of developers who lack formal, in depth and breadth computer science education. Those who never learned the past, doomed to repeat it, etc.
Unless you were doing things like Corba or DCOM, desktop development in the 90s was a breeze compared to modern development.
Tech stacks can be overwhelming, and in saying that this is what I do in 2021 and find it enjoyable: Snowpack + Typescript + ES6. I use regular CSS, just a single file.
If I do something unusual with importing files or some other kind of build process thing, chances are its only a few lines to write a plugin or perhaps a few shell commands from a npm script command (or a simple script written in node) to achieve the end goal.
I also use redom instead of a large framework. But also, the cool thing about TS and other front end stuff is that it's kind of fun to just find your own way. Of course, people like common practices, frameworks, etc. But also, exploring alternatives can reveal a lot about unseen potential.
I hope you find something you enjoy doing, life isn't worth wasting it on stuff you don't want to do.
edit: changed proverbial you to I, as I'm only referring to myself.
If I do something unusual with importing files or some other kind of build process thing, chances are its only a few lines to write a plugin or perhaps a few shell commands from a npm script command (or a simple script written in node) to achieve the end goal.
I also use redom instead of a large framework. But also, the cool thing about TS and other front end stuff is that it's kind of fun to just find your own way. Of course, people like common practices, frameworks, etc. But also, exploring alternatives can reveal a lot about unseen potential.
I hope you find something you enjoy doing, life isn't worth wasting it on stuff you don't want to do.
edit: changed proverbial you to I, as I'm only referring to myself.
Try Clojure/ClojureScript, you might like it. Much less ecosystem churn, good tooling, an excellent language.
His website says he works with Clojurescript at his employer. I thought it was strange when I saw that.
I guess given this latest post says "Nowadays I make a living mainly with JavaScript and TypeScript" it means that ClojureScript isn't used there anymore.
I still write it every now and again under a blue moon, but only when working on legacy stuff or replacing components with their TypeScript counterparts.
Replacing ClojureScript with TypeScript? I wonder what the rationale for that is.
We were told that it's hard to find Clojure engineers, but everyone including your grandmother knows JS/TS, but I think what they really meant by that is that they can't afford Clojure engineers.
Sounds like a quantity is better than quality argument. I bet it came from a non-technical person (or someone who hasn't written code in years).
I'm trying to learn some frontend as a backend developer(primarily .NET Core but I enjoy others like Elixir/Phoenix in my own time as well) to help other developer in our team, but no matter how many times I tried, I just can't get it. The barrier of entry is so insanely high right now, I just cannot force myself to get into it. It's not only million different tools, it also to me seems like every React codebase has a huge learning curve on its own because everyone does it differently. Not only that, but Javascript(or mostly Typescript now) is to me so unreadable when combined with parts of html sprinkled everywhere, that you really need to focus a lot just to understand what's in front of you, what it does, but I guess that part is just a matter of getting used to the language.
> It's not only million different tools, it also to me seems like every React codebase has a huge learning curve on its own because everyone does it differently.
I've been writing React code on and off since 2014 and I can relate to the pain: component creation and API changes in React (especially hooks) have meant quite a different way to do things, and in my experience this resulted in making things harder to understand across the board.
Life was simpler when `React.createClass()` was the only way to create components :)
I've been writing React code on and off since 2014 and I can relate to the pain: component creation and API changes in React (especially hooks) have meant quite a different way to do things, and in my experience this resulted in making things harder to understand across the board.
Life was simpler when `React.createClass()` was the only way to create components :)
Hooks and functional components are indeed a different way to look at it, but I sure am happy that they went that way. I doubt that we will see a paradigm shift like that in React again, at least in this decade. And they've been very good at maintaining backwards compatibility.
I don’t know if this is even an option for you but you might want to take a look at Angular especially if you already have an OO language background on the backend.
Basically everything is standardised, you are mostly just writing classes the way you would for a desktop application, the majority of what makes the web frustrating to work with is abstracted away in a series of sensible patterns and overall the tooling is really great.
Basically everything is standardised, you are mostly just writing classes the way you would for a desktop application, the majority of what makes the web frustrating to work with is abstracted away in a series of sensible patterns and overall the tooling is really great.
I did work with Angular a bit. It is admittedly better in my opinion in that context - it gives you kind of guard rails. But then an actual Angular developer came into the project and threw everything around to the point I wasn't recognizing the project anymore. I have to admit he was insanely productive with it as he actually had years of experience just in Angular.
I have to admit, I mostly make 'backend uis' recently and for me Blazor(server for now) fills that niche insanely well, I've never been so productive when doing frontend work, it has its pitfalls as well, our code is probably not the cleanest, but the fact that I can include a project with all my models, services and just use that, makes it so satisfying to work with... I only ever had one similar feeling so far, when trying Phoenix.
> take a look at Angular especially if you already have an OO language background on the backend.
Observables, pipes, operators, litany of custom attributes in the markup, the TS source code looks like Java. I'm literally starring now the 4th day at bunch of TS and HTML files only to duplicate a simple UI feature. Once done, writing tests for this mess. All this to create a web app which loads 5-10 seconds with 2 levels of loading spinners. I feel sorry for anyone whose job will be using the application. I actively procrastinate to delay touching it.
Observables, pipes, operators, litany of custom attributes in the markup, the TS source code looks like Java. I'm literally starring now the 4th day at bunch of TS and HTML files only to duplicate a simple UI feature. Once done, writing tests for this mess. All this to create a web app which loads 5-10 seconds with 2 levels of loading spinners. I feel sorry for anyone whose job will be using the application. I actively procrastinate to delay touching it.
I mentioned this more in my other commend on this thread but I should mention that I think the bar for when people reach for an SPA framework like Angular is probably a lot lower than is reasonable. Angular in particular is designed for enterprise style applications and that is about it. Everything you need for that doesn’t come for free in terms of complexity obviously.
The other thing I mentioned elsewhere at the total other end of the spectrum was Hotwire. That is genuinely as close to 2006 web development as I can think of in terms of simplicity and is probably enough for the majority of applications up to and including an email client in the browser which is what they originally built it for.
The other thing I mentioned elsewhere at the total other end of the spectrum was Hotwire. That is genuinely as close to 2006 web development as I can think of in terms of simplicity and is probably enough for the majority of applications up to and including an email client in the browser which is what they originally built it for.
The most complicated web development stuff is the easy technology taken to extreme levels of pseudo-sophistication.
The technology that's unpopular because it's too complicated to learn is actually easier to build real projects with, and maintain long term.
The reason is because the easy stuff its too simple to have an architectural foundation or engineering vision. Easy to learn, hard to use. Sort of the learning curve version of a stitch in time saves nine.
It's exacerbated in frontend because it attracts so many beginners. When the loudest voice is the junior developer, popular tech != good tech. That's why frontend is so chaotic and confusing.
This is all sort of obvious, but nobody want's to hear it. When I've tried to state it in online forums, I'm either a troll or a gatekeeper. shrug
The technology that's unpopular because it's too complicated to learn is actually easier to build real projects with, and maintain long term.
The reason is because the easy stuff its too simple to have an architectural foundation or engineering vision. Easy to learn, hard to use. Sort of the learning curve version of a stitch in time saves nine.
It's exacerbated in frontend because it attracts so many beginners. When the loudest voice is the junior developer, popular tech != good tech. That's why frontend is so chaotic and confusing.
This is all sort of obvious, but nobody want's to hear it. When I've tried to state it in online forums, I'm either a troll or a gatekeeper. shrug
> Oh and while you're at it, install also Yarn
Both NPM and Yarn come bundled with recent Node versions, so hopefully you only need to install one thing (Node).
That being said, having multiple package managers must be confusing to people who haven't spent entirely too much time configuring front-end projects.
Both NPM and Yarn come bundled with recent Node versions, so hopefully you only need to install one thing (Node).
That being said, having multiple package managers must be confusing to people who haven't spent entirely too much time configuring front-end projects.
I stopped doing frontend work when I realized that everybody is working against good UX. Marketing departments, Product Owners, CEOs, all want you to implement dark patterns and small traps for short sighted metrics.
On top, just everybody and his mother has an opinion on how the UI should look and work.
On top, just everybody and his mother has an opinion on how the UI should look and work.
[deleted]
The thing I don't like the most about frontend is setting up a stack. Often I wish things were more explicit and less magic.
It feels like a lot of a projects' meta state is managed poorly in the filesystem.
One concrete thing I can think of, when Typescript transpiles to dist/*, it is not cleaned up from last time it transpiled. So if you directory structure changes this can lead to strange issues like running an old version a .js file without realizing it.
A very high level/magic library I use provides no way to configure its initial setup through javascript. To do automated setup I have to write a config file to disk to work around it. (The library is otherwise great, and I should report this now that I think about it!)
Other than that I kinda like the messiness of frontend.
It feels like a lot of a projects' meta state is managed poorly in the filesystem.
One concrete thing I can think of, when Typescript transpiles to dist/*, it is not cleaned up from last time it transpiled. So if you directory structure changes this can lead to strange issues like running an old version a .js file without realizing it.
A very high level/magic library I use provides no way to configure its initial setup through javascript. To do automated setup I have to write a config file to disk to work around it. (The library is otherwise great, and I should report this now that I think about it!)
Other than that I kinda like the messiness of frontend.
Well, since web apps are competing with native desktop apps, they're also starting to compete on the associated complexity.
Like in the 90ies when everyone had their own desktop GUI library (remember the distinctive Borland look?) and fluffernutter libraries and then it boiled down to a few major ones, the same thing is happening in the web frontend.
And since there's no good distinction between "simple web stuff like actual pages" and "full-blown web apps", the tooling is the same, and the complexity bleeds into everything.
…yep, no having your cake and eating it.
Funnily enough, the few things that might survive the test of time and be there in 2030 or 2040 might already exist today — it might just be impossible to identify them.
Like in the 90ies when everyone had their own desktop GUI library (remember the distinctive Borland look?) and fluffernutter libraries and then it boiled down to a few major ones, the same thing is happening in the web frontend.
And since there's no good distinction between "simple web stuff like actual pages" and "full-blown web apps", the tooling is the same, and the complexity bleeds into everything.
…yep, no having your cake and eating it.
Funnily enough, the few things that might survive the test of time and be there in 2030 or 2040 might already exist today — it might just be impossible to identify them.
I think modern clean desktop toolkits (e.g. JavaFX, Qt) are actually a lot simpler than web development, but only if you take deployment out of the equation. If you want to iterate your app every single day, the web is good at that.
Yeah, desktop development is really rooted in a different time where you'd iterate maybe once in a year... there is some CI/CD tooling these days, but dealing with the end system & user is still a hard problem.
Wow, I’ve taken the exact same path. Started in 2006, learned everything I could, and lost joy gradually over the past few years.
I’ve left my last front end job behind a couple years ago and launched my startup. Now front-end is just a tiny part of what I do.
Good luck OP!
Good luck OP!
Honestly, this is applicable to many computational fields. I’ve done mobile, backend, and a bit of frontend. Now I do bioinformatics and guess what? It’s the same: the field is moving fast, dozens of new data processing tools pop up every month. A zoo of different algorithms, statistical models, machine learning techniques. And nobody cares about code style and automated testing. 9 out of 10 times you won’t be able to run the code the manuscript author has written because there’s either no code shared or it’s just not runnable.
My point is you’ve got to defeat the tools fatigue and focus on something else. It’s a bit easier in life sciences compared to your typical b2b or b2c app.
My point is you’ve got to defeat the tools fatigue and focus on something else. It’s a bit easier in life sciences compared to your typical b2b or b2c app.
I’ve been feeling the same way about modern HTML/JS/CSS. The tooling has become too cumbersome and languages like TypeScript, SCSS and even Elm illustrate how the community needs a new frontend toolset. On top of that tools like React Native and Electron add even more complexity to the problem. I’ve recently started looking at Dart/Flutter - https://flutter.dev/ - which looks like it might have some potential to fix a lot of these problems. Has anyone here used Flutter and feel like it addresses these problems well?
The problem the author has is that he’s focusing on the technology and not on the user impact.
The point of working as a frontend developer is that you get to develop the interface between the system and the user, and you get to directly affect how good your users feel about their interactions with your company or organisation. If you start talking about how bad the flavour-of-the-month technology is then you’re missing the point. The tech you should be using is the one that enables the experience you’re building, and that tech can be anything between plain HTML and CSS, all the way up to WASM and WebGL.
The point of working as a frontend developer is that you get to develop the interface between the system and the user, and you get to directly affect how good your users feel about their interactions with your company or organisation. If you start talking about how bad the flavour-of-the-month technology is then you’re missing the point. The tech you should be using is the one that enables the experience you’re building, and that tech can be anything between plain HTML and CSS, all the way up to WASM and WebGL.
Relax a bit and just use the tools you like. If it doesn’t make you more productive then don’t bring it into your stack. Love building things with plain old JS and CSS like it’s 2007? Go nuts, it all still works.
This guy is in for a rude awakening when he finds out backend is no different.
I agree, but anyway as mentioned, it's about tooling. When I compare creating JS SPA vs. for example .NET MVC website, with JS you will get awesome SPA (oh wait, do you really need that?) - easier way to create dynamic stuff but with cost of bigger complexity which probably comes in ways as project management, DevOps, testing.
I was developing some SPAs in Angular, React and of course there are some great things but I do not see the pure reason because of additional complexity to develop everything in this "modern" way.
I was developing some SPAs in Angular, React and of course there are some great things but I do not see the pure reason because of additional complexity to develop everything in this "modern" way.
A simple search returned a Medium article wherein the author talks about using React without all of the tooling: https://medium.com/@chrislewisdev/react-without-npm-babel-or...
Overall, anyone who works for a large company will have to deal with a large toolset. That's how you get 10+ engineers working together without stepping on each others toes.
Overall, anyone who works for a large company will have to deal with a large toolset. That's how you get 10+ engineers working together without stepping on each others toes.
I am now retired after 40+ years mostly front end coding and the only examples of my work still running are some plain old javascript game sites from 2005. I switched frameworks/languages/toolsets about a dozen times over the years and finally reached the point where I was too old to learn the new stuff (React and its evolving ecosystem). Some tools have a longer than average shelf life - things like Unix utils, jQuery, git, node - what are your favorites?
Why did you feel that you were too old to learn the newer frameworks, if you don’t mind me asking?
For context, I’m a young(ish) developer and I often wonder at which age will my brain plasticity will stop being able to learn and keep up in this career.
I’m also curious if rather than brain plasticity being a problem in the future, the more likely issue will be losing enthusiasm to constantly learn the latest shiny framework.
For context, I’m a young(ish) developer and I often wonder at which age will my brain plasticity will stop being able to learn and keep up in this career.
I’m also curious if rather than brain plasticity being a problem in the future, the more likely issue will be losing enthusiasm to constantly learn the latest shiny framework.
Not who you asked, but I'm 31 right now. Started doing frontend at 17. When I turned 30 I made a conscious decision to not use any more free time to keep up with the ever evolving landscape.
I'm not sure if it's my brain losing plasticity or if I'm just realizing how much keeping up with all of the latest technologies doesn't actually make me better at my job. My job being to leverage technology to satisfy business requirements.
That said, I'm definitely less of a team player because my answer to questions now is, "I've got no idea" compared to "whoa, that's really lucky you asked because I just read this article yesterday, let's try that out"
It seems like I'm in the minority at work though. I posted this article like, "DAE?" and the answer was nah.
I'm not sure if it's my brain losing plasticity or if I'm just realizing how much keeping up with all of the latest technologies doesn't actually make me better at my job. My job being to leverage technology to satisfy business requirements.
That said, I'm definitely less of a team player because my answer to questions now is, "I've got no idea" compared to "whoa, that's really lucky you asked because I just read this article yesterday, let's try that out"
It seems like I'm in the minority at work though. I posted this article like, "DAE?" and the answer was nah.
That makes a lot of sense, thanks for sharing your experiences. This job really does demand a lot from your free time. I can see that not being a pattern I’d like to continue indefinitely either.
Good luck with your career! Remember that everything can be always be a tomorrow problem if you communicate it properly :)
Through my couple of decades as a programmer, I've gone through various specializations. Spent a good 10 years going very deep in web frontend.
I moved on years ago because, like the author, it was not fun or interesting anymore. I don't feel as strongly about it as the author seems to, though. It's all part of the journey.
Probably at some point, I will move on to a new technical domain than the one that's consuming my life right now, and that's fine.
I moved on years ago because, like the author, it was not fun or interesting anymore. I don't feel as strongly about it as the author seems to, though. It's all part of the journey.
Probably at some point, I will move on to a new technical domain than the one that's consuming my life right now, and that's fine.
I'm a few years older than the author, but otherwise have a largely similar history. But I love front-end! Yes, there's a lot of tooling, but I think the difference is that I see and appreciate everything that that tooling's brought me. It took many years for me to learn what I know now, but given what I know now, there's so much I can do now that I couldn't do before, or would've taken me a lot longer.
Many the author’s points are exactly the reasons I like and am bullish on SvelteJS. I started doing web dev in 1995. PHP was game changing. I feel the same about Svelte. For me, there are way too many layers in modern front end. I want to be as close to the foundation as possible - vanilla js, css, html. That is where the joy is. Svelte is the new old thing with a healthy sprinkling of awe and wonder.
Try Rails and Stimulus before you give up. Next to no JS with snappy front-end rendering. I believe Laravel and Django have adopted it too.
> The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn.
The lie we all tell ourselves! yes it is true one can pick up a language fairly quickly but knowing how to use the language properly and learning the language eco-system (frameworks, plugins, etc) takes time. Well at least once you have kids.
The lie we all tell ourselves! yes it is true one can pick up a language fairly quickly but knowing how to use the language properly and learning the language eco-system (frameworks, plugins, etc) takes time. Well at least once you have kids.
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/
Do frontend devs have on-call? Backend devs do.
Frontend devs also have less algorithmic FAANG (and others) interviews[0]
[0] https://mobile.twitter.com/dan_abramov/status/10786586563449...
Frontend devs also have less algorithmic FAANG (and others) interviews[0]
[0] https://mobile.twitter.com/dan_abramov/status/10786586563449...
I'm the other way around. The backend is both getting more complicated and getting replaced with standardized solutions. It seems its easier now for front end developer to write a whole solution with a standard back end like firebase than it is for a dev to write both back and front.
Many/most? people don't like UI development, in particular UI state management. Including smart developers. "Front end complexity" complaints are frequently that, but misattributed to the code/tools/etc. I miss the simplicity of the static web too.
Okay, man, u are welcome in c++ world!
Reminds me of this satire (the original also linked in it):
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
I stopped doing FE development a few years ago because of the unnecessary complexity of everything. I've gone back to my roots and am now actively avoiding anything to do with the internet / online world. Bar HN & Mastodon.
"The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn."
Time to give ClojureScript a shot? Great time to get acquainted with Fulcro or Re-Frame.
Both have new docs and videos out.
Time to give ClojureScript a shot? Great time to get acquainted with Fulcro or Re-Frame.
Both have new docs and videos out.
I agree. The fact we've invented insane frameworks like Gatsby to create "static websites" is just totally mindboggling to me. We already have "static site builder" technology. It's called HTML and CSS.
It's all about trade offs. No one is required to use all the latest tooling and frameworks, and writing things the 'good old way' still works, it'll just come with trade offs. Pick your poison.
Yea, also have you used Angular? Makes you want to quit coding in general haha.
Create react app means no fucking around with build systems.
And there’s zero reason to use SCSS.
And there’s zero reason to use SCSS.
The reasons are getting lesser, but it's still a good way to automate a few things. I'm loving the SCSS + CSS Modules combo.
Flutter web simplifies web app development in this regard. It's not fully mature yet but I recently wrote a web app using Flutter web that had 250k users in a week, and it works beautifully.
TypeScript, ESlint, SCSS, React, etc are training wheels. front-end development is harder without them, but it's also much faster if you skip them once you learn.
Try out .NET 5 with Blazor. You will be able to use 1 language (C#) on server and client side and a single package manager (nuget). Install visual studio and your good to go
I predict this will sort itself out in a week or so.
Thanks. I no longer have a doubt if my next job will be "full-stack developer" or "Java Backend developer" :))
Partially why I went into finance instead.
Experience translates into seniority easier and you don’t need to sprint non stop just to stand still
Experience translates into seniority easier and you don’t need to sprint non stop just to stand still
so he doesn't like front-end because it became like back-end and is now going to try if he likes back-end more ...
everyone is ranting about complexity, but these tools are built for a reason. We learn to use the tools to improve the efficiency of the job at hand. Not all tools are useful, but lets make better ones!
Also, All tools are not for everyone, so developers should be comfortable not working with specific tools.
Also, All tools are not for everyone, so developers should be comfortable not working with specific tools.
I think the author is kind of mixing the coding for himself/fun and coding for someone else/money.
same good ol'story :)
in reality we are all "always newbies" and we will be. Thats the modus operandi of always innovating/disrupting world. No matter what you are doing. You either stuck on your favourite patterns, learn new or die.
Ask MDs, scientists, mechanics, uber drivers, whoever ...
in reality we are all "always newbies" and we will be. Thats the modus operandi of always innovating/disrupting world. No matter what you are doing. You either stuck on your favourite patterns, learn new or die.
Ask MDs, scientists, mechanics, uber drivers, whoever ...
SRR en jQuery still work today, and you can still create nice interactive apps with them
At least we don't have to worry about Internet Explorer compatibility anymore.
> Don't have NPM? Better install that, too, because nobody installs libraries without a package manager anymore. Oh and while you're at it, install also Yarn, because why not make use of two package managers at the same time.
Phew... Using a package manager ? oh no... not that
lol wtf
Phew... Using a package manager ? oh no... not that
lol wtf
front-end is not bad for complicated, it's bad because people don't know what they need and invent / use unnecessary and bad tools
What's frustrating to me is that even though a lot of these frameworks and tools keep advertising themselves as making you more productive and letting you write less code in the pursuit of better client experiences -- ie, creating an "SPA", a single page application -- they keep adding more tools your way and more required boilerplate for you to write. You can argue that it's inevitable as they "mature", but then someone comes along a year later with a fix to those problems and you're forced to relearn everything to keep up. This cycle then starts over anew for the next 2-3 years as more tools and required boilerplate are added and someone gets frustrated enough to provide a new framework and tooling.
I've gone through this, in turn, as I've developed applications from plain old JS, to jQuery, to Backbone.JS/Marionette, to AngularJS, to Angular, and most recently to React, along with the similar change in tooling through Grunt, Gulp, and Webpack. Each time as the amount of boilerplate I'm forced to write begins to frustrate me, a new framework conveniently rolls around and convinces me to switch. I haven't looked at Vue.js yet, but a co-worker on a different team showed me a React/Redux project and I ran away screaming -- figuratively, not literally! -- from the boilerplate involved (if you're wondering, so far I've been pairing React with MobX but the applications haven't been particularly big). The dev experience has been better each step, but it's not been an easy ride and it's obvious that these frameworks don't represent the end of the chain.
All this time I thought this was just the required tax for providing a nice front-end experience, but recently I've been diving heavily into Blazor Server-Side and Phoenix LiveView on some personal toy projects to see what the server-side landscape is like, and it's a breath of fresh air. It's surprisingly quick and easy to write code that provides an SPA experience where changes on one connected client immediately propagate to other connected clients, and with so little code to boot. They have their pros and cons, but the dev/productivity experience has felt so much better. Because C# is such a great language, Blazor is super easy to jump into and immediately understand what's going on, and since it's part of ASP.NET you're not going to lack in good libraries/documentation/examples/support. However, it doesn't really have a good reload-on-changes functionality yet even while running under dotnet watch, as you'll have to manually reload your browser tab after changes. Phoenix LiveView on the other hand has a great reload-on-changes functionality for fast iteration, but its drawback is that it has a much steeper learning curve and initial hurdle. Fortunately it's offset by the fantastic documentation it provides, but it is something to keep in mind as it makes on-boarding people not used to Elixir/Phoenix a bit difficult.
Honestly, if the OP article resonates with you, I recommend giving one of those two server-side frameworks a spin. It's nice to temporarily escape from the craziness of the modern JS landscape, and to not have to write your models twice.
I've gone through this, in turn, as I've developed applications from plain old JS, to jQuery, to Backbone.JS/Marionette, to AngularJS, to Angular, and most recently to React, along with the similar change in tooling through Grunt, Gulp, and Webpack. Each time as the amount of boilerplate I'm forced to write begins to frustrate me, a new framework conveniently rolls around and convinces me to switch. I haven't looked at Vue.js yet, but a co-worker on a different team showed me a React/Redux project and I ran away screaming -- figuratively, not literally! -- from the boilerplate involved (if you're wondering, so far I've been pairing React with MobX but the applications haven't been particularly big). The dev experience has been better each step, but it's not been an easy ride and it's obvious that these frameworks don't represent the end of the chain.
All this time I thought this was just the required tax for providing a nice front-end experience, but recently I've been diving heavily into Blazor Server-Side and Phoenix LiveView on some personal toy projects to see what the server-side landscape is like, and it's a breath of fresh air. It's surprisingly quick and easy to write code that provides an SPA experience where changes on one connected client immediately propagate to other connected clients, and with so little code to boot. They have their pros and cons, but the dev/productivity experience has felt so much better. Because C# is such a great language, Blazor is super easy to jump into and immediately understand what's going on, and since it's part of ASP.NET you're not going to lack in good libraries/documentation/examples/support. However, it doesn't really have a good reload-on-changes functionality yet even while running under dotnet watch, as you'll have to manually reload your browser tab after changes. Phoenix LiveView on the other hand has a great reload-on-changes functionality for fast iteration, but its drawback is that it has a much steeper learning curve and initial hurdle. Fortunately it's offset by the fantastic documentation it provides, but it is something to keep in mind as it makes on-boarding people not used to Elixir/Phoenix a bit difficult.
Honestly, if the OP article resonates with you, I recommend giving one of those two server-side frameworks a spin. It's nice to temporarily escape from the craziness of the modern JS landscape, and to not have to write your models twice.
this is the most hilarious blog piece on HN i've ever seen
Sounds like he’s burned out of software engineering. Moving to back end is not going to help, back end has similar issues. Micro services, reactive frameworks, package managers, etc.
It’s common to burn out of software engineering. It happens to many, if not most people in software. Software is fun to get started and dabble and enjoy as hobby. However, when it turns into larger scale projects with team members, it’s harder to manage. It becomes tedious and difficult very fast.
It’s ok to walk away and say software did not work out. Change careers and do something difficult. There’s more to life and career than moving bits around.
It’s common to burn out of software engineering. It happens to many, if not most people in software. Software is fun to get started and dabble and enjoy as hobby. However, when it turns into larger scale projects with team members, it’s harder to manage. It becomes tedious and difficult very fast.
It’s ok to walk away and say software did not work out. Change careers and do something difficult. There’s more to life and career than moving bits around.
This guy is stuck in 2015
This comment hits the nail right on the head.
What is wrong with web dev? Why is it perceived not ok to be "stuck in 2015"? I've never seen so much churn and turnover in any other single layer of a tech stack.
What is wrong with web dev? Why is it perceived not ok to be "stuck in 2015"? I've never seen so much churn and turnover in any other single layer of a tech stack.
There isn't massive churn. As far as I can see, most of the JS ecosystem has been continually improving.
React has been around since 2013 [0], Webpack has been around since 2014 [1], etc.
If you're stuck in 2015, you're 5 years of updates and improvements behind.
The author, by his own account, does not want to keep up with the evolution of the ecosystem: "I suppose with the increase of complexity in what we want to achieve on the web the stack to achieve it with has had to also increase in complexity. For me, personally, it's too much".
[0] https://en.wikipedia.org/wiki/React_(JavaScript_library)
[1] https://en.wikipedia.org/wiki/Webpack
React has been around since 2013 [0], Webpack has been around since 2014 [1], etc.
If you're stuck in 2015, you're 5 years of updates and improvements behind.
The author, by his own account, does not want to keep up with the evolution of the ecosystem: "I suppose with the increase of complexity in what we want to achieve on the web the stack to achieve it with has had to also increase in complexity. For me, personally, it's too much".
[0] https://en.wikipedia.org/wiki/React_(JavaScript_library)
[1] https://en.wikipedia.org/wiki/Webpack
The tech stack in front-end changes constantly because things change : new constrain (mobile), new possibilities (webrtc, WebWorkers), new expectations (people sometimes don't just want a document), new Frameworks that attempt to solve previous problems better (react), and new trends (material UI) that require not just a css change.
It's not perfect, but given how much the ground shifts below your feets constantly while you maintain your web app, I don't find the experience that bad.
Make an static html document if you need a document. Make backend code with a sprinkle of vanilla js if you make simple interactions. Use react if you need your app to evolve fast, do tons of things, and stay organised.
That's what I do for my project, ciboulette.net .
The marketing website is static and js free. The UI to pass an order is an express server, html pages with a sprinkle of js. The administration UI is react + meteorjs.
And it's fine, not perfect, but I don't feel like it's too much.
I mentioned this in another comment above but for anyone feeling this way which I think is entirely reasonable and healthy even there are two options I would point them towards both at totally different ends of the spectrum.
The first one is for people who are mostly comfortable with backend development and want to have as little to do with the mess that is the churn of front end as possible. However for those people I would strongly recommend taking a serious look at Hotwire.dev which is a new approach from the same team behind Ruby on Rails and their vision of trying to bring that same level of simplicity to the front end.
It does a great job on that angle in particular and for most applications is likely to be entirely appropriate for your needs. They built it specifically while developing a modern web based email client so it scales up to fairly decent levels of complexity while still maintaining probably 85% of the performance of the standard SPA approach. But if you specifically want simplicity this is the best option out there I know of currently.
The other end of the spectrum is Angular which is all in on the SPA approach and everything that involves however it has a number of key differences between other frameworks that I think make it the “front end framework of choice for enterprise applications”.
It’s extremely stable both in terms of bugs, performance and API. Every code change for example that lands in main is tested against almost 3000 different applications full test suites inside of Google and I believe (not entirely sure if this is correct or not) but also a number of other enterprises in addition to that.
You are mostly going to be writing code as though you were just writing a regular application because it was specifically designed to sit on top of the web rather than trying to expose all the moving targets of the web platform and its various APIs directly to developers. I can not stress how much this can reduce headaches out of the box.
Basically the way I look at angular is Google said here is an approach that we have found works really well for writing apps that scale in terms of performance and code based. You won’t be able to outgrow this no matter how big you get and it’s what we use to run almost all of our customer facing revenue generating parts of the business (ads and cloud).
The approach is about as well tested as well you could possibly find. In addition to that if you follow our opinionated approach and APIs we are going to allow you to have a great developer experience. One main example of this is Angular has a rolling release cycle now where the tooling is able to upgrade your code base for you with each new release meaning you have no excuse for staying on the happy path. But on the whole the idea of front end churn is a thing of the past this way.
Additionally, behind the API that you are going to be exposed to Google are throwing a lot of “computer science” fire power at problems like performance and general engineering best practices etc but basically you can just outsource most of that part of the problem to the Angular team.
Disclaimer: it’s not magic, it’s still possible to write bad apps and even recently on here you will have heard people talk about Google cloud as a good example but it seemed like a lot of the reasons for that based on the inside baseball comments I read here had more to do with culture, product velocity and the sheer number of teams who weren’t working in coordination with each other. I still stand by the idea that the idea however that the sheer insane amounts of money Google has betting on Angular means that it is only going to get better and better over time at those issues.
The first one is for people who are mostly comfortable with backend development and want to have as little to do with the mess that is the churn of front end as possible. However for those people I would strongly recommend taking a serious look at Hotwire.dev which is a new approach from the same team behind Ruby on Rails and their vision of trying to bring that same level of simplicity to the front end.
It does a great job on that angle in particular and for most applications is likely to be entirely appropriate for your needs. They built it specifically while developing a modern web based email client so it scales up to fairly decent levels of complexity while still maintaining probably 85% of the performance of the standard SPA approach. But if you specifically want simplicity this is the best option out there I know of currently.
The other end of the spectrum is Angular which is all in on the SPA approach and everything that involves however it has a number of key differences between other frameworks that I think make it the “front end framework of choice for enterprise applications”.
It’s extremely stable both in terms of bugs, performance and API. Every code change for example that lands in main is tested against almost 3000 different applications full test suites inside of Google and I believe (not entirely sure if this is correct or not) but also a number of other enterprises in addition to that.
You are mostly going to be writing code as though you were just writing a regular application because it was specifically designed to sit on top of the web rather than trying to expose all the moving targets of the web platform and its various APIs directly to developers. I can not stress how much this can reduce headaches out of the box.
Basically the way I look at angular is Google said here is an approach that we have found works really well for writing apps that scale in terms of performance and code based. You won’t be able to outgrow this no matter how big you get and it’s what we use to run almost all of our customer facing revenue generating parts of the business (ads and cloud).
The approach is about as well tested as well you could possibly find. In addition to that if you follow our opinionated approach and APIs we are going to allow you to have a great developer experience. One main example of this is Angular has a rolling release cycle now where the tooling is able to upgrade your code base for you with each new release meaning you have no excuse for staying on the happy path. But on the whole the idea of front end churn is a thing of the past this way.
Additionally, behind the API that you are going to be exposed to Google are throwing a lot of “computer science” fire power at problems like performance and general engineering best practices etc but basically you can just outsource most of that part of the problem to the Angular team.
Disclaimer: it’s not magic, it’s still possible to write bad apps and even recently on here you will have heard people talk about Google cloud as a good example but it seemed like a lot of the reasons for that based on the inside baseball comments I read here had more to do with culture, product velocity and the sheer number of teams who weren’t working in coordination with each other. I still stand by the idea that the idea however that the sheer insane amounts of money Google has betting on Angular means that it is only going to get better and better over time at those issues.
You're making it sound like Hotwire is some novel thing the RoR guys have come up with. It's actually a copy of Phoenix LiveView, and not the only one either.
> ...The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn. If you know of a good opportunity, let me know.
One advice: be careful when you make claims like this, even if you are an extremely competent programmer, because it sounded extremely aggorant.
Picking up a new tech (framework, language, etc) during the job vs having years of experience building things with the tech makes a huge difference in terms of productivity.
Being language(or framework)-agonostic is cool. But saying languages are very similiar indicates that you probably know none of them in depth. Every language (or framework, etc) is its own microcosmo. (i.e. at the compiler level, design-pattern's level, etc).
One advice: be careful when you make claims like this, even if you are an extremely competent programmer, because it sounded extremely aggorant.
Picking up a new tech (framework, language, etc) during the job vs having years of experience building things with the tech makes a huge difference in terms of productivity.
Being language(or framework)-agonostic is cool. But saying languages are very similiar indicates that you probably know none of them in depth. Every language (or framework, etc) is its own microcosmo. (i.e. at the compiler level, design-pattern's level, etc).
It's a fair comment but you have to admit that the javascript world presents a set of problems that go way beyond the language itself. The problems are different in backend development and in a way they feel a bit more contained.
In the java world I feel I know exactly what to do even though it bores me to tears. In Go I know where to look, same can be said for python and dotnet.
As much as I love the really interesting things I can do in the JS ecosystem I find debugging large projects excruciating. I didn't find the comment particularly arrogant and it rang true to my experience.
In the java world I feel I know exactly what to do even though it bores me to tears. In Go I know where to look, same can be said for python and dotnet.
As much as I love the really interesting things I can do in the JS ecosystem I find debugging large projects excruciating. I didn't find the comment particularly arrogant and it rang true to my experience.
I'm asking you this as I believe it will help me in the future. Is having the knowledge about the tool better that having the skills to solve a set of problems? If I really want a position within a specific company (for whatever reason) but they use a language with which I haven't worked before but am willing to learn (and definitely have the learning skills for that!), would I be in a disadvantage with respect to another candidate, one that has extensive knowledge about the language (and ecosystem), even if I would have experience in the "field of the app being built"?
To second another comment. You have the domain knowledge so that is a valuable place to start. Build the applications in that domain you have experience in, on different tech stacks as side projects to demonstrate the competency. Ultimately, that's all experience is on your CV and the technical interview will be their opportunity to plumb the depths of your knowledge.
Everything else, and I don't know how to stress this enough, is interview technique.
Everything else, and I don't know how to stress this enough, is interview technique.
The answer to your question is a big stonking depends. There are some skills and knowledge that are transferable across languages and ecosystems. Some companies are happy to find good talent that are willing to learn and will teach them the specifics of their language and ecosystem. Other companies are unwilling to take on people who don't have 5 years experience in their stack. I once had a company reject me outright because the majority of my experience is with React and they use Vue. Both are Javascript libraries and more similar than they are different. Sometimes the argument in those cases is they need someone who can get the work done yesterday, other times its mere tribalism.
Your best bet is to build a couple of side projects with the language you're interested in and use it as proof that you've passed superficial interest and are willing to learn. After that its down to finding a company or a team that are willing to give you a shot. They are out there.
Your best bet is to build a couple of side projects with the language you're interested in and use it as proof that you've passed superficial interest and are willing to learn. After that its down to finding a company or a team that are willing to give you a shot. They are out there.
That's a red flag to stay away from the company anyway if they have no onboarding or mentoring.
how is it justifiable to expect every company to pay you to learn shit lol
Didn't mean to be arrogant at all. I simply said it because I have created things in a variety of languages, and to tell whoever was reading and looking for a BE engineer that I have no problem learning new languages that I may not know. Now obviously since I haven't been exclusively a BE engineer, I'm not an expert in BE, but I'm more than happy to be given the chance to become one, which is essentially the whole point of the article.
> 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.