I completely ignored the front end development scene for 6 months. It was fine
rachsmith.com
rachsmith.com
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.
That or I've just been lucky. Very possible. I have mostly ignored the fuss over redux and friends.
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.
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
Also both of these libraries are from the official redux team.
Just a really happy user and has helped me tame the state problem.
It may be verbose, but it’s the one thing that all the other devs won’t be implementing in some weird, proprietary way.
I really like the boiler plate though. Everything is very specific
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.
(I mostly like it, for the record)
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 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.
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
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.
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 !
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.
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.
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.
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?
Outside of that sector, I personally don't know anyone who would choose either - but it's definitely still a significant market segment.
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.
The first rule you should remember when reading HN is the real world is not HN.
Can you explain what you mean by that?
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.
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.
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).
And it's used exactly nowhere. Can you name one project that is rust based and isn't part of the rust toolchain?
Parts of Firefox are implemented in Rust.
Swc is a JS bundler written in Rust.
I agree it's not a super in-demand skill as far as job postings go, but it's not exactly completely unused either.
Some others : https://lib.rs/command-line-utilities
Oh hey, that's me :)
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.
It's fun looking for fundamental insights.
This sums it up quite nicely.
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).
Alternatively, why not engage with them?
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)
AKA Fundamentals :)
Sorry I said it, but it's true.
This has not been my experience. FE are expected to know a lot, and most backend devs I've known respect that.
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.
The latest frameworks aren’t just “trends”, like fashion.
They’re improved ways of doing things. Better, simpler, more reliable.
Advocating to use tech that changes slowly, or avoid latest frameworks is advocating being slower and less productive.
I do think a lot of frameworks are fashion statements, but that’s okay because style matters when doing creative work.
They’re developers from other ecosystems who just want to look down in javascript and feel superior.
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 once got bounced from a job interview for not knowing about a quirk of the newest XCode (less than a week old).
Sounds like they did you a favor. Who’d want to work for people like that?
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?!
So only interacting with HR/management would be a red flag for me.
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.
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?
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'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.
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.
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.
- 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)
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 am seriously considering just using something like blazor or phoneix live view so I can ignore front end entirely.
Also blazor and phoenix will be more magical abstraction. Basically have to stand on the shoulders of giants these days.
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?
I've recently also played around with adding AlpineJS to it and it solves some of the issues I was having with LV.
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.
I'm still mildly convinced there's a front-end engineering bootcamp / JS framework industrial complex operating behind the scenes.
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.
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 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.
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!
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.
I also completely agree that it's a much bigger picture and that life situation plays a giant role in it.
Says who?
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 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.
Google bots might prefer another site which loads faster compared to your site which will affect SEO.
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.
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.
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.
[1] amusingly, today you can freely download a PDF of the method, as it was published in the original latin: https://royalsocietypublishing.org/doi/10.1098/rstl.1694.002...
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.
The 'framework of the week' club has never held my interest.
If https://webassembly.org can liberate us from traditional web development, that's fine by me.
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.
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.
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.
Is the front end still changing all that fast?
Use the tools you need and ignore the ones you don't. It's the same as any kind of software development.
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.
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.