I don't want to do front-end anymore
askonomm.com
askonomm.com
> 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.
The stacks run deep on both ends .. but I'm often not sure to what end.
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.
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.
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.
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=...
I've considered it many times, but I continuously find evidence to the contrary.
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.
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!
That was 4 years ago and beyond basic patching they've barely touched their infrastructure and it runs around $100/mo.
Not that I wouldn't do it, a lot of times it does make financial sense.
Tbh, I find most engineering orgs don't have the competency to pull it off.
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.
- 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?
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.
I've talked at length about it before in comments. Not really looking for the repeat discussions.
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.
[0] https://lichess.org/forum/lichess-feedback/hardware-of-liche...
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.
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.
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.
All the web queries are responded in <<< 1 second - so far....
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.
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 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.
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.
sadly, there is no kitchen blender powered by Node.js in the V8 engine.
418 I'm a teapotThat reminds me, there should be a mandatory session variable that tells you which of those you actually use to sign up/in
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.
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).
Do you have some sources for that? Just curious.
I personally avoid having to login via FB, Google etc.
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.
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.
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.
We joked at my old place that the best thing for a web dev's sanity long term is to retire into SQL
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".
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.
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.
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.
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.
And yes, I was wrong, rails has been around longer than that, it was just a guess.
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.
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 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?)
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.
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.
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.
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.
Have they? I don't see that in my user stories
IMO, what matters most is coding efficiency, how fast can business problems be solved with a low enough error threshold.
I think you nailed it.
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.
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.
old.reddit.com is another good example. Not everything needs to be an SPA.
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".
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.
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.
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.
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.
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?
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).
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.
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.
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.
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.
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.
Supposedly one-page apps are meant to improve latency and interactivity, but FB is slow as molasses and frustrating regardless.
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.
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.
There seems to be a confusion here.
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.
> 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.
Oh bullcrap.
This is just a rationalization from people who like the shiny.
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.
Intentionally broken is still broken.
Most sites and apps want users to click and engage as much as possible, not necessarily the most efficiently.
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.
I'm not familiar with the Facebook website but I can't imagine that it needs any particularly complex application logic under the hood.
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.
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.
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.
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.
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.
> 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.
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.
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.
Shadow DOM having better performance is a myth.
Google it.
TL;DR: it's there, but it's really only usable in like 5% of scenarios
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.
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 :)
Webpack is difficult to figure out at first, but if you have an existing config it should be a lot easier.
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.
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.
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.
Huh? function(state(A)) = state(B), always.
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.
I'm thinking about making a T-shirt with this phrase. Because it's important.
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.
I haven't seen a performant LOB app in years.
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.
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.
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.
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.
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.
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."
Apparently the author has always worked on their own projects, with its own (or its team’s) discipline. Let me state this: old-school front-end is a mess once you have to mantain an enterprise-grade application.
npm is pure joy to work with, in comparison with a huge mess of copy-pasted files in a “vendors” directory (if you are lucky enough to have such a directory! currently I’m working on a project where developers copy-pasted the content of JS libraries one after the other in a single “lib.js” file… for years!)
Front-end development has now reached a very fine situation regarding code hygene and modularity — and this makes me very happy to be on the front-end side.
I 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.
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.
- 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.
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
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.
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.
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...
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.
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.
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.
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 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.
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.
One reason for the growing complexity in UI tooling is that many websites we build today compared to 10 years ago are not "stupid little web pages containing youtube embeds and guest books"
With that being said, many people are still building simple websites, and React/TypeScript/Webpack/Babel/CSS-in-JS/et al. probably isn't solving any "real problems" for them.
I've had to learn and adapt during my whole career, but I'm also more productive today than I've ever been, thanks to the tools that are available to me as a front-end developer.
I still reach out for Vanilla HTML/CSS/JS now and again, but I mostly deal with large and complex UI's that need to be shared across multiple projects and hundres of developers.
From a historical perpsective: jQuery solved a very real problem at it's time: simplifying and doing consistent/reliable cross browser JS development. Backbone.js later came along to solve the problem that JavaScript apps were now so large and complex that simply dropping a few JavaScript/jQuery files was not a scalable way to build. As applications became even more complex, React.js made it easier to deal with UI/state changes in large code-bases. All of these abstractions grew out of necessity.
Learn one set of tools really well. Make sure it's here to stay, mature, and has a large community. My fav is Nextjs, but it could be anything. Make sure it comes with everything you need, including a CLI to set up your project. Stay as close as possible to what the stack gives you. Don't build on top of it, unless you're willing to upgrade constantly. Avoid configuring your build system yourself, unless the framework gives you clearly defined escape hatches. (Like Next does.)
Learn the underlying fundamentals. Learn about algos and data structures. That will be relevant forever.
Most importantly, ignore these "20 state management libraries you should learn in 2021" articles. They are poison. And nobody cares.
I think 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.
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?
- 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.
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.
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!
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".
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.
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.
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 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'm still looking how to improve FE testing but it is something what absolutely makes my life easier.
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.
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.
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!!
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:
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 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.
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.
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.
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 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
(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.)
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).
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.
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 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.
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 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.
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.
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.
I regularly engage in refactoring efforts that would be prohibitively time consuming in React, which I also have production experience with.
* 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!!).
For a talk about this: https://www.youtube.com/watch?v=Ie-gqwSHQr0
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.
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.).
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.
> 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.
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.
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.
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!
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...
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)...
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.
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, 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.
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.
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.
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?
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.
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.
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.
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.
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.
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 :)
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
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.
On top, just everybody and his mother has an opinion on how the UI should look and work.
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.
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.
Good luck OP!
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.
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.
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.
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.
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.
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 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.
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.
Frontend devs also have less algorithmic FAANG (and others) interviews[0]
[0] https://mobile.twitter.com/dan_abramov/status/10786586563449...
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
Time to give ClojureScript a shot? Great time to get acquainted with Fulcro or Re-Frame.
Both have new docs and videos out.
And there’s zero reason to use SCSS.
Experience translates into seniority easier and you don’t need to sprint non stop just to stand still
Also, All tools are not for everyone, so developers should be comfortable not working with specific tools.
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 ...
Phew... Using a package manager ? oh no... not that
lol wtf
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.
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.
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.
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)
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.
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).
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.
Everything else, and I don't know how to stress this enough, is interview technique.
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.