Haha. I ignored the web dev scene for a year or two to work on something else. Angularjs vanished and nobody will hire you unless you have worked with react. Rest is gone and everyone is obsessed with graphql. Kubernetes really took off. React alone isn’t enough though, it’s nextjs and everyone is looking into trendy redux replacements now. Typescript is everywhere. Everyone assumes you can’t code your way out of a paper bag if you haven’t worked with their exact stack for one year longer than it has existed, even though it’s all incredibly easy to learn. Also interviews are even more nuts and irrelevant. It’s depressing that your relevant important skills don’t matter at all unless you are self employed
When I started learning to code few years ago, tutorials were always, "how to create a blog ?" because it shows everything (authentication, crud, nested view, rights).
Then javascript framework came out. It was so hard that they move to just a todolist tutorial because even the creator didn't know how to create a blog with their new cool tech.
Some blogger were still able to understand how to use it and release todolist tutorial with authentication to demonstrate authentication, session management and rights.
Then new cool javascript framework came out and now it was even harder to code, creators weren't able to develop a todolist because it was too hard so their tutorial was just a basic counter application.
Now with nextjs we are even a step further. The developers don't know how to use it (is it even possible ?) so the tutorials show just how to "start" an application, load css and how to create a route.
In just a few years we came from create a full application to not even know how to do a todolist. (Imagine form validation, it must be so hard !!!).
Everybody seems happy and very productive. It must be myself.
In 15 years we came from 15 minutes to create a blog with this old tech to a few days of work. That's a lot of progress we don't have to reload the page !
This is a wonderful comment. You've put into words what I've felt about the industry these past 10 years.
Complexity correlates strongly with onboarding. The more complex your framework, library, or tool, the longer and steeper the learning curve to become productive with it.
This is not about a learning curve, I feel like you will never be productive with any of those javascript framework.
Yes, of course there is a learning curve. For react you will be a lot faster after a few month using it. And this curve is a lot longer than for rails(react and rails are just here for example here).
But it seems even after being a react god master you will still be x10 times less productive than an average rails developer for developing an everyday feature.
> But it seems even after being a react god master you will still be x10 times less productive than an average rails developer for developing an everyday feature.
This is a very enlightening point, maybe because the creators of React can afford to pay for unproductive gods, and those crazy assumptions are accidentally embedded in their tools, unlike rails, which was built by a guy trying to solve problems in the optimal way.
The real issue is when such tools become the standard for everyone else, and this often happens because giant corporations have the capital to push their bullshit, just to make their hiring process easier.
I've heard of a theory that says "A's hire A's but B's hire C's". The gist is that cream-of-the-crop interviewers actively look for open-ended-ness and the possibility that the interviewee may be better at things than they are, whereas less effective interviewers only look for people whose skills are a subset of their own (and by implication, design tests that only leverage the skillset they know, hence the "must have 5 years GraphQL experience cus I ain't got no interest in coaching you" attitude instead of "I am prepared to go out of my comfort zone and talk to people to get them up to speed on tech stack minutiae")
As a candidate, I've "fired" interviewers that were just wasting my time asking me about googleable trivia. There are other employers willing to pay premium for experience over technology memorization.
> I've "fired" interviewers that were just wasting my time asking me about googleable trivia.
I feel like this is a great bit of advice for interviewers and interviewees: for the interviewer, don’t ask about things that are easy to look up, and for the seeker, take it as a red flag if they do.
I agree that good engineers can learn most tech fast, and that that is due to experience and not them being inherently smarter than others. If this is true though, how do you measure (non specific) experience? Maybe asking for 100 relatively easy but totally random knowledge crumbs? (some web, some unix, some networking, some functional programming, etc). It would be impossible to score high, but well rounded engineers could get more of them right. This might actually be a better approach than asking a few hard questions.
> everyone is looking into trendy redux replacements now
A lot of people are probably soured on redux forever (that's how these things tend to work) but they've done a really great job with their hooks based API and especially the redux toolkit/RTK Query. Getting started today using the toolkit is so much more straightforward and easier to understand that it feels like a totally new library. If you're still living in the old school redux world of trying to explain containers vs components, mapStateToProps, how to build reducers from scratch, how to organize ducks, etc., you really should take a look at the newer tooling.
Totally! Wonder if people realize that the person who wrote a lot of these libraries (hooks) as part of the core React team wrote Redux before joining the team? Dan Abramov. Everyone soured on an older (worse) abstraction because the same engineer who build the abstraction thought about it longer and built better abstractions that were also easy to adopt. I think that’s super cool, and doesn’t quite fit the narrative that people are trying to paint here of “fad chasing.”
The speed with which Google moved things around 2012 was just stupid. Gwt to angular was fast and left basically no real migration path. Or recompense for having jumped on in the first place.
I believe angular got better, but I didn't stick around to find out.
React has at least been steady. It has some parts that I'm personally in the camp is over engineered. But, I think that is more that the scene encourages highly engineered solutions. Reminds me a lot of the j2ee days where there was just so much ceremony on a basic ui.
The rest of the technologies you list are similar to me. Not wrong or bad choices, at large. Also not typically needed, at large.
Huh? I did a bunch of React work a few years ago when everything was classes. Then I went off and did other stuff for a bit, and when I came back to React, everyone was using hooks.
I got more into "principles" than stacks recently and can fight might way telling performance optimization stories about stock market-connected microservices and so I get less question about stupid stuff like how you color a div using react vs angular.
Honestly, I ve done all the frameworks at various point, either they help touch your dom or clean your code, and now I teach noobs in JS at the bank to just do their own frigging well cut functions, around jquery and basta. The only thing I allow is a css preprocessor because that's a true progress.
There s so little to gain with a JS framework (I agree typescript is a good initiative tho) and so much to pay in time wasted. And God knows impatient idiots like to "migrate" "legacy", so the least surface you expose to "unmaintained framework", the least you hear those morons steering the company towards non productive migration work to get less than we started with :D
> everyone is looking into trendy redux replacements now
What's wrong with redux? I've been using it in my last 2 companies, it scales amazingly and I think that's one of the stack in react that I'm comfortable with
I enjoyed it while I used it but my main issues with it were with the developer experience and how many files the logic was spread across: actions, action constants, reducers, etc. When you have to edit 4 different files just to add a loading flag then I feel like something has gone wrong. If it solves your problems and you’re happy though, no need to let anyone convince you to change!
You should checkout redux toolkit and it’s sibling rtk query - it solves these problems you mentioned really well and has been a breeze to work on a complex app with multiple people.
Also both of these libraries are from the official redux team.
Just a really happy user and has helped me tame the state problem.
Redux vs. jank proprietary solution aren't the only options. For instance, a lot of what people use Redux for is fetching and storing API data, or managing cross-component state. A combination of react-query[1] and React context does the same in a much more developer-friendly (IMO) way. Again, not advocating for anything, just important to know what the options are.
its global state with a bunch of ceremony. outside of things like the user session and feature flags its essentially useless and more error prone than its worth.
It's a bit bad if you're not using typescript—then it's entirely fine.
It's a bit bad if you try to add a bunch of extra shit to it unless you really need that shit (e.g. Thunk).
The terminology's kinda bad ("action" for "event", especially, which also gives us junk like "action creator") which can make it seem more complex than it is.
Both your point and the article one are valid. Your point reflects the reality of the market while the article correctly states that the most important skill of a software engineer is the ability to learn quickly (built on top of a solid background of computer science fundamentals). Most of today's new things are in fact just evolutions of old concepts slightly revised and adapted.
Unfortunately the market is more driven by the latest FAD rather than rationality. I am of the opinion that the main responsables are WE, the software engineers. I have seen several times that SE in a position of influence will sistematically go for the latest FAD rather than make a rational choice (which in most of the cases IS the "boring stack") for the sole purpose of pumping-up their CVs. At the same time this is allowed by lack of competence and governance on the IT by the business.
The bottom line is that our entire sector instead of progressing by leaps and bouds keeps on continuosly reinventing the wheel and makes only very small incremental changes and adaptations. The innovation and progresses in productivity that we had in the last decade pale with respect to the one that we had , just for example, in the nineties and are mostly due to an increase in processing power. And there is still much to be discovered: our sector is still very immature. In some way some of the experimental development environments that were available in the eighties were more advanced than what we have today.
Even if I am not a Ruby user and so my judgement could be superficial I have the impression that in the last two decades the only community that has consistenly tried trying to challenge the status quo and really improve productivity for our profession is in fact Ruby community.
> Everyone assumes you can’t code your way out of a paper bag if you haven’t worked with their exact stack for one year longer than it has existed, even though it’s all incredibly easy to learn.
Indeed, I see this a lot – complaining about lack of skilled workforce and not having trained anybody themselves so far or even talking to someone with different buzzwords in the stack. That's parasitism at it's best, isn't it?
Obsession with the latest frameworks and the proclivity to refer to someone as an "X developer" for some X ∈ {popular frameworks} is a sign of ignorance/immaturity, both for developers and hiring managers.
Those with a solid understanding of the underlying principles (both computer science theory and, in the case of front-end development, the core web standards) are the best positioned to make the most impactful contributions.
Focus on mastering stuff that doesn't change, or changes slowly. Otherwise what you learn will be irrelevant five years from now.
"Focus on mastering stuff that doesn't change, or changes slowly. Otherwise what you learn will be irrelevant five years from now."
After you followed the x. technology trend, you should have worked out the basic concepts behind them at some point, if you not just copy pasted and edited until something somewhat worked. They are seldom really fundamentally different. So every (necessary) technology change in the future becomes more easy.
(but you might feel less motivated for unnecessary, but mandated change, that just reinvented the wheel in yet another color)
Recruiters, HR and interviewers often are nothing like the culture of the people you will end up working with.
Treat everything as a potential signal, but take care not to mistake noise for signal.
Also recruitment is often about reducing false positives (avoiding bad hires), at the cost of a high number of false negatives (failing to employ suitable candidates). Try not to take it personally when they give you a no for an obviously bad reason?!
The company I worked for was infinitely worse (literal Sociopathic management). The pay was better, it was closer to home, and the work was more stable. If I had to guess-- I'd say the existing iOS guy wanted a friend to be hired so he tanked me.
TBH, as an Apple dev it's really your responsibility to be up on the latest and greatest platforms and dev tools.
Apple broke development on OS X 10.3 in order to have a new C++ ABI ready for 10.4. Want to compile programs for 10.3? You need to use Xcode on 10.4 to do that. You don't have 10.4 yet? What kind of loser are you?
Thank you for sharing this. This reflects the large part of my experience working in the Government and banking IT sectors.
I don't see my previous employer (a Federal government) running workloads on K8s anytime soon.
However, I do hope they've finished their migration from Windows Server 2008 by now though (we started this project in 2018, but I left halfway through).
How often do you see Rust mentioned here? Rust's actual use in the industry is minimal. Yes, it's growing, but it's relatively unknown. The small academic team I was on wrote a stats app package using Mithril. Nobody's using mithril, it's hardly discussed here, even though the author posts often.
I truly believe that mithril is better than React or Vue people just don't know about it, it's not part of the hype cycle. React is FB and was one of the first and Vue is designed in a very community-centric way. Had we done that project today, we'd probably pick one of those because they are a lot better on resumes.
HN is full of people that post dozens of comments a day. You have to ask yourself what the people who don't need to talk about it all the time are using.
I'm a big believer in the idea of mastering fundamentals, and even explicitly mention in the mithril.js framework comparison page[0] that you can build production quality stuff with any framework (including of course mithril.js)
There's this pervasive notion with newer tech that new things must be objectively superior than old stuff, but the way I see is that everything comes with trade-offs, e.g. Rust may indeed be safer than C, but conversely it's also been characterized as difficult to learn/keep up with, and IIRC has a less broad range of target architectures.
I think, however, that reading resources like the "The descent to C"[1] article that's up on front page can help someone getting into C, but also Rust, and even someone who wants to gain some insight about how Javascript works under the hood, precisely because it's a resource more about fundamentals than C per se.
Similarly, there are fundamental patterns that appear over and over in competing technologies (e.g. routing in JS frameworks, or DI in object oriented systems), and this goes for even the design of said patterns (e.g. principles of encapsulation, composition and orthogonality)
I've even had success applying the search of fundamentals to other disciplines. Bruce Lee famously said "fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times". But one hidden insight is that in martial arts "it's all about the hips": once you "get" the insight about the role of hip rotation, all striking techniques improve by leaps and bounds. Many such "fundamental" insights exist, from insights about balance to insights about tells.
In music playing, one universal insight is that effortlessness is quite literally a matter of muscle relaxation (beginners often get stuck in a rut because they tense up unconsciously). Etc.
Rust has a huge exposure in the programming community. I may not know how to write it, but I sure know what it is. It's not just limited to HN in awareness.
You say that but my exposure to Rust was through HN.
That same team I'd sit down and chat with the CS PhD majors that were doing machine learning. It genuinely surprised me when a brilliant student said he'd never heard of Rust.
TIOBE is a garbage metric, but Rust's numbers are paltry there. It's key to some really important projects, but it still isn't a widely-used language.
Was reading through some C++ at work the other day and was like “why is this reference.. assigned to… copy constructor?… oh, yeah…”
IMO it’s better (explicit) to see a call to `.clone()`, but maybe this is because I’m not up to my elbows in C++ everyday. Either way, I think Rust will continue to grow in popularity (C as well).
Redox, quite a few utilities that replace classic Unix ones with something that has a better interface (ls, and I think something that replaced grep), probably more.
HN would have you believe the whole frontend scene is totally replaced every month. At our company we started using React about 3 years ago and React is still the industry standard today and likely will be 3 years in the future.
AKA, be a backend developer, because tech changes less frequently there and backend devs get more respect than front end and "full stack" devs, regardless of how talented they are.
Backend devs definitely know that, but it's management or outsiders who seem to think otherwise.
I've performed both roles in my career but have always been impressed by talented frontend devs ability to make some otherwise batshit ui spec come to life ... but regardless, I was always paid more when I worked on the backend, and so was every other backend dev I knew. Maybe I'm the outlier.
When non-programmers think of developers they always imagine front end devs. Rarely do they understand the distinction or specialization of programming roles.
Frontend devs who can also design (especially make impressive mock-ups) and talk OK are gods in meetings, which translates into better social standing (which can equal money, if they play their cards right and move into "product owner" and such, over time)
Eh, idk. We could have lisp, x-expressions, macros, and DSLs instead of most frameworks. We could even use lisp dialects to “write C” (eg Chicken Scheme).
I do think a lot of frameworks are fashion statements, but that’s okay because style matters when doing creative work.
Frameworks are a spinning wheel that reinvent technology every 3-5 years. It only seems like an improvement because the people using and writing it are relearning the same lessons that their predecessors already learned, but are unaware of this.
There’s only so many ways to write a reasonable GUI framework. There’s only so many ways to do general purpose data stores. There’s only so many ways to handle events. There’s only so many ways to schedule load/threads/work. There’s only so many ways to build code. There’s only so many ways to do object/class/etc. inheritance. There’s only so many ways to do interfaces/contracts/whatever. etc. It’s the same patterns and trade offs over and over again, but if you’ve never much of anything outside of web dev you’d never know that.
The past 15 years of web dev is the story of young programmers racing forward, having never bothered to look at the past.
I spent over a year away from React at a company using a very obscure front-end framework. Afterward I felt slightly behind on the uptick in NextJS and Hooks usage (these both existed but were uncommon before), but... it really wasn't a big deal. I picked it up. A couple months later I'm quite comfortable with both (I have opinions about hooks, but that's for another day)
I think people overblow how big a burden it is that things keep evolving. Especially once you know the language/platform pretty well (that part doesn't change so much) and you've been around the block a few times ("oh, this is like X but different in a couple ways"), it just really isn't a huge thing to learn the next trend. Sometimes it's a genuine innovation, sometimes it's a familiar pattern coming back around in a new set of clothes. Neither case is a catastrophe.
> What I’ve learnt through experience is that the number of languages I’ve learned or the specific frameworks I’ve gained experience with matters very little. What actually matters is my ability to up-skill quickly and effectively. My success so far has nothing to do with the fact I know React instead of Vue, or have experience with AWS and not Azure. What has contributed to my success is the willingness to learn new tools as the need arises.
What's not fine is having poured resources into a framework over the course of a few years, only for that framework to first cease to be necessary, and eventually become a barely-supported ball-and-chain.
This applies to almost everything released prior to HTML5. The problem is that re-writing isn't always an option, but the old stuff permeates almost every source file and is extremely expensive to decouple.
I suspect this will sooner or later apply to everything released immediately after HTML5. Eventually, everything used today will face the same fate.
There's something to be said for rejecting frameworks that aggressively inject themselves into code bases and which can't easily be extracted.
For my own frontend stuff (ie when I get to choose), I've been using Clojurescript and re-frame for about 6 years now. Everything else, I've ignored. I'm much happier this way.
That's not to say that I haven't learned at least some of the newer developments at least in react-land, for interop purposes I know about hooks and such, but I've mostly been able to avoid it and certainly don't have to care about it most of the time.
As for work, I just picked up whatever the team I joined dictated each time I changed teams. It was fine.
I worked at Apple in the 80's. We got a sabbatical back then - 5 weeks after 5 years. I saved a bunch of vacation and took off during the Thankgiving -> Christmas season for 3 months. I was afraid that when I returned I'd be totally swamped trying to catchup at work. Guess what - during the 3 months absolutely nothing changed.
I switched to Flutter 2.5 years ago for frontend. The blessing of having incredibly well designed UI framework that gives you NATIVE iOS/Android/WEB/MacOS/Linux/Windows app from the single code (in a decent language and without a gram of html/css/js crap) is hard to describe. I'm stunned by how many devs yet to discover flutter.
Web frontend ecosystem is just a pile of hacks on top of hacks compared to what Flutter team and community has built over just few years.
I'd like to trust Google, but they deprecate Android functionality at an astonishingly fast rate. It's a significant risk factor that should be taken into account.
Doing a quick "Find usages" on java.lang.Deprecated in my current project returns over 4,000 instances from Google/Android libraries and it's a significant frustration within the Android developer community
I don't think devs haven't found it, it's a combination of:
- They found it too early and it was pretty broken (I fit in this camp a little)
- They found it and consider Dart a step back from the main languages on most platforms. Dart feels closer to Java/ObjC than Kotlin/Swift for those who are in the mobile space and know what that transformation was like. (I mostly fit in this camp)
I hate javascript front-end stuff with a burning passion. I wanted to make a small widget, and somehow I needed 100+ libraries for this. The compilation/build/etc process makes no sense whatsoever, and I just type magic commands and hope it works.
I am seriously considering just using something like blazor or phoneix live view so I can ignore front end entirely.
This feels like an incredible security problem to me. When companies like 1Password switch to an Electron client, I'm left wondering how many dependencies they have. How do they protect against some minor library change introducing a security flaw?
Last year, I built a little widget thing in plain JS with Parcel[1]. It took away 100% of the tooling I used to spend a couple hours nailing down just to get started. When I need small JS projects that don't need a framework, etc, I'm likely to use Parcel in the future.
You didn't need 100+ libraries, or a compilation/build process. You just thought you did because that's what everyone else is doing. You could have used plain HTML, CSS and JS and probably have built it faster, and ended up with much leaner code.
Only 100? Create-react-app said it pulled in something like 1600 last I saw (is that accurate? It must include duplicates, right?). It makes me nervous about security and stability when I see that
Been ignoring it for maybe 15 years now. The DOM API is looking great these days. OO style JavaScript has never let me down. Prerequisite: ability to write concise HTML and CSS. One newer thing I do utilize is TypeScript which makes developing and refactoring more complex web apps much easier.
I've found the way to reduce churn the most is discard frameworks and DSLs whenever possible.
This morning, I rewrote a page of frontend code for a scheduling webapp. I'd initially built it in TS/React years ago. Switched to Rust/WASM with a custom VDOM-based framework a year ago.
I'm reasonably confident I won't rewrite it again in a new framework: the new page is an HTML document with an included JS script that performs standard DOM manipulations using the API described on MDN. The code's now insulated from changing dependencies because it has none. And the page loads fast.
Completely agree. After healthy doses of React / Angular / Vue development, you kind of reach a point where wrestling with the quirks and overhead of the framework, when it's not strictly necessary, seems like more work than just tossing up some plain standards-compliant code.
I like getting rid of dependencies whenever possible.
I think I read something a little while ago that that's actually what Netflix sometimes tries to do with their front end - plain, dep-free code wherever they can make it work.
Yeah, it seems to me they took a dependency out of plain sight and replaced it with an opaque binary that has to be built externally with its own dependencies and declared victory.
React didn't substantially improve code flow, and added a dependency, config, a build step, and DSL. Typescript added a build step and config.
Stated another way: The new page is a single file written in web standards. The React/TS way is more complicated, requires a bigger download, and is slower.
Wasm and rust sound amazing. Are there any downsides? Performance issues? I heard there can be issues with dom manipulation but might be misremembering
Currently, WASM calls ultimately execute DOM API commands, so there is no performance benefit for DOM manipulation. This is expected to change, but I don't know the details.
I can't explain why, but WASM files end up much larger than an equivalent JS file. (And often larger than a NPM/framework-based etc JS bundle) Also, a build step.
Perhaps someone else who's used WASM more recently, or used it with a language other than Rust can comment.
It's nice being able to use whichever language you wish, but IMO not worth the downsides in its current state.
I love her attitude, and I think mine's similar. Main difference being that I usually enjoy the learning experience; don't find it frustrating. I kinda love that beginner feeling and knowing there's lots to explore. Even if I end up disliking what I'm trying, I usually manage to find things I learned from it; so it's still good!
Edit: To anyone wondering about the comments, I initially assumed the author was a guy! My deepest apologies to the author! I thought the commenter "Lucas ..." was the Author's name... I'm so dum; sorry!
Definitely can agree with the sentiment. I've done frontend dev since '97 and have multiple times skipped a year or two without staying up-to-date with the current browser/development trends without issue.
It's generally pretty trivial to keep up and maintain usefulness by focusing on the fundamentals (I completely skipped the DHTML fad for example -- lots of widgets you could throw into your page that animated around) and instead picked up JS DOM API and CSS once browser support stabilized a bit.
---
Just a note, when I visited the page there's a small bio intro on the post that introduces Rach as a woman.
The author isn’t a guy! I agree otherwise, it’s refreshing perspective.
I spent a few years fairly deep in backend work and worried quite a bit about going back to the front. Ultimately it ended up being a valuable break and pretty much all of the important things I’d learned before were still totally transferable. I think as long as you’re learning something, regardless of the discipline, your brain will be happy and you’ll find ways to apply what you’ve learned in all kinds of places.
Sometimes the most valuable skills are fundamental in just about any discipline. Having patience to solve problems, or perseverance are huge. Finding meaning in what you do. Maintaining good work life balance. This stuff, in the long view, ends up mattering way more than what a popular API looks like right now.
Hello! Thank you for pointing that out! I was a bit silly and somehow came to the (wrong) conclusion that "Lucas" (the first commenter) was the name of the author... I don't even know what to say lol. I just went a bit derp there.
Recently I changed jobs and moved from being a front end dev to a backend dev role. Less framework chasing, more architectural concerns / long term planning, slower pace of development / expectations from stake holders and double the pay.
For reference: I used to do backend dev but I did FE exclusively since 2016.
The problems seem to be harder on the backend, henceforth more challenging and interesting. Also optimizing code for AWS directly contributes to the bottom line of a company. So if you save $10k a month because you optimized some service, it's more likely to be rewarded.
Optimizing web pages make page loads faster, but doesn't necessarily contribute to the bottom line.
It does but its hard to quantify, if your site loads in 4 seconds but after a change the sites loading time becomes 8 seconds you will lose some people who will be annoyed and wont sign up.
Google bots might prefer another site which loads faster compared to your site which will affect SEO.
When I interview, I prep for full stack engineer roles.
Company interviewed me for full stack role and then offered me a backend position (cause I "performed very well" in the system architecture rounds).
> Although it can be frustrating to go back to being a complete beginner at something over and over, each time I pick up something new I further my expertise in being a lifelong learner.
Sure, but it would be nice if revolution-for-revolutions-sake wasn't the default position of the industry.
There are plenty of good ideas (my hobby-horse: hypermedia) that have been dumped on the ground because people decided to reinvent everything, rather than building on the existing conceptual model.
This is a solid observation albeit one I think most people come to eventually. For the most part once you have already dealt with the spectrum of tools, the new ones just aren't different enough to be worth killing yourself to keep up with. Know what they do, and what they are good and bad at if you are in the position to be making relevant decisions, but actually learning them just isn't that big of a deal.
I stopped following news back in 2011 while previously being "addicted" to it. Whether about about tech, music releases, world news, etc. Turns out, if something is important enough for me to know, it will reach me eventually one way or another without me having to proactively track everything. If I start something new or a have a problem to solve, I research what an adequate, modern way to do it would be.
I was frontend developer at time time but moved to more backend dev again. When I last year did a frontend project with react that I knew only conceptually from people talking about it for the first time, I didn't had any problem using it productively in a couple hours. The only thing that was a bit jarring, was that many people seem to have forgotten that there are html tags besides `div`.
While software certainly moves fast compared to things, that have been around for hundreds or thousands of years, I feel, for the most part it just moves fast on the surface. The fundamentals have been pretty much the same since I started and I reckon for decades before that.
I've definitely been caught in the trap of chasing frameworks. What finally cured me of it was to go as deep into the JavaScript language as possible. Not sure if this works for everyone, but once I spent a lot of time learning the language under-the-hood, the shininess of the hot new framework or library lost its luster and I was able to focus on what I actually needed to accomplish.
Recently I've been lucky enough to work on a software project that requires a bunch of probabilistic calculations -- so I've been needing to learn about and apply one-dimensional numerical root finding methods that were state of the art in the _seventeenth century_, and still highly applicable today [1].
Maybe a tactic could be to figure out roles or niches where a relatively larger proportion of the work involves dealing with problems or aspects of reality that change at a relatively slow rate (physical laws? logical axioms? geology? human biology?), and where you can spend a greater fraction of your time working from first principles and accumulating depth and breadth of knowledge with a longer half-life of usefulness.
On another hand, there can be a good living in helping address supply / demand imbalances in the market for $latest trendy ephemeral thing.
This is pretty much why I've avoided professionally doing front-end dev. The investment of time seems basically guaranteed to be worthless in less than 2yrs.
I wish I was better, since then I could truly build my own products - but I'm aiming to have enough income just to hire more talented front end engineers to build for me instead of using time to build the skill myself.
Oh, no. Webasm is just a way to run arbitrary binary programs in the browser. You need a whole stack on top of that. And there are lots of choices.
You probably shouldn't be using webasm unless you're 1) writing something like a 3D application that needs all the CPU and GPU power it can get, or 2) you're writing some kind of obfuscated hostile code, probably ad-related.
It might fragment things further, eg imagine a job posting for a C++ programmer with web experience, browser knowledge and use of a specific C++ front end web library.
I ignored it for years and things are still great.
Still running with simple Bootstrap themes, jQuery and mostly server side rendering and have thousands of users on my side project and lots of paying ones too.
Confident I could scale this to hundreds of thousands of users with no issue.
Early in my career I saw that front-end was a whac-a-mole in which libraries and frameworks to pick up. It was so stress-inducing for me that I decided to focus completely on the backend. Sure, in Melbourne this has been a financial detriment (fullstack out-earning backend development), but the stress levels have far outweighed it personaly.
I was asked to do a take home interview question the other day in which from scratch I had to create a react app with an API. I literally spent two days looking at what the state of the art solutions are for typescript react apps and node APIs. It’s impossible to stay up to date I think!
High adaptability means career survival? You don’t say.
Front end development has matured around the reactive pattern so of course switching between react and vue is no real challenge. But the maturity of a domain is the commoditization of the domain. So I will surely be looking out for what’s next.
Go is a good choice for web backends. Google maintains the libraries for most of the things you need for web backends, so they're well-debugged and heavily used. The language itself is just adequate, as it was designed to be. It's not overdesigned.
I've used Go for a web backend. Partly because it's fast enough that I can get quite a bit of useful work done on a US$12/month shared hosting account. It's amusing to see how much you can get done on low-cost shared hosting.
I write high-performance 3D stuff in Rust, but wouldn't bother with it for webcrap.
When I returned to work after my 6 month break, CodePen was moving their backend code from Ruby on Rails to Go, and Front End to Next.js. So I am now learning how to program with Go and reading a lot of Next.js docs and resources.
If you go to the front page of her site, it says
Hi I'm Rach. I'm a developer building software for CodePen, wife, mother of two, productivity nerd and recovering screen addict. This is my blog.
So: someone at $dayjob decided it was time to rewrite $dayjob in Go. Thus, everyone there must learn Go.
