15 ms·

I know many developers who want nothing to do with frontend work because of two main factors, 1. The obsession with bleeding edge technology and 2. The develope

I know many developers who want nothing to do with frontend work because of two main factors, 1. The obsession with bleeding edge technology and 2. The developer community being disproportionately composed of young and/or new and/or self-taught developers who "discover" new paradigms constantly. Those factors create a constant churn in technologies in which nothing is learned and everything is repeated every six months to two years. It's like watching mayflies argue about politics. This article feels much the same.

BSEdlMMldESB 3y ago
I see this as a problem to be solved in the software-education space
- intrasight 3y ago
  It totally could be solved. Make it a licensed profession. Make it like the legal practice where you have to go to school for 3 years and then pass a test to get your license. Only half joking.
  - getpokedagain 3y ago
    I think left to our own engineers would have resolved to something like this already. The issue as I see it is corporations and business people have taken over the leadership of this trade to rake in money regardless of what it does to the real world. And why wouldn't they you can create a problem out of thin air, solve the problem poorly selling the solution, and then when your rushed, half assed and bad solution has issues, you can simply sell the fix to that as well. I doubt we will see much progress in the quality and rigor of software engineering in the near term, it will need to take a shift from making money in the short term at any cost to making a quality product. Instead we see the same thing happening to other industries so I hold little hope in the near term.
  - meowmeowwoof 3y ago
    agree with testing and licensing (and unionizing) but is there any particular reason people should have to go to school? one of the great things about the software industry is that anyone can teach themselves and make a healthy career out of it - would be a shame to add what might be an unnecessary gatekeeping requirement to one of the last few accessible career-paths with upward class mobility
    - potta_coffee 3y ago
      The sad and ironic part is that additional gatekeeping won't produce better results anyway.
      - intrasight 3y ago
        I think the results would be better as all practitioners would be well-versed in theory and practice. And of someone pitched a very novel approach, it would get more scrutiny. Of course we should be open to new approaches - just not for the sake of it being new.
        potta_coffee 3y ago
        I don't agree because current graduates aren't necessarily well-versed in theory and practice. In fact I've worked with CS graduates that don't understand theory at all and follow the worst conceivable practice. Of course CS education isn't standardized and I'm not talk about Stanford grads here. But I have a hard time believing that simply erecting barriers that require education will improve the situation when a lot of educated people still have no idea what they're doing.
    - intrasight 3y ago
      The same question/discussion happens in the legal profession - and they have largely settled on the answer being "yes, you have to go to school" IMHO, you can't have one (testing and licensing) without the other.
  - potta_coffee 3y ago
    I've worked with plenty of educated developers who couldn't code their way out of a paper bag. One of our local universities has a shockingly bad program that's reproducing their own unique little brand of terrible bullshit. I've spent half my career fixing the messes they leave behind at various companies in the area.
nkozyra 3y ago
But it's been like this for more than a decade now. Frontend work is unglamorous to a lot of developers but part of the more academic appeal is that it's still very much in its awkward teenage phase. That makes it appealing to tinker with and try to find a "better way." That's the churn.
- intrasight 3y ago
  It's been like that for at least 3 decades - which is how long I've been doing such work. I disagree with your assessment of it being an "awkward teenage phase". The rate of churn is accelerating while nothing really new theory-wise has been added. I agree with the parent post: > disproportionately composed of young and/or new and/or self-taught developers who "discover" new paradigms constantly
  - nkozyra 3y ago
    > It's been like that for at least 3 decades I've been there since the start, too. I disagree that it's been like that for that long, though. JavaScript was an awkward add-on at first, then a barely usable tool (early vanilla), then a stopgap measure to fix browser compatibility problems (jQuery, moo tools, underscore etc) and start to flesh out some libraries. But the Angular/React phase was the first time people gravitated toward using the frontend as a proper language. Before then it was just a thing you had to deal with. So 3 decades? Nah. 2 decades of "why do we have to deal with this" and 1 decade of "ok let's make this work somehow"
    - pcthrowaway 3y ago
      > But the Angular/React phase was the first time people gravitated toward using the frontend as a proper language. Don't forget Backbone which preceded Angular by checks 7 days.
    - intrasight 3y ago
      36 years at least. I'm not talking about WWW. HTML and JS were never meant to be the end-all of human computer interaction, but yet here we are. I imagine an alternative history where good distributed software got traction.
draw_down 3y ago
[dead]
SamBam 3y ago
That's what made me so confused about the framing of the article, because it seemed like it was going to go the other way. > Things you forgot because of React Ah, this is going to be a back-to-basics, here's how great vanilla JS, HTML and CSS can be. > I used to only listen to new music, updating my tastes with each week, and was never really satisfied. Then I discovered that there were certain genres that didn't update each week, and were timeless and satisfying. Ok, this is definitely a back-to-basics, don't jump on the flavor-of-the-week > React is old news now, here are a dozen new flavors of the week. Wait, what..?
- horsawlarway 3y ago
  I was laughing at the line that hooks are as old as his kid (as if this made them ancient) followed immediately by the comment that his kid is going into pre-k. His kid is... drumroll... 4 years old.
  - fsloth 3y ago
    That's a really curious perception of time. I consider everything as old as my kids spanking new. My oldest is 16. I wonder what causes this (except me being old, but still, I thought this even when my oldest 4 as well).
    - travisjungroth 3y ago
      People should kick off a bunch of things on when their child is born to remember timescales are relative. Buy a green banana. Buy a certificate of deposit. Plant tomatoes. Cellar a bottle of wine. Plant a redwood tree.
      - joelfried 3y ago
        I made a wine kit for each of my children - it makes 30 bottles and we drink one a year on the birthday itself. I've found it helps for scale and as a bonus you get to see how a wine really ages over time.
intrasight 3y ago
It's disheartening to realize that the frontend space is no better now than when I began my career in 1990. And it's also disheartening that even though computers are like 5000 times faster now, that they feel slower to me as a developer and as an end user.
- nvahalik 3y ago
  Wholeheartedly disagree. Advancements to CSS have made front-end way more reasonably than they were in the 90s. Stuff that took weeks to figure out with tables can now be done so quickly with `display: flex` and the whole grid system. It's beautiful. If we had `display: flex back` in 1998 I probably wouldn't have stuck with FE rather than dive into the backend.
  - mablopoule 3y ago
    Agree. I did CSS before flexbox was available, and I have no ideas how I did before. There is tons of very good stuff coming our way in CSS (such as container queries), better ergonomics for Javascript, excellent tooling in the browser, stuff to be optimistic for, not just all this madness about the framework du jour.
  - wongarsu 3y ago
    Web dev (as in: HTML and CSS) improved a lot in the last 20-30 years. But if I had to quickly make a fully functioning interface and had the choice between today's web and 2002's Delphi 7 I'd choose Delphi 7 in a heartbeat. And just look at what non-technial people were able to do with Macromedia Flash in the early 2000s. You need experienced frontend devs to recreate what designers did as a hobby back then. Of course those solutions don't solve the transition between desktop and mobile layout (since that wasn't a thing back then), but more some modern frameworks solve that well (like whatever MS calls UWP right now) without forcing everyone to reinvent a way to do infinite scrolling without running out of memory
    - phist_mcgee 3y ago
      This reads as if written by someone with rose tinted glasses.
pohl 3y ago
Well put. On the other hand, I pray that the industry doesn’t ossify right now around Facebook’s dominant framework. Sweet Jesus, anyone but Facebook.
- pc86 3y ago
  It's open source, who cares who the originator is?
  - whs 3y ago
    Tell that to people who're moving from the open source CentOS project.
dan-robertson 3y ago
That’s something people have said for a while but I’m pretty sure React was the main thing people were moving towards 5 years ago and I think, for the most part, people are still using react. That doesn’t sound like constant churn or people switching frameworks all the time (caveat 1: react has changed from eg classes to functional components and hooks; caveat 2: maybe front end is broken into groups and one picked up react 5 years ago for two years, another picked it up four years ago switching away after two years, and so on, and I’m just combining them all as ‘used react for five years’ in my head). I feel like the churn has gone down over time. But maybe that is also a decrease in my personal interest in front end as well as posts here (I recall there used to be a lot more frontend related posts here ~10 years ago)
- arcbyte 3y ago
  5 years ago I was the lead architect on a v2 rewrite project of about 30% of our app. We considered React but the landscape was also full of Angular and Vue and a bunch of others I don't remember. At the end of the day, we went with the latest version of our boring server side rendering library that the rest of the app used. A huge reason was the churn in front-end javascript libraries. I've never once regretted that decision and the project was a big success.
  - fsloth 3y ago
    "we went with the latest version of our boring server side rendering library that the rest of the app used." Boring tools are the best thing ever. What did you use?
    - arcbyte 3y ago
      We went from JSF1 something to JSF2 something. Very boring but there was so much technology change already in this rewrite that we chose to limit the amount of new stuff for everyone to learn especially when we didnt know if it would be applicable to anything in their future career.
      - 3y ago
sgallant 3y ago
This comment smells like gate keeping to me: "developers who work with frontend tech aren't REAL developers". Personally, I know many developers who are doing great work with frontend technologies. Some with little experience, some with decades of experience, some self taught, and some with formal CS degrees. Frontend is a great career path for those who enjoy it.
- pc86 3y ago
  I'm not sure where you read "developers who work with frontend tech aren't REAL developers" but it wasn't the comment you're replying to.
  - john-radio 3y ago
    I mean, he did literally liken them to insects though...
- dep_b 3y ago
  ...as long as the given front-end is done with a sane language using sane frameworks like Windows / Mac / Linux or iOS / Android.
  - pc86 3y ago
    None of those are frameworks.
    - dep_b 3y ago
      They all come with a good set of standard frameworks? Web ships with barely anything and when it does have something like Date handling people still write replacements for it because it's so bad.
coldtrait 3y ago
This is me. But the reason for this being the space is inundated with front-end frameworks - like there's a new one out every week. The nature of the industry is that you have to be up to date with everything. Like I had worked on Angular at one point but recently had to work on an older version and I couldn't figure it out easily. React was decent but now there's NextJs and Svelte etc.
- squidsoup 3y ago
  NextJs is still react.
Jeema101 3y ago
Maybe it's just because I'm old and grumpy and have seen lots of things come and go, but I don't understand how some frontend devs even have this much time to obsess over their tools. It would be like car guys spending more time arguing about whether Snap-on is better than Craftsman than actually talking about and working on cars.
- text0404 3y ago
  > but I don't understand how some frontend devs even have this much time to obsess over their tools. most of us don't. these comments are mostly from people whose idea of "web development" is a form and some static content.
- actionfromafar 3y ago
  Have you met car guys? :)
- paulgerhardt 3y ago
  Snap-on and Craftsman are actually pretty antiquated tools by modern car guy standards. If you want a real wrench you go with a Mac RBRT - it’s the new hotness in combo wrenches but there are decent alternatives out there from Wright and Proto. Here’s a great video showing things you might have missed if you’ve been in Craftsman world for a while[1]. [1] https://youtu.be/hxtgWSpTC0o https://youtu.be/hxtgWSpTC0o
  - antran22 3y ago
    I have absolutely no knowledge in mechanical engineering before and I am now really in a youtube-binge about wrench. Not sure it is a good thing that I can get captivated by absolute random topic or a bad thing because how technology just suck up our attention.
- hinkley 3y ago
  Have you seen r/tools? I thought the SnapOn koolaid was stale fifteen years ago. Turns out no.
hinkley 3y ago
When I was starting out in the industry, I wasn’t even a programmer yet when a lead developer sat me down and taught me about the pendulum swing. At the time it was closer to six years to two decades. It’s clearly gotten faster in the era of Stack Overflow, but if you’re seeing six months to two years, that’s ridiculous (you’re not, the situation is). That conversation accelerated the first ten years of my career by making me more effective. I knew people who made it farther with less work than I did, but mostly I knew the reverse. So I in turn have talked about the pendulum swing with more people than any other topic. In the Expanse, Amos talks about The Churn, which is a related phenomenon. “When the jungle tears itself down and builds itself into something new. Guys like you and me, we end up dead. Doesn’t really mean anything. Or, if we happen to live through it, well that doesn’t mean anything either.” If you come through chaos unscathed it doesn't mean you were good. It just means you were lucky. Don’t let it go to your head. The motivation of people with 3 years of experience is to jump on a bandwagon that mutes the effectiveness of having 15 years’ worth of experience. You’re dragging half of the industry down in order to pull yourself up. That’s defecting, and we all know how that turns out.
- ttfkam 3y ago
  I've been doing web development since 1996. I've witnessed the ebbs and flows and hype trains. Svelte's the real deal. How do I know? Because it's not a new API or paradigm. It's the old web just better. It encourages HTML and sane CSS, not just wrapping them in endless boilerplate. It compiles to efficient code rather than making you write all of it over and over again. It takes all the lessons from the last decade and a half and distills them into familiar web development patterns. <script> <style> all your HTML + bare minimum of logic to solve your problems I haven't been this excited about a new web technology in a decade, so coming from an old school web dev who learned off of view source in 1996, take that into consideration. And while I prefer Svelte, Htmx is doing a lot of the same work; not new APIs; just embracing old ones without all the boilerplate.
  - text0404 3y ago
    i too have been developing since 1996. and in 1996, nobody was making web-based applications with anywhere near a fraction of the complexity that modern web apps manage. please build spotify using only HTML and JS language features from 1996.
ttfkam 3y ago
tl;dr: I love web development again. You obviously haven't tried Svelte yet. I would have agreed with you a few years ago though. The churn as I've seen it has been a direct result of React's ecosystem, not in spite of it. Here's a partial list of React libraries that just provide state management: MobX Recoil Redux Akita Context Hookstate Zustand Jotai Just for state management! And all exist solely because React state management is a monumental fustercluck. Then you get into React API nightmares the article mentioned that have nothing to do with HTML, CSS, and JS but have everything to do with React's API quagmire. You may scoff at pointing to Svelte as "just a new shiny", but it really is getting back to the web's roots. Htmx as well. I've been doing web development professionally since 1996. I have hated web development since soon after React was introduced. React solved a lot of big problems to be sure, but it introduced its fair share as well as made web development tedious in a way I hadn't experienced before. I wasn't developing for the web anymore; I was developing for React. I constantly felt detached from my actual target. Wrapper after wrapper of familiar vanilla libraries to shoehorn into the React ecosystem rather than living alongside it. Svelte (and Htmx to a lesser extent) gave me back plain ole HTML & CSS. Svelte also gave back that simple JS that described the problem I was trying to solve instead of endless boilerplate on an API layer on top of the browser API. Vue got close but didn't go far enough. SolidJS just made a faster React. Svelte and Htmx embraced the web with no holding back, and I love them for it.
- text0404 3y ago
  so you'd prefer that there was only one state management solution for every webapp? what if i don't need 99% of the features of this monolith library?
  - ttfkam 3y ago
    Seriously, try Svelte. See how its Stores API works. For bonus points, look at the Context API. Between Stores, Context, and what looks like plain ole JS in the component, state management is a solved problem. With all due respect, calling it a "monolith" out of hand just screams you haven't even looked at solutions and don't know what you're talking about. SolidJS stores work the same. In other words, this is basically a solved problem unless you live in the React ecosystem.
begueradj 3y ago
Could you please elaborate on this statement: "The developer community being disproportionately composed of young developers" ?
- hajile 3y ago
  That's simple enough. Look at StackOverflow's survey (or any other) over 50% of professional devs have less than 10 years of experience. That's 2013 or the year React came out and a full 5 years after the launch of Chrome/v8 started the next round of the framework wars. On the frontend, things are even worse. Salaries started to skyrocket 7-8 years ago and the number of people suddenly interested has skyrocket every year for the past 5-6 years.
  - tacker2000 3y ago
    Yea i also noticed recently that survey is actually really skewed in that directio. And as such shouldn’t really be used as basis for any “state of the developer landscape”
  - ARandomerDude 3y ago
    > Look at StackOverflow's survey Part of the problem with this methodology is SO is useful among the most junior devs. For example, I haven't been to SO in several years but it was my go-to site in 2010.
    - hajile 3y ago
      The very large State of JS survey skews to even less experience overall with nearly 30% having less than 5 years of experience and a bit over 50% having less than 10 years of experience. https://2021.stateofjs.com/en-US/demographics/ https://2021.stateofjs.com/en-US/demographics/
- mellosouls 3y ago
  You've misquoted, but I think the intent was clear; (commercial) front-end is more likely to get less experienced developers as the entry requirements are slacker at the lower end. This lack of experience carries with it the same flaws and risks (and occasional benefits) that inexperience carries everywhere.
danparsonson 3y ago
> ...Server-side rendering isn’t special anymore.. quietly dries tears using pages ripped from ASP.NET For Dummies
hajile 3y ago
This article seems completely filled with nonsense. After YEARS and THOUSANDS of projects proving that 2-way binding causes massive problems, the author insists I shouldn't believe my lying eyes. This may sucker devs with only a handful of years writing frontend code, but any dev who lived through those years won't be buying what is being sold. "Hooks are outdated" is also false. I used Knockout and signals YEARS before React. Signals are NOT better. At a large scale, they are fragile and nearly impossible to debug because EVERYTHING in your entire app is a moving/mutating target. Just because they "aren't afraid" doesn't mean they aren't coding horrible bugs everywhere that will come home to roost from seemingly unrelated code changes in another part of the app. The author claims that you can port libraries between other frameworks easily. This is absolutely false. The only "portable" solutions are going completely headless then making wrappers for various frameworks and if you do this, then React is no different than any other framework. Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific) isn't a dig at the framework so much as an indictment of the author. Benchmarks are another interesting area. The actual delta between React and other systems isn't as massive as some seem to believe. More importantly, React's ability to defer rendering of some elements gives it the potential to feel faster to the user (which is the important metric). I find the React is "hard to learn" claim fascinating. When I used AngularJS, it took 1-2 MONTHS to write basic stuff. Becoming an expert required 6 months to a year as you slowly learned the entire AngularJS codebase debugging stuff like the digest cycle. I taught a LOT of people to code React. 1-2 days to learn those basics and 1-2 weeks to know everything. The core React API has grown, but it's still not very complicated. Other frameworks may be quicker to learn, but in my experience, the difference is not huge upfront and there are almost always weird edge cases that haven't been documented that you'll run into (and that's without the signals edge cases).
- dragonwriter 3y ago
  > Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific) isn't a dig at the framework so much as an indictment of the author. Yeah, it is fairly obvious (though, to be fair, it wouldn't hurt to point it out) that: useCallback((...args) => { <*statements*> }, [<*deplist*>] ); is effectively identical to: useMemo(() => (...args) => { <*statements*> }, [<*deplist*>]);
toddmorey 3y ago
What a grumpy comment. - Two of the best developers I know are completely self-taught. - I'd argue there have been so many front-end frameworks not for the sake of novelty because the web platform itself was incomplete and stagnated. (And also blew a huge opportunity with the APIs for web components.) - Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved. - Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem. - Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend.
- zer8k 3y ago
  > Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved. A language so good you need to write another language that compiles into that language to make it tolerable. > Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem. I'm not sure about this opinion. Most websites are slow as all get out and require me to download the world to even get working. > Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend. As a person on the backend I can tell you your definition of "overengineering" is ignoring the fact we have to deal with frontend cowboys all the time. When SEVs happen it's us on trial almost universally. Just the absolutely bonkers states a frontend can accidentally end up in despite good testing is enough to warrant "overengineering" to try to support it. We had an opportunity to kill javascript and instead we embraced it. We deserve what we get.
  - claytongulick 3y ago
    > A language so good you need to write another language that compiles into that language to make it tolerable If static typing is your thing, I guess. It's not for everyone. > We had an opportunity to kill javascript and instead we embraced it. We deserve what we get. Some of us quite enjoy the language.
antran22 3y ago
> everything is repeated every six months to two years Same feeling looking at the new Vercel SQL library. Oh wow now you can write SQL right next to your client-facing code, such convenient. You have just rediscovered PHP. To be fair, frontend frameworks solve a problem. Application can get too big that you cannot manage all the states imperatively. Declarative UI building really help to keep the UI separated from the logic. But then management get greedy and and try to shove all the features they can think of into one single big app. Like, if you went to a page and click a button, going to another page will let you know that you clicked that button and shows up some nice CTA so you won't forget. Frontend people scramble around trying to create new abstraction to keep their working surface manageable. Then you get workflows where to get the result of an API call you have to dispatch a thunk action so it would update in the global store (my example may be antiquated, I'm away from React & Redux for a little while), instead of just, you know, call it and `.then()` update the UI. Maybe if you have an app that is twice bigger than a normal app, maybe, I don't know, split it into two apps instead? The problem of web development app right now, I think, is because people are being monolithic where it should be independently modular, and then try to cut up your backend service into pieces when a single monolith works fine.
- robertoandred 3y ago
  PHP can't run in the browser.
  - sethrin 3y ago
    I'd say don't give anyone bad ideas, but we are too late: https://github.com/oraoto/pib https://github.com/oraoto/pib
    - antran22 3y ago
      Sorry friend, WordPress already beat you to it: https://github.com/WordPress/wordpress-playground https://github.com/WordPress/wordpress-playground
  - antran22 3y ago
phendrenad2 3y ago
The thing that these young and/or inexperienced developers don't understand is: Frameworks are not your friend. Framework projects are not created with your benefit in mind. Frameworks are created as an opening salvo so that some developers or organization can gain a foothold in the landscape and start collecting money from consulting contracts. The reason there are 1,000 React alternatives is not "people like signals more than hooks", the real root cause is 1,000 people want to steal market share from React so they can get paid as a consultant. "I like signals more than hooks" folks are just useful, predictable pieces of the landscape to be manipulated in this scheme.
- unsupp0rted 3y ago
  Frameworks are your friend; either the one everybody used or the one you invariably end up writing from scratch for yourself for every project.
  - phendrenad2 3y ago
    Indeed, a framework written to be used for a project has a limited amount of time where it's your friend. Until the big 2.0 rewrite comes out and they changed the API completely, and the clock starts counting down to the rapidly approaching 3.0 release where they will rewrite the API, before two weeks later announcing 4.0 alpha 1...
tootie 3y ago
I remember when CSS was brand new. When IE5 had the first DOM. When jQuery took over the world. That's all like 20 years of time.
wouldbecouldbe 3y ago
Those developers are immature. JS was always here to stay. Wether you like it or not. Come with solutions instead of leaving it to someone else, or worse complaining. JS was always super exciting, with a few lines you could build entire applications.
- tuukkah 3y ago
  It's not so much about JS somehow being a language like no other, it's more about the web: HTTP, HTML, DOM. And XHR/fetch - JS wasn't exciting before them.
steve76 3y ago
[dead]
mrbombastic 3y ago
I agree with you and think the eternal september effect is probably the largest factor working against advances in frontend dev but would posit a couple more: 1) front end dev is generally underestimated and under respected in terms of complexity, I have had many devs say “you are basically just building a json viewer” over the years which is somewhat true but a great oversimplification 2) the closer you are to the user the more ephemeral and hard to reuse your components are, and business incentives work more strongly against reuse because the higher ups can actually see the work that is being shared.
- thex10 3y ago
  > business incentives work more strongly against reuse because the higher ups can actually see the work that is being shared Can you talk more about this one? I think this is getting at something I've seen but have been unable to articulate thus far.

BSEdlMMldESB 3y ago

I see this as a problem to be solved in the software-education space

intrasight 3y ago
It totally could be solved. Make it a licensed profession. Make it like the legal practice where you have to go to school for 3 years and then pass a test to get your license. Only half joking.
- getpokedagain 3y ago
  I think left to our own engineers would have resolved to something like this already. The issue as I see it is corporations and business people have taken over the leadership of this trade to rake in money regardless of what it does to the real world. And why wouldn't they you can create a problem out of thin air, solve the problem poorly selling the solution, and then when your rushed, half assed and bad solution has issues, you can simply sell the fix to that as well. I doubt we will see much progress in the quality and rigor of software engineering in the near term, it will need to take a shift from making money in the short term at any cost to making a quality product. Instead we see the same thing happening to other industries so I hold little hope in the near term.
- meowmeowwoof 3y ago
  agree with testing and licensing (and unionizing) but is there any particular reason people should have to go to school? one of the great things about the software industry is that anyone can teach themselves and make a healthy career out of it - would be a shame to add what might be an unnecessary gatekeeping requirement to one of the last few accessible career-paths with upward class mobility
  - potta_coffee 3y ago
    The sad and ironic part is that additional gatekeeping won't produce better results anyway.
    - intrasight 3y ago
      I think the results would be better as all practitioners would be well-versed in theory and practice. And of someone pitched a very novel approach, it would get more scrutiny. Of course we should be open to new approaches - just not for the sake of it being new.
      - potta_coffee 3y ago
        I don't agree because current graduates aren't necessarily well-versed in theory and practice. In fact I've worked with CS graduates that don't understand theory at all and follow the worst conceivable practice. Of course CS education isn't standardized and I'm not talk about Stanford grads here. But I have a hard time believing that simply erecting barriers that require education will improve the situation when a lot of educated people still have no idea what they're doing.
  - intrasight 3y ago
    The same question/discussion happens in the legal profession - and they have largely settled on the answer being "yes, you have to go to school" IMHO, you can't have one (testing and licensing) without the other.
- potta_coffee 3y ago
  I've worked with plenty of educated developers who couldn't code their way out of a paper bag. One of our local universities has a shockingly bad program that's reproducing their own unique little brand of terrible bullshit. I've spent half my career fixing the messes they leave behind at various companies in the area.

nkozyra 3y ago

But it's been like this for more than a decade now. Frontend work is unglamorous to a lot of developers but part of the more academic appeal is that it's still very much in its awkward teenage phase. That makes it appealing to tinker with and try to find a "better way." That's the churn.

intrasight 3y ago
It's been like that for at least 3 decades - which is how long I've been doing such work. I disagree with your assessment of it being an "awkward teenage phase". The rate of churn is accelerating while nothing really new theory-wise has been added. I agree with the parent post: > disproportionately composed of young and/or new and/or self-taught developers who "discover" new paradigms constantly
- nkozyra 3y ago
  > It's been like that for at least 3 decades I've been there since the start, too. I disagree that it's been like that for that long, though. JavaScript was an awkward add-on at first, then a barely usable tool (early vanilla), then a stopgap measure to fix browser compatibility problems (jQuery, moo tools, underscore etc) and start to flesh out some libraries. But the Angular/React phase was the first time people gravitated toward using the frontend as a proper language. Before then it was just a thing you had to deal with. So 3 decades? Nah. 2 decades of "why do we have to deal with this" and 1 decade of "ok let's make this work somehow"
  - pcthrowaway 3y ago
    > But the Angular/React phase was the first time people gravitated toward using the frontend as a proper language. Don't forget Backbone which preceded Angular by checks 7 days.
  - intrasight 3y ago
    36 years at least. I'm not talking about WWW. HTML and JS were never meant to be the end-all of human computer interaction, but yet here we are. I imagine an alternative history where good distributed software got traction.

draw_down 3y ago

[dead]

SamBam 3y ago

That's what made me so confused about the framing of the article, because it seemed like it was going to go the other way. > Things you forgot because of React Ah, this is going to be a back-to-basics, here's how great vanilla JS, HTML and CSS can be. > I used to only listen to new music, updating my tastes with each week, and was never really satisfied. Then I discovered that there were certain genres that didn't update each week, and were timeless and satisfying. Ok, this is definitely a back-to-basics, don't jump on the flavor-of-the-week > React is old news now, here are a dozen new flavors of the week. Wait, what..?

horsawlarway 3y ago
I was laughing at the line that hooks are as old as his kid (as if this made them ancient) followed immediately by the comment that his kid is going into pre-k. His kid is... drumroll... 4 years old.
- fsloth 3y ago
  That's a really curious perception of time. I consider everything as old as my kids spanking new. My oldest is 16. I wonder what causes this (except me being old, but still, I thought this even when my oldest 4 as well).
  - travisjungroth 3y ago
    People should kick off a bunch of things on when their child is born to remember timescales are relative. Buy a green banana. Buy a certificate of deposit. Plant tomatoes. Cellar a bottle of wine. Plant a redwood tree.
    - joelfried 3y ago
      I made a wine kit for each of my children - it makes 30 bottles and we drink one a year on the birthday itself. I've found it helps for scale and as a bonus you get to see how a wine really ages over time.

intrasight 3y ago

It's disheartening to realize that the frontend space is no better now than when I began my career in 1990. And it's also disheartening that even though computers are like 5000 times faster now, that they feel slower to me as a developer and as an end user.

nvahalik 3y ago
Wholeheartedly disagree. Advancements to CSS have made front-end way more reasonably than they were in the 90s. Stuff that took weeks to figure out with tables can now be done so quickly with `display: flex` and the whole grid system. It's beautiful. If we had `display: flex back` in 1998 I probably wouldn't have stuck with FE rather than dive into the backend.
- mablopoule 3y ago
  Agree. I did CSS before flexbox was available, and I have no ideas how I did before. There is tons of very good stuff coming our way in CSS (such as container queries), better ergonomics for Javascript, excellent tooling in the browser, stuff to be optimistic for, not just all this madness about the framework du jour.
- wongarsu 3y ago
  Web dev (as in: HTML and CSS) improved a lot in the last 20-30 years. But if I had to quickly make a fully functioning interface and had the choice between today's web and 2002's Delphi 7 I'd choose Delphi 7 in a heartbeat. And just look at what non-technial people were able to do with Macromedia Flash in the early 2000s. You need experienced frontend devs to recreate what designers did as a hobby back then. Of course those solutions don't solve the transition between desktop and mobile layout (since that wasn't a thing back then), but more some modern frameworks solve that well (like whatever MS calls UWP right now) without forcing everyone to reinvent a way to do infinite scrolling without running out of memory
  - phist_mcgee 3y ago
    This reads as if written by someone with rose tinted glasses.

pohl 3y ago

Well put. On the other hand, I pray that the industry doesn’t ossify right now around Facebook’s dominant framework. Sweet Jesus, anyone but Facebook.

pc86 3y ago
It's open source, who cares who the originator is?
- whs 3y ago
  Tell that to people who're moving from the open source CentOS project.

dan-robertson 3y ago

That’s something people have said for a while but I’m pretty sure React was the main thing people were moving towards 5 years ago and I think, for the most part, people are still using react. That doesn’t sound like constant churn or people switching frameworks all the time (caveat 1: react has changed from eg classes to functional components and hooks; caveat 2: maybe front end is broken into groups and one picked up react 5 years ago for two years, another picked it up four years ago switching away after two years, and so on, and I’m just combining them all as ‘used react for five years’ in my head). I feel like the churn has gone down over time. But maybe that is also a decrease in my personal interest in front end as well as posts here (I recall there used to be a lot more frontend related posts here ~10 years ago)

arcbyte 3y ago
5 years ago I was the lead architect on a v2 rewrite project of about 30% of our app. We considered React but the landscape was also full of Angular and Vue and a bunch of others I don't remember. At the end of the day, we went with the latest version of our boring server side rendering library that the rest of the app used. A huge reason was the churn in front-end javascript libraries. I've never once regretted that decision and the project was a big success.
- fsloth 3y ago
  "we went with the latest version of our boring server side rendering library that the rest of the app used." Boring tools are the best thing ever. What did you use?
  - arcbyte 3y ago
    We went from JSF1 something to JSF2 something. Very boring but there was so much technology change already in this rewrite that we chose to limit the amount of new stuff for everyone to learn especially when we didnt know if it would be applicable to anything in their future career.
    - 3y ago

sgallant 3y ago

This comment smells like gate keeping to me: "developers who work with frontend tech aren't REAL developers". Personally, I know many developers who are doing great work with frontend technologies. Some with little experience, some with decades of experience, some self taught, and some with formal CS degrees. Frontend is a great career path for those who enjoy it.

pc86 3y ago
I'm not sure where you read "developers who work with frontend tech aren't REAL developers" but it wasn't the comment you're replying to.
- john-radio 3y ago
  I mean, he did literally liken them to insects though...
dep_b 3y ago
...as long as the given front-end is done with a sane language using sane frameworks like Windows / Mac / Linux or iOS / Android.
- pc86 3y ago
  None of those are frameworks.
  - dep_b 3y ago
    They all come with a good set of standard frameworks? Web ships with barely anything and when it does have something like Date handling people still write replacements for it because it's so bad.

coldtrait 3y ago

This is me. But the reason for this being the space is inundated with front-end frameworks - like there's a new one out every week. The nature of the industry is that you have to be up to date with everything. Like I had worked on Angular at one point but recently had to work on an older version and I couldn't figure it out easily. React was decent but now there's NextJs and Svelte etc.

squidsoup 3y ago
NextJs is still react.

Jeema101 3y ago

Maybe it's just because I'm old and grumpy and have seen lots of things come and go, but I don't understand how some frontend devs even have this much time to obsess over their tools. It would be like car guys spending more time arguing about whether Snap-on is better than Craftsman than actually talking about and working on cars.

text0404 3y ago
> but I don't understand how some frontend devs even have this much time to obsess over their tools. most of us don't. these comments are mostly from people whose idea of "web development" is a form and some static content.
actionfromafar 3y ago
Have you met car guys? :)
paulgerhardt 3y ago
Snap-on and Craftsman are actually pretty antiquated tools by modern car guy standards. If you want a real wrench you go with a Mac RBRT - it’s the new hotness in combo wrenches but there are decent alternatives out there from Wright and Proto. Here’s a great video showing things you might have missed if you’ve been in Craftsman world for a while[1]. [1] https://youtu.be/hxtgWSpTC0o https://youtu.be/hxtgWSpTC0o
- antran22 3y ago
  I have absolutely no knowledge in mechanical engineering before and I am now really in a youtube-binge about wrench. Not sure it is a good thing that I can get captivated by absolute random topic or a bad thing because how technology just suck up our attention.
hinkley 3y ago
Have you seen r/tools? I thought the SnapOn koolaid was stale fifteen years ago. Turns out no.

hinkley 3y ago

When I was starting out in the industry, I wasn’t even a programmer yet when a lead developer sat me down and taught me about the pendulum swing. At the time it was closer to six years to two decades. It’s clearly gotten faster in the era of Stack Overflow, but if you’re seeing six months to two years, that’s ridiculous (you’re not, the situation is). That conversation accelerated the first ten years of my career by making me more effective. I knew people who made it farther with less work than I did, but mostly I knew the reverse. So I in turn have talked about the pendulum swing with more people than any other topic. In the Expanse, Amos talks about The Churn, which is a related phenomenon. “When the jungle tears itself down and builds itself into something new. Guys like you and me, we end up dead. Doesn’t really mean anything. Or, if we happen to live through it, well that doesn’t mean anything either.” If you come through chaos unscathed it doesn't mean you were good. It just means you were lucky. Don’t let it go to your head. The motivation of people with 3 years of experience is to jump on a bandwagon that mutes the effectiveness of having 15 years’ worth of experience. You’re dragging half of the industry down in order to pull yourself up. That’s defecting, and we all know how that turns out.

ttfkam 3y ago
I've been doing web development since 1996. I've witnessed the ebbs and flows and hype trains. Svelte's the real deal. How do I know? Because it's not a new API or paradigm. It's the old web just better. It encourages HTML and sane CSS, not just wrapping them in endless boilerplate. It compiles to efficient code rather than making you write all of it over and over again. It takes all the lessons from the last decade and a half and distills them into familiar web development patterns. <script> <style> all your HTML + bare minimum of logic to solve your problems I haven't been this excited about a new web technology in a decade, so coming from an old school web dev who learned off of view source in 1996, take that into consideration. And while I prefer Svelte, Htmx is doing a lot of the same work; not new APIs; just embracing old ones without all the boilerplate.
- text0404 3y ago
  i too have been developing since 1996. and in 1996, nobody was making web-based applications with anywhere near a fraction of the complexity that modern web apps manage. please build spotify using only HTML and JS language features from 1996.

ttfkam 3y ago

tl;dr: I love web development again. You obviously haven't tried Svelte yet. I would have agreed with you a few years ago though. The churn as I've seen it has been a direct result of React's ecosystem, not in spite of it. Here's a partial list of React libraries that just provide state management: MobX Recoil Redux Akita Context Hookstate Zustand Jotai Just for state management! And all exist solely because React state management is a monumental fustercluck. Then you get into React API nightmares the article mentioned that have nothing to do with HTML, CSS, and JS but have everything to do with React's API quagmire. You may scoff at pointing to Svelte as "just a new shiny", but it really is getting back to the web's roots. Htmx as well. I've been doing web development professionally since 1996. I have hated web development since soon after React was introduced. React solved a lot of big problems to be sure, but it introduced its fair share as well as made web development tedious in a way I hadn't experienced before. I wasn't developing for the web anymore; I was developing for React. I constantly felt detached from my actual target. Wrapper after wrapper of familiar vanilla libraries to shoehorn into the React ecosystem rather than living alongside it. Svelte (and Htmx to a lesser extent) gave me back plain ole HTML & CSS. Svelte also gave back that simple JS that described the problem I was trying to solve instead of endless boilerplate on an API layer on top of the browser API. Vue got close but didn't go far enough. SolidJS just made a faster React. Svelte and Htmx embraced the web with no holding back, and I love them for it.

text0404 3y ago
so you'd prefer that there was only one state management solution for every webapp? what if i don't need 99% of the features of this monolith library?
- ttfkam 3y ago
  Seriously, try Svelte. See how its Stores API works. For bonus points, look at the Context API. Between Stores, Context, and what looks like plain ole JS in the component, state management is a solved problem. With all due respect, calling it a "monolith" out of hand just screams you haven't even looked at solutions and don't know what you're talking about. SolidJS stores work the same. In other words, this is basically a solved problem unless you live in the React ecosystem.

begueradj 3y ago

Could you please elaborate on this statement: "The developer community being disproportionately composed of young developers" ?

hajile 3y ago
That's simple enough. Look at StackOverflow's survey (or any other) over 50% of professional devs have less than 10 years of experience. That's 2013 or the year React came out and a full 5 years after the launch of Chrome/v8 started the next round of the framework wars. On the frontend, things are even worse. Salaries started to skyrocket 7-8 years ago and the number of people suddenly interested has skyrocket every year for the past 5-6 years.
- tacker2000 3y ago
  Yea i also noticed recently that survey is actually really skewed in that directio. And as such shouldn’t really be used as basis for any “state of the developer landscape”
- ARandomerDude 3y ago
  > Look at StackOverflow's survey Part of the problem with this methodology is SO is useful among the most junior devs. For example, I haven't been to SO in several years but it was my go-to site in 2010.
  - hajile 3y ago
    The very large State of JS survey skews to even less experience overall with nearly 30% having less than 5 years of experience and a bit over 50% having less than 10 years of experience. https://2021.stateofjs.com/en-US/demographics/ https://2021.stateofjs.com/en-US/demographics/
mellosouls 3y ago
You've misquoted, but I think the intent was clear; (commercial) front-end is more likely to get less experienced developers as the entry requirements are slacker at the lower end. This lack of experience carries with it the same flaws and risks (and occasional benefits) that inexperience carries everywhere.

danparsonson 3y ago

> ...Server-side rendering isn’t special anymore.. quietly dries tears using pages ripped from ASP.NET For Dummies

hajile 3y ago

This article seems completely filled with nonsense. After YEARS and THOUSANDS of projects proving that 2-way binding causes massive problems, the author insists I shouldn't believe my lying eyes. This may sucker devs with only a handful of years writing frontend code, but any dev who lived through those years won't be buying what is being sold. "Hooks are outdated" is also false. I used Knockout and signals YEARS before React. Signals are NOT better. At a large scale, they are fragile and nearly impossible to debug because EVERYTHING in your entire app is a moving/mutating target. Just because they "aren't afraid" doesn't mean they aren't coding horrible bugs everywhere that will come home to roost from seemingly unrelated code changes in another part of the app. The author claims that you can port libraries between other frameworks easily. This is absolutely false. The only "portable" solutions are going completely headless then making wrappers for various frameworks and if you do this, then React is no different than any other framework. Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific) isn't a dig at the framework so much as an indictment of the author. Benchmarks are another interesting area. The actual delta between React and other systems isn't as massive as some seem to believe. More importantly, React's ability to defer rendering of some elements gives it the potential to feel faster to the user (which is the important metric). I find the React is "hard to learn" claim fascinating. When I used AngularJS, it took 1-2 MONTHS to write basic stuff. Becoming an expert required 6 months to a year as you slowly learned the entire AngularJS codebase debugging stuff like the digest cycle. I taught a LOT of people to code React. 1-2 days to learn those basics and 1-2 weeks to know everything. The core React API has grown, but it's still not very complicated. Other frameworks may be quicker to learn, but in my experience, the difference is not huge upfront and there are almost always weird edge cases that haven't been documented that you'll run into (and that's without the signals edge cases).

dragonwriter 3y ago
> Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific) isn't a dig at the framework so much as an indictment of the author. Yeah, it is fairly obvious (though, to be fair, it wouldn't hurt to point it out) that: useCallback((...args) => { <*statements*> }, [<*deplist*>] ); is effectively identical to: useMemo(() => (...args) => { <*statements*> }, [<*deplist*>]);

toddmorey 3y ago

What a grumpy comment. - Two of the best developers I know are completely self-taught. - I'd argue there have been so many front-end frameworks not for the sake of novelty because the web platform itself was incomplete and stagnated. (And also blew a huge opportunity with the APIs for web components.) - Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved. - Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem. - Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend.

zer8k 3y ago
> Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved. A language so good you need to write another language that compiles into that language to make it tolerable. > Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem. I'm not sure about this opinion. Most websites are slow as all get out and require me to download the world to even get working. > Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend. As a person on the backend I can tell you your definition of "overengineering" is ignoring the fact we have to deal with frontend cowboys all the time. When SEVs happen it's us on trial almost universally. Just the absolutely bonkers states a frontend can accidentally end up in despite good testing is enough to warrant "overengineering" to try to support it. We had an opportunity to kill javascript and instead we embraced it. We deserve what we get.
- claytongulick 3y ago
  > A language so good you need to write another language that compiles into that language to make it tolerable If static typing is your thing, I guess. It's not for everyone. > We had an opportunity to kill javascript and instead we embraced it. We deserve what we get. Some of us quite enjoy the language.

antran22 3y ago

> everything is repeated every six months to two years Same feeling looking at the new Vercel SQL library. Oh wow now you can write SQL right next to your client-facing code, such convenient. You have just rediscovered PHP. To be fair, frontend frameworks solve a problem. Application can get too big that you cannot manage all the states imperatively. Declarative UI building really help to keep the UI separated from the logic. But then management get greedy and and try to shove all the features they can think of into one single big app. Like, if you went to a page and click a button, going to another page will let you know that you clicked that button and shows up some nice CTA so you won't forget. Frontend people scramble around trying to create new abstraction to keep their working surface manageable. Then you get workflows where to get the result of an API call you have to dispatch a thunk action so it would update in the global store (my example may be antiquated, I'm away from React & Redux for a little while), instead of just, you know, call it and `.then()` update the UI. Maybe if you have an app that is twice bigger than a normal app, maybe, I don't know, split it into two apps instead? The problem of web development app right now, I think, is because people are being monolithic where it should be independently modular, and then try to cut up your backend service into pieces when a single monolith works fine.

robertoandred 3y ago
PHP can't run in the browser.
- sethrin 3y ago
  I'd say don't give anyone bad ideas, but we are too late: https://github.com/oraoto/pib https://github.com/oraoto/pib
  - antran22 3y ago
    Sorry friend, WordPress already beat you to it: https://github.com/WordPress/wordpress-playground https://github.com/WordPress/wordpress-playground
- antran22 3y ago

phendrenad2 3y ago

The thing that these young and/or inexperienced developers don't understand is: Frameworks are not your friend. Framework projects are not created with your benefit in mind. Frameworks are created as an opening salvo so that some developers or organization can gain a foothold in the landscape and start collecting money from consulting contracts. The reason there are 1,000 React alternatives is not "people like signals more than hooks", the real root cause is 1,000 people want to steal market share from React so they can get paid as a consultant. "I like signals more than hooks" folks are just useful, predictable pieces of the landscape to be manipulated in this scheme.

unsupp0rted 3y ago
Frameworks are your friend; either the one everybody used or the one you invariably end up writing from scratch for yourself for every project.
- phendrenad2 3y ago
  Indeed, a framework written to be used for a project has a limited amount of time where it's your friend. Until the big 2.0 rewrite comes out and they changed the API completely, and the clock starts counting down to the rapidly approaching 3.0 release where they will rewrite the API, before two weeks later announcing 4.0 alpha 1...

tootie 3y ago

I remember when CSS was brand new. When IE5 had the first DOM. When jQuery took over the world. That's all like 20 years of time.

wouldbecouldbe 3y ago

Those developers are immature. JS was always here to stay. Wether you like it or not. Come with solutions instead of leaving it to someone else, or worse complaining. JS was always super exciting, with a few lines you could build entire applications.

tuukkah 3y ago
It's not so much about JS somehow being a language like no other, it's more about the web: HTTP, HTML, DOM. And XHR/fetch - JS wasn't exciting before them.

steve76 3y ago

[dead]

mrbombastic 3y ago

I agree with you and think the eternal september effect is probably the largest factor working against advances in frontend dev but would posit a couple more: 1) front end dev is generally underestimated and under respected in terms of complexity, I have had many devs say “you are basically just building a json viewer” over the years which is somewhat true but a great oversimplification 2) the closer you are to the user the more ephemeral and hard to reuse your components are, and business incentives work more strongly against reuse because the higher ups can actually see the work that is being shared.

thex10 3y ago
> business incentives work more strongly against reuse because the higher ups can actually see the work that is being shared Can you talk more about this one? I think this is getting at something I've seen but have been unable to articulate thus far.