29 ms·

I don't want to do front-end anymore

• ironmagma 6y ago
  > I don't want to learn nor use a million different tools. As much rhetoric as there is about this being the frontend, the backend is worse. "Backend" is just defined as "anything that isn't the frontend" so the word casts a wide net. There's everything from logging and metrics to databases to pipelines and task managers to physical hardware and networking tools. That said, it's always good to have a variety of knowledge and experience. The backend is nice because it doesn't rely on visual output as much and so you can code more without context switching between the editor and the browser. And it's incredibly easy to get pigeonholed into writing frontend code only. So many companies seem to be unable to let go of the fact that you have some specialization.
  • tartoran 6y ago
    It’s not necessarily worse but it could be as tangled and bad because of other reasons. The rapid pace in the evolution of Js frameworks created a lot more problems than on the back end IMO
    • denysvitali 6y ago
      Remember that JS is used in the backend too (Node.JS / Deno). But I agree, the situation there at least is moving slowly compared to the frontend world.
  • bsder 6y ago
    > There's everything from logging and metrics to databases to pipelines and task managers to physical hardware and networking tools. Sure, but nobody in marketing is bothering you to use Javascript-framework-du-jour on the backend so they can put it on their sales slide. You can write the backend in totally boring technology and no one will ever know or care.
    • ironmagma 6y ago
      > marketing is bothering you to use Javascript-framework-du-jour on the backend so they can put it on their sales slide. I’ve worked in frontend for five years and this has never been a thing that happened. If a framework is important to your marketing, that would be because your customers have to use it to interface with your product. The same would be true if your customers had to interact with your backend; they would want an API in popular languages, trendy languages and frameworks too.
      • iSnow 6y ago
        I work in one of the big old industries and we commission web shops to build first versions of web apps that internal IT then takes over for maintenance and future iterations. We have standardized on Angular on the frontend and require providers to use it. The backend tech is less critical, it can be one of Java, JS, or Python and the important point is a JSON/REST interface with Swagger documentation.
• nicbou 6y ago
  I thought the same a few years ago, when I moved to backend development. I don't feel like the backend was that different, in terms of setting up infrastructure. In hindsight, I just didn't enjoy writing code for money. When I left my last programming job, I started programming for fun again. It wasn't a deliberate effort, but something that happened on its own. If you program for fun, you don't have to learn anything. You don't have to use webpack or SCSS if you don't want to. You don't need to write tests. "oops" is a valid commit message and "bugger off" is a valid response to stakeholders.
  • avmich 6y ago
    > "oops" is a valid commit message and "bugger off" is a valid response to stakeholders. I'm thinking about making a T-shirt with this phrase. Because it's important.
    • nowherebeen 6y ago
      I would buy
    • mathgladiator 6y ago
      me too.
    • nicbou 6y ago
      Go ahead, I hereby release it under a CC0 licence
  • mathgladiator 6y ago
    My advice to anyone that starts off loving code: focus on maximizing your revenue, minimizing your cost, and be careful with your commitments. One day you will hate working with these damn machines, and it isn't the machine but everything else. My target goal is to retire soon-ish, and I'll dick around with my own stupid programming language around board games: http://www.adama-lang.org/ http://www.adama-lang.org/ I don't intend to rally stake-holders about it. I fully expect to tinker on this for a decade without any love, and that's just fine with me. I don't intend to defend my decisions, or justify why this thing exists.
• neverbuythesun 6y ago
  I work for a company that mainly does custom enterprise intranet webapps. We mainly use PHP (7+), jQuery, jQuery UI, SSR templates and a really old orm (with custom patches). With all the shit these components usually get, it's been the most comfortable experience with web development I have ever had
  • OkGoDoIt 6y ago
    That actually sounds kind of wonderful. I’m sick of the technology treadmill.
  • spiderfarmer 6y ago
    Same here. But with Smarty templates.
• teraku 6y ago
  Is the date wrong? It says 8th Feb 2020
  • askonomm 6y ago
    It was indeed! Evidently I'm still stuck in last year. Fixed now however.
• otabdeveloper4 6y ago
  Spoiler alert: nobody does. We're only doing it for the money.
• eurasiantiger 6y ago
  This guy is stuck in 2015
  • k_sze 6y ago
    This comment hits the nail right on the head. What is wrong with web dev? Why is it perceived not ok to be "stuck in 2015"? I've never seen so much churn and turnover in any other single layer of a tech stack.
    • lecarore 6y ago
      The tech stack in front-end changes constantly because things change : new constrain (mobile), new possibilities (webrtc, WebWorkers), new expectations (people sometimes don't just want a document), new Frameworks that attempt to solve previous problems better (react), and new trends (material UI) that require not just a css change. It's not perfect, but given how much the ground shifts below your feets constantly while you maintain your web app, I don't find the experience that bad. Make an static html document if you need a document. Make backend code with a sprinkle of vanilla js if you make simple interactions. Use react if you need your app to evolve fast, do tons of things, and stay organised. That's what I do for my project, ciboulette.net . The marketing website is static and js free. The UI to pass an order is an express server, html pages with a sprinkle of js. The administration UI is react + meteorjs. And it's fine, not perfect, but I don't feel like it's too much.
    • ZephyrBlu 6y ago
      There isn't massive churn. As far as I can see, most of the JS ecosystem has been continually improving. React has been around since 2013 [0], Webpack has been around since 2014 [1], etc. If you're stuck in 2015, you're 5 years of updates and improvements behind. The author, by his own account, does not want to keep up with the evolution of the ecosystem: "I suppose with the increase of complexity in what we want to achieve on the web the stack to achieve it with has had to also increase in complexity. For me, personally, it's too much". [0] https://en.wikipedia.org/wiki/React_(JavaScript_library) https://en.wikipedia.org/wiki/React_(JavaScript_library) [1] https://en.wikipedia.org/wiki/Webpack https://en.wikipedia.org/wiki/Webpack
• mouzogu 6y ago
  I'm in the same boat as OP, although a little older. I started my HTML journey around 2000 and have been working as a "front-end" since graduating in 2007. I think the complexity in front end has been driven primarily by two things: 1. business demands pushing a lot of innovation in FE. Ultimately this is a good thing but it means more complexity, nowadays i mostly write non-JS JS, that is code that needs to be compiled into "real" JS. So the scope of complexity of non JS is almost unlimited and now webassembly :) - wont be long until i'm asked to edit Rust files that compile into jS haha 2. Node JS pushing us FE guys onto the server side and CLI side of things. Suddenly we are expecting to be masters of UI dev with sense of design and UX and also coding for the server and now also writing tests!!!. - I have exactly zero interest in writing tests. --- Unfortunately 95% of jobs now at least "expect" you to be comfortable in all these areas. Ultimately we are to blame as we are the ones who are pushing the boundaries of innovation, creating new tools and libraries to make our jobs easier/more complex(?) which feeds into creating more and more unrealistic expectations from us. I am at the point now reaching my 40s looking for some other field to move into....As I don't think i can do this work much longer unless there is a trend of specialistation that will emerge soon. Edit: Also one other thing to note, a lot of the new guys entering this field in the last 5-10 years are VERY dogmatic and don't really share the principle of if it works it works. They tend to be very much opinionated on having to do things in a certain way. This is why you get a lot of people who have trouble thinking outside of a "React" box (or whatever) and don't seem to understand most of these libs are progressive and there is nothing wrong with combining different approaches to meet your needs. It's like jQuery or imperative JS is a dirty word nowadays. Or that theres nothing wrong with building a static html file with a little js and css without the need for npm packages or some generator/build process.
  • daliusd 6y ago
    I think you should answer yourself what you don't like about writing tests in FE. I personally like writing them (at least for my personal project), but I think tools are still evolving in FE testing. E.g. I have recently found out about Playwright and it is step forward compared to Puppeteer: automatic waits and codegen tool is what makes Playwright the joy to work with. I'm still looking how to improve FE testing but it is something what absolutely makes my life easier.
• dagorenouf 6y ago
  Wow, I’ve taken the exact same path. Started in 2006, learned everything I could, and lost joy gradually over the past few years. I’ve left my last front end job behind a couple years ago and launched my startup. Now front-end is just a tiny part of what I do. Good luck OP!
• atraac 6y ago
  I'm trying to learn some frontend as a backend developer(primarily .NET Core but I enjoy others like Elixir/Phoenix in my own time as well) to help other developer in our team, but no matter how many times I tried, I just can't get it. The barrier of entry is so insanely high right now, I just cannot force myself to get into it. It's not only million different tools, it also to me seems like every React codebase has a huge learning curve on its own because everyone does it differently. Not only that, but Javascript(or mostly Typescript now) is to me so unreadable when combined with parts of html sprinkled everywhere, that you really need to focus a lot just to understand what's in front of you, what it does, but I guess that part is just a matter of getting used to the language.
  • mhoad 6y ago
    I don’t know if this is even an option for you but you might want to take a look at Angular especially if you already have an OO language background on the backend. Basically everything is standardised, you are mostly just writing classes the way you would for a desktop application, the majority of what makes the web frustrating to work with is abstracted away in a series of sensible patterns and overall the tooling is really great.
    • durnygbur 6y ago
      > take a look at Angular especially if you already have an OO language background on the backend. Observables, pipes, operators, litany of custom attributes in the markup, the TS source code looks like Java. I'm literally starring now the 4th day at bunch of TS and HTML files only to duplicate a simple UI feature. Once done, writing tests for this mess. All this to create a web app which loads 5-10 seconds with 2 levels of loading spinners. I feel sorry for anyone whose job will be using the application. I actively procrastinate to delay touching it.
      • mhoad 6y ago
        I mentioned this more in my other commend on this thread but I should mention that I think the bar for when people reach for an SPA framework like Angular is probably a lot lower than is reasonable. Angular in particular is designed for enterprise style applications and that is about it. Everything you need for that doesn’t come for free in terms of complexity obviously. The other thing I mentioned elsewhere at the total other end of the spectrum was Hotwire. That is genuinely as close to 2006 web development as I can think of in terms of simplicity and is probably enough for the majority of applications up to and including an email client in the browser which is what they originally built it for.
• AndrewSChapman 6y ago
  Personally I find VueJS a joy to work with on the FE. It eschews some of the complexities that come with React and gives you a comprehensive and simple state based component rendering framework. Vue's cli tool means that you don't have to worry about installing all the dependencies, just answer the setup questions about how you like to work and it installs everything for you: Typescipt, sass, babel, eslint.. all of it installed for you. I absolutely do not yearn for the SSR template days. Sure when you're composing green field it's straight forward, but when you're coming into a complex project 3 years later, figuring out where on earth the JS is that's impacting this particular screen (or causing this particular bug) can be an absolutely nightmare. I'll be sticking with Vue and Typescript and not reverting to jQuery, thank you very much.
  • habosa 6y ago
    I agree, Vue has made me interested in frontend development for the first time since jQuery!
• trestenhortz 6y ago
  Create react app means no fucking around with build systems. And there’s zero reason to use SCSS.
  • harrygeez 6y ago
    The reasons are getting lesser, but it's still a good way to automate a few things. I'm loving the SCSS + CSS Modules combo.
• hmwhy 6y ago
  Although I can relate, I find the reasoning in the post a bit odd. For example: > Starting a new project? Make sure to write your project idea down because by the time you are finished setting up the vast boilerplate you have probably forgotten it. If it's a personal project (it doesn't sound like the author is talking about work-related projects), what's stopping the author with writing just good old HTML, CSS and JavaScript? I said I could relate because a couple of years ago I was in a similar position, but a comment on Hacker News in a thread about JavaScript fatigue says that it doesn't have to be that way (apologies, it's been too long and I was a lurker back then and don't have it bookmarked). That was a liberating moment for me and I now just do whatever it's best on a case-by-case basis.
  • afarrell 6y ago
    For me, it is the desire to write non-flakey automated tests and easily pop a debugger into them.
  • okaleniuk 6y ago
    It's even easier to go with good old JavaScript now than back in 2007 because of all the tooling. We have profilers right in the browsers now. How cool is that!
    • vbezhenar 6y ago
      Another goodie is how modern browsers support modern JavaScript. Basically everything I needed transpiler few years ago just works: const, lambdas, classes, even imports. Supporting only modern browsers when you start sounds like a good idea and if you ever need old browsers, you can always transpile to ES5 later. Also don't forget that while CSS is still lame, it got few goodies as well, like CSS variables. The only thing that I personally miss is how to set up Chrome to be a proper IDE. I know that I can edit files from the disk, it has autocomplete, but this whole UI is kind of weird. May be I just need some tutorial.
• wruza 6y ago
  Honestly SCSS is what I middleware-in first even in toy-sandbox projects. Writing CSS without humane //-commenting syntax and hierarchical definitions is so annoying. install install install Everyone is okay with installs (yarn helps with caching downloads, which npm failed to do). The hard part is configure configure configure and then deal with the fact that every few months your config gets deprecated, keys renamed, docs not in sync, and most SO answers talk about one of the older, unspecified versions.
  • wruza 6y ago
    You can finally write what is essentially just HTML and JavaScript! To be fair, it is html+js that is: hot-reloadable, so you don’t have to click here and there again and again; modular so you don’t have to write a mile long htmls with 80-column indents; you can import other’s work and reuse it; not care about missing features in a “cross-platform” “browser”; not depend on cdn latency and availability; have a proper debugger. That said, personally I don’t understand this react/redux madness. I understand how it works and how to do things in it, but the general idea misses me. It is all hand-wavy funkchyonal rhetoric with learning curves and budgets that are beyond all reason. Seems like a young religion. In defense of component frameworks, try making a proper input field that accepts “1 000 00”, formats it into “10,000.00” at focus-out without interfering with a user while they are editing it, yields 10000 into your model in real-time, and present a hint when they try to enter “qwe”, without breaking your data model with NaN. Then we’ll talk about raw html+js or jquery.
    • senko 6y ago
      > ... try making a proper input field [...]. Then we’ll talk about raw html+js or jquery. Quick Google search and 15 seconds later: http://www.decorplanit.com/plugin/ http://www.decorplanit.com/plugin/ (one of many, I picked one that closest resembled your reqs) I find your lack of faith in jQuery disturbing.
• danielstocks 6y ago
  I started out my career in a similar fashion as the author (dabbled with HTML/CSS/PHP). One reason for the growing complexity in UI tooling is that many websites we build today compared to 10 years ago are not "stupid little web pages containing youtube embeds and guest books" With that being said, many people are still building simple websites, and React/TypeScript/Webpack/Babel/CSS-in-JS/et al. probably isn't solving any "real problems" for them. I've had to learn and adapt during my whole career, but I'm also more productive today than I've ever been, thanks to the tools that are available to me as a front-end developer. I still reach out for Vanilla HTML/CSS/JS now and again, but I mostly deal with large and complex UI's that need to be shared across multiple projects and hundres of developers. From a historical perpsective: jQuery solved a very real problem at it's time: simplifying and doing consistent/reliable cross browser JS development. Backbone.js later came along to solve the problem that JavaScript apps were now so large and complex that simply dropping a few JavaScript/jQuery files was not a scalable way to build. As applications became even more complex, React.js made it easier to deal with UI/state changes in large code-bases. All of these abstractions grew out of necessity.
• Tesl 6y ago
  I've been doing front-end work recently and absolutely hate it. It constantly feels like I'm developing on quicksand where I can't trust the layers below me. But I think web development has actually improved a lot. Frankly 10 years ago it was even worse. Had we chucked Javascript in the bin a decade or two ago and built something new from scratch we'd probably be better off for it.
  • sandruso 6y ago
    I think our worst enemy now is backward compatibility. I wish we could use other technologies/langs to target FE development without transpoling to js. I hope that webassembly will deliver.
• trestenhortz 6y ago
  I like javascript. It’s lightweight and very flexible. No other language has async built in at such a fundamental level. It’s incredibly easy to throw anonymous functions around. It’s destructuring is incredibly powerful. JavaScript code is concise. Recent versions such as es6 have made it better.
  • iSnow 6y ago
    I think the author would agree. They are bemoaning Typescript which is everything but lightweight and the build chain. JS for me was a very nice change from the heavyweight OOP languages but now what the usual stack implies is just as bloated and obtuse.
    • askonomm 6y ago
      I do agree indeed! It has its quirks, but all-in-all easy to use and get stuff done. Not to mention no need to set-up a compiler or anything. It just works.
    • citrons 6y ago
      Yeah the setup-project boilerplaye stuff is a mess. Luckily for backend it's super easy to set up typescript as the default are good enough for weekend projects/prototypes: ``` mkdir my-project cd my-project npm init -f npm i -D typescript ts-node @types/node npx tsc init touch index.ts npx ts-node index.ts ```
    • JoeNr76 6y ago
      This was my main reason to switch to mainly front-end: to get away from clunky, badly written C# and Java back-end programming. 2/3 of a code file are just the coder wrangling the OOP typesystem instead of just coding the functionality that is needed. I do like Typescript if you just use it minimally: you can type (I prefer interfaces usually) argument types and rely on the compiler to infer types. But then the OOP fundamentalists got their hands on it and now they want strict type checking and believe that it makes their code bulletproof https://indepth.dev/posts/1402/bulletproof-angular https://indepth.dev/posts/1402/bulletproof-angular
• deleted 6y ago
  [deleted]
• shorner 6y ago
  I think there's been a much bigger change in (particularly front end) web development over the last decade, and that's that the underlying technology is now a lot less experimental. Wind back to 2010, and websockets was new and fun, webRTC was coming up, there were loads of interesting possibilities about how the web could be used, HTML5 was new/coming, compilers (sass, gulp, etc.) were perceived as a benefit as they took away from common repetitive tasks, KnockoutJS and Ember were trying new approaches (that eventually turned into Angular/React/Vue). It felt like the possibilities were endless, and the future was ours for the taking. Now, it feels like we (as the global web community) have entered a period of stability - all of the decisions have been made. - Frameworks win (and broadly speaking, React, Angular and Vue are all very similar to use, give or take a bit). - You need to write tests, because front end applications contain more behaviour (which used to belong to the backend) - Build tools win for a host of reasons (babel allowing future JS features early, type checking, etc.). (As an aside - the logical conclusion of lots of nice build tools is... lots of nice build tools (and therefore boilerplate)) - Experimental technologies (webrtc and web sockets, among others) are "gimmicky" or "niche" - useful in small amounts - Designs are all the same (hyperbolically speaking) - want a product page? give it a horizontal three-column layout showing a free tier and two pricing options. Use Bootstrap, or roll something out that approximates it. For me, there used to be an excitement that there could be a new core frontend web technology every few months - that excitement doesn't exist now. But... that doesn't mean that it's not fun to work in web development anymore. It is the people that have changed and become more limiting, not the technology and possibilities (which have only grown over the last 20 years). And by people, I mean you (you're not 14 anymore), me, clients, managers, users - everyone. With stability come expectations!
  • visarga 6y ago
    And with expectations come new jobs, no matter how well automation delivers. Robots and software aren't gonna make us jobless because expectations will fill up and overflow any volume of possibilities.
    • shorner 6y ago
      Plus - someone's got to make those robots! Then we're into the "AI" conversation, where I think the general public think we're a lot closer to AI than we really are... Just because we have 90% reliable speech recognition and it can convert that to a basic google request, and parse some likely results, does not make Siri/Alexa/etc "intelligent".
• iSnow 6y ago
  There's a bit of hyperbole in the article, but it strikes a nerve. I originally came from Java and was so fed up with the hulking class lib and the arcane build systems sprinkled with Ant snippets and XML galore, so JS felt like a fresh breeze. AngularJS was a bit convoluted and the syntax was not nice. But OK, data binding was nice. Bit like dependency injection on the Java side made the code much harder to reason about but helped build certain classes of applications. Angular 4 was just WTF. Somewhat cleaner module system but now with a clunky OOP language instead of the elegant functional expressions that JS had and Java finally adopted. For which reason exactly? And I tried Vue which is a much lighter framework but like Angular, the build system is just retarded. Instead of many dozens of JARs with dozens of sub-dependencies, modern JS goes for the kill and literally imports several hundred of npm package with thousands of dependencies. And in the end, I end up having to use "browserify" to have JS running in a browser. It's a clowns world in IT, but modern JS really takes the cake. I'm back in backend, solving real problems instead of wrangling my build chain.
  • nickthemagicman 6y ago
    On the bright side, with native web components and web assembly gaining traction things may be looking up in the future, as a lot of these ideas get rolled into the browser natively.
    • overhero 6y ago
      yeah, web components gaining tractions since 2011...
      • himujjal 6y ago
        lol. web components are a waste of time unless someone wants to write a widget with ShadowDOM. Its clear. Svelte has won and is the last thing web can give us. Lets all go home
        • nickthemagicman 6y ago
          What's wrong with the regular DOM? Shadow DOM having better performance is a myth. Google it.
• 3np 6y ago
  Through my couple of decades as a programmer, I've gone through various specializations. Spent a good 10 years going very deep in web frontend. I moved on years ago because, like the author, it was not fun or interesting anymore. I don't feel as strongly about it as the author seems to, though. It's all part of the journey. Probably at some point, I will move on to a new technical domain than the one that's consuming my life right now, and that's fine.
• mcv 6y ago
  Fortunately a lot of these frameworks provide tools that set up your project for you. I totally agree that having to configure your own webpack from scratch is hell, and not what I signed up for, but there are tools that can help us make use of the tools we need to do our jobs. And on the backend, not everything is trivial either. Do you enjoy configuring Spring? What cloud stack do you deploy to? Or do you need a UI framework? And all the complaints I hear about npm these days, I also heard about maven 15 years ago. The only way to avoid it is to write everything yourself, and not make use of frameworks that do most of the heavy lifting for you. Write simpler applications, I guess, or at least in a simpler environment. With complexity come the tools to manage that complexity.
• enz 6y ago
  Welcome to the club, my friend. I am pretty happy with my backend/DevOps position. I hope you'll find a new job more suitable.
• archibaldJ 6y ago
  > ...The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn. If you know of a good opportunity, let me know. One advice: be careful when you make claims like this, even if you are an extremely competent programmer, because it sounded extremely aggorant. Picking up a new tech (framework, language, etc) during the job vs having years of experience building things with the tech makes a huge difference in terms of productivity. Being language(or framework)-agonostic is cool. But saying languages are very similiar indicates that you probably know none of them in depth. Every language (or framework, etc) is its own microcosmo. (i.e. at the compiler level, design-pattern's level, etc).
  • teniutza 6y ago
    I'm asking you this as I believe it will help me in the future. Is having the knowledge about the tool better that having the skills to solve a set of problems? If I really want a position within a specific company (for whatever reason) but they use a language with which I haven't worked before but am willing to learn (and definitely have the learning skills for that!), would I be in a disadvantage with respect to another candidate, one that has extensive knowledge about the language (and ecosystem), even if I would have experience in the "field of the app being built"?
    • richeyryan 6y ago
      The answer to your question is a big stonking depends. There are some skills and knowledge that are transferable across languages and ecosystems. Some companies are happy to find good talent that are willing to learn and will teach them the specifics of their language and ecosystem. Other companies are unwilling to take on people who don't have 5 years experience in their stack. I once had a company reject me outright because the majority of my experience is with React and they use Vue. Both are Javascript libraries and more similar than they are different. Sometimes the argument in those cases is they need someone who can get the work done yesterday, other times its mere tribalism. Your best bet is to build a couple of side projects with the language you're interested in and use it as proof that you've passed superficial interest and are willing to learn. After that its down to finding a company or a team that are willing to give you a shot. They are out there.
• bwindels 6y ago
  I can relate, and agree front-end frameworks and tooling feel overly complicated. The good news is that there is another way. It's completely feasible to develop without any tooling but a static web server and a browser nowadays. Just bundle for production. I've developed [1] (a +10k LoC chat app) and [2] (a small web app) using just a 600 LoC template library [3] (which I should really extract), and I vastly prefer it over more traditional setups. Being so close to the browser makes it so easy to see what is going on. I've never spent hours or days debugging the infrastructure code because there is barely any, which is usually what ruins the fun for me. Everybody is different, but for me the accidental complexity of the commonplace front-end stack (webpack, react, typescript, ...) isn't worth what you get out of it. 1: https://github.com/vector-im/hydrogen-web https://github.com/vector-im/hydrogen-web 2: https://github.com/matrix-org/matrix.to https://github.com/matrix-org/matrix.to 3: https://github.com/vector-im/hydrogen-web/blob/master/src/platform/web/ui/general/TemplateView.js https://github.com/vector-im/hydrogen-web/blob/master/src/pl...
  • j45 6y ago
    The increased brittleness of so many JS components is a real maintenance issue that can impact progress.
• mispon 6y ago
  Okay, man, u are welcome in c++ world!
• Tolexx 6y ago
  This is why I only do monolithic app development with server side rendering. I try as much as I can to avoid js. It's just way too wild.
• flucivja 6y ago
  I don't understand these kind of posts that 10 years back was frontend development easier. What is stopping people to use HTML, CSS, vanilla JS, or with jQuery these days? Nobody is forcing us to use React, TS on every project we do. Feel free to use jQuery if you think its the best tool for your project. All these technologies are just tools and you decide what tool you choose to get work done ;).
  • askonomm 6y ago
    For personal projects of course, we can do whatever we want. But I don't make a living with personal projects. I do that by working for a company 8 hours mon-fri, and there I am not in charge of the tech stack used.
    • flucivja 6y ago
      Thats true. But I guess for big project there was a reason to choose some framework. Usually with big projects without any framework you would end up with your own custom framework anyway to speed up development and it would cause onboarding new team members would be harder. But sometimes this is also necessary, look at FB, they built React because they needed it and later it was adopted by community and other companies. Its realy just about what your project needs. Btw. with backend development its same or maybe worse. There are as many languages and frameworks for backend development as stars on the sky :D.
    • qwertay 6y ago
      Good thing too because otherwise these retro hipster devs would block every new feature with the excuse "Its not possible to do that without reloading the page in raw html"
      • ryanbrunner 6y ago
        Having your site work with "raw html" pays off several times over in my opinion, even if you completely ignore people who actually turn off Javascript: - Page navigation becomes easier if you know the server can handle any route you throw at it as a launch point. - You can get by with cheaper end-to-end tests for critical flows by not using Javascript in your test suite (although you should be careful to use it when it's important) - You get a degree of protection if something does go wrong on the front end that you get a non-JS experience to fall back to. - Pages that genuinely don't need Javascript (think like simple CRUD forms) don't have to pay the SPA tax.
• codemusings 6y ago
  I feel the same fatigue. But on the other hand: looking at the boiler plate to get a web backend running I honestly don't see that much of a difference. Granted my experience is mostly limited to the Java ecosystem (specifically Spring) but just by looking at alternatives like Laravel (PHP) or Elixir (Erlang) or Django (Python) I don't see much difference when it comes to boilerplate. Developers seem to have this romantic notion that everything used to be so simple but it seems like history is just repeating itself. I'm sure programmers of the 70s and 80s said the same about desktop development in the late 90s. That being said: It's baffling to me that browser vendors can't agree on advancing the technology on their own. Why do we have to wait for the ECMA and CSS standard to evolve and instead use shims to get where we clearly want to go?
  • ethbr0 6y ago
    The first sin of computing was platform diversity: the greatest leap forward in computing was platform diversity. Ever since, we've been trying to grapple with that problem and opportunity. If browsers didn't evolve incompatibly during the early days of web scripting, much of this never would have come into being. But then we would have had to wait another couple decades for AJAX, etc. Unfortunately, I do get a sense that the younger generation looks at the polyfill complexity produced by the 90s and assumes that's the baseline by which things should be done. ... and, not to put too fine a point on it (and with deference to all the folks working in front end who know more about computer science than I ever will!), front end web development has a huge amount of developers who lack formal, in depth and breadth computer science education. Those who never learned the past, doomed to repeat it, etc.
  • Tarariro 6y ago
    Unless you were doing things like Corba or DCOM, desktop development in the 90s was a breeze compared to modern development.
• lasagna_coder 6y ago
  Tech stacks can be overwhelming, and in saying that this is what I do in 2021 and find it enjoyable: Snowpack + Typescript + ES6. I use regular CSS, just a single file. If I do something unusual with importing files or some other kind of build process thing, chances are its only a few lines to write a plugin or perhaps a few shell commands from a npm script command (or a simple script written in node) to achieve the end goal. I also use redom instead of a large framework. But also, the cool thing about TS and other front end stuff is that it's kind of fun to just find your own way. Of course, people like common practices, frameworks, etc. But also, exploring alternatives can reveal a lot about unseen potential. I hope you find something you enjoy doing, life isn't worth wasting it on stuff you don't want to do. edit: changed proverbial you to I, as I'm only referring to myself.
• gabordemooij 6y ago
  I share the opinion of the author of this article. However this resort at the end of this article might be an illusion, the backend also suffers from complexity, you have package managers there as well (Composer if you use PHP), complex frameworks like Symfony/Laravel, cumbersome ORMs and for deployments you need Docker, Kubernetes, specific cloud tools, Elastic Search. It's also very complex these days. Personally I no longer enjoy modern web development at all. There is also the hyve-mind, if you dissent you get mocked, ridiculed and you encounter all kinds of aggression. It's all very depressing. I still love to code, so I started creating my own programming language Citrine (for which I got death threats by the way) - so that project is kind of my escape where I can still do things the way I want it. To be honest I don't know what happened to web development. At a certain point in time, I had the impression the web community consisted mainly of bright, intelligent and most of all, open-minded people. Today, it looks all enterprisey and there is a lot of peer pressure, maybe even dogma to conform to the norm. So, sorry for the personal notes here, but I guess I can relate to the story of the author very much. I personally think it's time for me to close this chapter and look for another line of work, because coding in an enterprise situation is just not something I want to do with the rest of my life as well. I would like to thank the author for this article, it's good to know I am not the only one who feels this way.
• Doctor_Fegg 6y ago
  > The complicated web was here. [...] > I've given in my resignation at my current place of employment and will be seeking an exclusively back-end role for my next adventure Oh boy. I sympathise entirely with this post, but the story's exactly the same on the backend. Kubernetes. Docker. AWS and its gazillion impenetrable product names. The days of security updates, pentests, honeypots and captchas you have to go through in order to put up a webapp that won't be commandeered by (insert bad guy here) within hours. The endless cycle of breakage on your server because LetsEncrypt or whoever have upgraded their crypto libraries to fight against (insert bad guy here). The need for a lawyer to write you a privacy policy before you can let people log into your site. The endless bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. And even then it's better than dealing with email verification because Gmail/Hotmail will kill your emails anyway. The complicated web is everywhere. Retreating to the backend is no escape. Sorry.
  • sriku 6y ago
    Some of my colleagues and I were joking recently that the "AWS well architected" framework should've been named "AWS well paid" framework. It's like it's no longer legit to run a small site serving a small community. It has to "scale", be secure against minions who want to usurp your machines, have backups, CI, CD, GitHub events, run on K8sa and be "cloud native", and on and on .. to show some HTML page when an end point is hit. I feel I can't even joke about this any more here. The stacks run deep on both ends .. but I'm often not sure to what end.
    • dvfjsdhgfv 6y ago
      It's basically about money. As a tech guy, you choose the technologies with the largest margin. Companies who use AWS are either (1) rich enough to spend huge sums of money, (2) can't calculate or are gullible enough to believe it's the best solution for them. In either case, typically you're more likely to make money on AWS-related technologies than working for more cost-conscious clients who understand the cost structure of the overall infrastructure. That's why people code a Hello World as a React app on AWS, as ridiculous as it may seem.
• yuchi 6y ago
  Oh please stop. Apparently the author has always worked on their own projects, with its own (or its team’s) discipline. Let me state this: old-school front-end is a mess once you have to mantain an enterprise-grade application. npm is pure joy to work with, in comparison with a huge mess of copy-pasted files in a “vendors” directory (if you are lucky enough to have such a directory! currently I’m working on a project where developers copy-pasted the content of JS libraries one after the other in a single “lib.js” file… for years!) Front-end development has now reached a very fine situation regarding code hygene and modularity — and this makes me very happy to be on the front-end side.
  • 411111111111111 6y ago
    Yes, the grass on the other pasture is always greener. I especially found his hand-waving wrt language funny. > The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn. If thats what he thinks, then he really only experimented with very similar languages... And the quantity of strangely applied software patterns like using statemachines to hide a simple switch-case... it would be hilarious if it wasn't so sad.
    • wizzwizz4 6y ago
      The difference between MIT Scratch and FORTH is superficial; it's all just mutable LISP when you get down to it.
  • paul_f 6y ago
    Not every application needs to be "enterprise grade". Yet, many design teams seem to approach them all the same way. Stop the needless bloat!
  • chrisjs95 6y ago
    This. The quality of developers has gone down in the past 10 years and it's really hard to teach maintainable Javascript to developers. They just don't understand even delegation and how to do complex UI's in plain Javascript. Either way you wouldn't really want to because it just turns to crap. The frameworks have been great for companies.
• Havoc 6y ago
  Partially why I went into finance instead. Experience translates into seniority easier and you don’t need to sprint non stop just to stand still
• cccc4alll 6y ago
  Sounds like he’s burned out of software engineering. Moving to back end is not going to help, back end has similar issues. Micro services, reactive frameworks, package managers, etc. It’s common to burn out of software engineering. It happens to many, if not most people in software. Software is fun to get started and dabble and enjoy as hobby. However, when it turns into larger scale projects with team members, it’s harder to manage. It becomes tedious and difficult very fast. It’s ok to walk away and say software did not work out. Change careers and do something difficult. There’s more to life and career than moving bits around.
• eqvinox 6y ago
  Well, since web apps are competing with native desktop apps, they're also starting to compete on the associated complexity. Like in the 90ies when everyone had their own desktop GUI library (remember the distinctive Borland look?) and fluffernutter libraries and then it boiled down to a few major ones, the same thing is happening in the web frontend. And since there's no good distinction between "simple web stuff like actual pages" and "full-blown web apps", the tooling is the same, and the complexity bleeds into everything. …yep, no having your cake and eating it. Funnily enough, the few things that might survive the test of time and be there in 2030 or 2040 might already exist today — it might just be impossible to identify them.
  • thu2111 6y ago
    I think modern clean desktop toolkits (e.g. JavaFX, Qt) are actually a lot simpler than web development, but only if you take deployment out of the equation. If you want to iterate your app every single day, the web is good at that.
    • eqvinox 6y ago
      Yeah, desktop development is really rooted in a different time where you'd iterate maybe once in a year... there is some CI/CD tooling these days, but dealing with the end system & user is still a hard problem.
• gherkinnn 6y ago
  I don't quite get the frustration. Learn one set of tools really well. Make sure it's here to stay, mature, and has a large community. My fav is Nextjs, but it could be anything. Make sure it comes with everything you need, including a CLI to set up your project. Stay as close as possible to what the stack gives you. Don't build on top of it, unless you're willing to upgrade constantly. Avoid configuring your build system yourself, unless the framework gives you clearly defined escape hatches. (Like Next does.) Learn the underlying fundamentals. Learn about algos and data structures. That will be relevant forever. Most importantly, ignore these "20 state management libraries you should learn in 2021" articles. They are poison. And nobody cares.
  • richeyryan 6y ago
    Surely this line of thinking has the potential to lead to "I know NextJS best so every problem looks like a NextJS problem" ? If you limit yourself to the surface area of one tool, you become reliant on the authors of that tool to solve the problems you need solved. Then if that tool declines for some reason you have to look for another tool that solves all the same set of problems for you. Not to mention you'll probably find your job opportunities limited if you're all in on one tool. I think you are spot on when you say learn the underlying fundamentals but that should be extended to the web platform. Learn how to manage state outside of your favorite library. Learn how to cache your assets and HTTP responses using service workers. Learn the general ideas behind MVVM views so you can look at another library, get the gist and get going. My best lecturer in college told us that he wasn't teaching us specific algorithms or MVC or the DOM APIs. He was teaching us how to learn. That there are common patterns and fundamentals and "new" things are usually similar to existing things in some way. Usually when I see some new frontend library, I see a concept that has been recycled or stolen from some other library and presented as new. I don't believe there is much novel work being done put out there. Even stuff that qualifies as somewhat novel like Svelte is really just a refinement of the road React started us down. It probably takes a bit of work, and sometimes luck, to figure out what's transient and whats important universal stuff but once you start looking at things that way, it makes it a lot easier to appraise the new stuff and figure out if its worth your time or not. Then if you need to solve a problem its not about how NextJS can be twisted to fit it but just taking the components you need and assembling them in a way that makes sense. Maybe this approach just requires more learning than is reasonable for most people, I don't know. I personally like learning, seeing what makes things tick and how everything fits together.
• iansinnott 6y ago
  > Oh and while you're at it, install also Yarn Both NPM and Yarn come bundled with recent Node versions, so hopefully you only need to install one thing (Node). That being said, having multiple package managers must be confusing to people who haven't spent entirely too much time configuring front-end projects.
• audessuscest 6y ago
  > Don't have NPM? Better install that, too, because nobody installs libraries without a package manager anymore. Oh and while you're at it, install also Yarn, because why not make use of two package managers at the same time. Phew... Using a package manager ? oh no... not that lol wtf
• giantDinosaur 6y ago
  Weird that the author says all languages are very similar. Strongly suggest trying something like Elm (although I do not recommend it for any large production use, small areas are fine.) to see how brilliant the experience in another paradigm can be.
  • ronanyeah 6y ago
    I would personally recommend Elm for production use after 3 years of development with it. I regularly engage in refactoring efforts that would be prohibitively time consuming in React, which I also have production experience with.
  • z5h 6y ago
    I've used Elm at 2 places for large production use, and in a large personal project. It would be my preferred technology by far. I'll add that Elm is actually what converted me from a backend (fullstack at times) engineer to front end. Also realizing that thinking about how people interact with computers and solving those problems well is actually a fun challenge.
  • cies 6y ago
    Me too! Loving Elm. And there are others that break from the pain that frontend otherwise is: * Purescript * Kotlin/JS + KVision * Rust + Yew * Haskell + Miso * ReScript + ReReact or TEA * F# + Elmish Hell even TypeScript + TEA would be a great alternative: https://github.com/typescript-tea/core https://github.com/typescript-tea/core A hot topic still is CSS that non of these solve, so an additional lib is needed there. TailwindCSS has been my go to lately, and I really start to get the hang of it (great docs also!!).
    • giantDinosaur 6y ago
      Not necessarily solved, and I assume you know about it, but for anyone reading this, elm-ui is definitely worth checking out for at least an exploration of an alternative to CSS. For a talk about this: https://www.youtube.com/watch?v=Ie-gqwSHQr0 https://www.youtube.com/watch?v=Ie-gqwSHQr0
  • 6y ago
• CapsAdmin 6y ago
  The thing I don't like the most about frontend is setting up a stack. Often I wish things were more explicit and less magic. It feels like a lot of a projects' meta state is managed poorly in the filesystem. One concrete thing I can think of, when Typescript transpiles to dist/*, it is not cleaned up from last time it transpiled. So if you directory structure changes this can lead to strange issues like running an old version a .js file without realizing it. A very high level/magic library I use provides no way to configure its initial setup through javascript. To do automated setup I have to write a config file to disk to work around it. (The library is otherwise great, and I should report this now that I think about it!) Other than that I kinda like the messiness of frontend.
• nathias 6y ago
  so he doesn't like front-end because it became like back-end and is now going to try if he likes back-end more ...
• mxxx 6y ago
  Relax a bit and just use the tools you like. If it doesn’t make you more productive then don’t bring it into your stack. Love building things with plain old JS and CSS like it’s 2007? Go nuts, it all still works.
• tobyhinloopen 6y ago
  SRR en jQuery still work today, and you can still create nice interactive apps with them
• gorpomon 6y ago
  It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically. The complicated web is here because users insist on interaction, and if any web page has more than around 10 interactions on it, the resultant complexity is best handled by a framework. I recently got to do a jQuery job for a client-- it wasn't a pleasant blast from the past but a kludgey swamp to slog through. The build pipeline complaint also strikes me as hollow. Create React App outputs folder you can drag and drop onto a server and serve, same for Angular and I would assume Vue. Yes, it is a lot of JS from a ton of NPM libraries, but that's the trade-off when you get an entire ecosystem of code for free. If your application is security critical then consider either writing your own libraries or hosting security vetted copies of the libraries. The real reason to leave this industry is that it's all the same work at the end of the day. Despite what application you build, whether it's a social network, a security application or collaborative tool like Figma or Trello, it all runs together as a mish-mash of views, data and DOM elements. Unless you're really invested in the product, it becomes hard to maintain enthusiasm. You can only roll a CSS library, or auth scheme or API library so many times before you're ready to start some new adventures in coding.
  • catmanjan 6y ago
    >user's expectations for the web have grown astronomically Have they? I don't see that in my user stories
    • deleted 6y ago
      [deleted]
    • paul_f 6y ago
      Users just want it to work. I think the problem is too many developers trying to impress each other for status. IMO, what matters most is coding efficiency, how fast can business problems be solved with a low enough error threshold.
      • danjac 6y ago
        It's a combination of whimsical requirements from PMs and designers, plus FOMO and resume-driven development among developers. None of which have anything to do with actual end-user needs.
• _0o6v 6y ago
  I agree. The fact we've invented insane frameworks like Gatsby to create "static websites" is just totally mindboggling to me. We already have "static site builder" technology. It's called HTML and CSS.
• ChrisMarshallNY 6y ago
  Well, I have enjoyed doing backend, but it isn't really what I'm good at. I guarantee that there are thousands of people that can do better servers than me. My stuff does tend to be solid and high-quality, though; just not as ruthlessly efficient as a dedicated backend engineer can do. I am fairly good at writing SDKs. That seems to be where my strengths lie, in the backend arena. But I really enjoy doing frontend. The difference for me, is that I am not a Web/site designer. I do applications, using compiled and linked native language (Swift, on Apple). I'm big on usability, localization, and accessibility. I enjoy writing a powerful application that can be localized to an entirely new audience by simply sending a single text file to a translator. I also enjoy writing stuff that is usable. One of the things that I do, is fail to provide documentation to users of my applications, during development, so I can see how they understand, model, and use them. I sometimes make fairly big adjustments, because users fail to understand an affordance, or misinterpret a user interface element. I also enjoy interfacing with devices (Bluetooth, TCP/IP, USB, etc.).
  • jamil7 6y ago
    I also switched away from React to iOS/Swift full-time roughly 2 years ago, although I was doing it on the side and as a hobby for longer. Couldn't be happier honestly. It's not without it's own issues but I find it much more manageable.
• xwdv 6y ago
  I hate front end work, but not for the reasons given here. I actually don’t think the boilerplate stuff is a big deal unless you’re starting new things all the time instead of maintaining an existing project. The real reason I hate front end work is because you spend so much time programming meaningless stupid shit that is only complicated because you have to achieve a certain aesthetic or UX. Imagine spending a day getting some borders to render correctly for some custom widget. Borders! With backend work though, things you write are usually much more important and you spend less time tweaking and tinkering to get something “just right”. And you don’t have to deal with designers.
• jonplackett 6y ago
  I totally identify with all this, having originally been a flash developer back around that time (even easier than html). BUT, I have recently discovered the joy of react. I hated it at first of course (what's with this stupid jsx language that my text editor doesn't even understand how to error check?) But now I've finally got my shit together with Visual Studio and the right plugins, it's really kinda neat.
• jonplackett 6y ago
  At least we don't have to worry about Internet Explorer compatibility anymore.
• mac_was 6y ago
  The problem lies in what you actually want to create. For your simple html,css websites with gifs please don't use React with Typescript! But if you are writing an application, something which is supposed to replace desktop software, and allow for storing data in a database, retrieve it quickly, manage some sort of complicated systems then I'm sorry Html + css is not good enough. Use the tools you need, don't pick react for landing pages. Edit: typo
• erdos4d 6y ago
  I predict this will sort itself out in a week or so.
• raspasov 6y ago
  Try Clojure/ClojureScript, you might like it. Much less ecosystem churn, good tooling, an excellent language.
  • richeyryan 6y ago
    His website says he works with Clojurescript at his employer. I thought it was strange when I saw that.
    • fulafel 6y ago
      I guess given this latest post says "Nowadays I make a living mainly with JavaScript and TypeScript" it means that ClojureScript isn't used there anymore.
      • askonomm 6y ago
        I still write it every now and again under a blue moon, but only when working on legacy stuff or replacing components with their TypeScript counterparts.
        • raspasov 6y ago
          Replacing ClojureScript with TypeScript? I wonder what the rationale for that is.
          • askonomm 6y ago
            We were told that it's hard to find Clojure engineers, but everyone including your grandmother knows JS/TS, but I think what they really meant by that is that they can't afford Clojure engineers.
            • raspasov 6y ago
              Sounds like a quantity is better than quality argument. I bet it came from a non-technical person (or someone who hasn't written code in years).
• z3t4 6y ago
  TypeScript, ESlint, SCSS, React, etc are training wheels. front-end development is harder without them, but it's also much faster if you skip them once you learn.
• DrStartup 6y ago
  Many the author’s points are exactly the reasons I like and am bullish on SvelteJS. I started doing web dev in 1995. PHP was game changing. I feel the same about Svelte. For me, there are way too many layers in modern front end. I want to be as close to the foundation as possible - vanilla js, css, html. That is where the joy is. Svelte is the new old thing with a healthy sprinkling of awe and wonder.
• vmception 6y ago
  > will be seeking an exclusively back-end role for my next adventure, starting April gigglesnort ooooh boy > The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn. BAHAHAHAAAHAHA Enjoy pretending not to have memorized Grokking the System Design Interview front to back, ah man what do you mean instagram doesn't even look like that anymore and even Snapchat is a $100B company after getting ripped to shreds by competitors, it doesn't matter! of course you'll only be periodically adding rest endpoints for poorly designed startups using whatever came after express, this is just for the interview!
• majky538 6y ago
  I agree, but anyway as mentioned, it's about tooling. When I compare creating JS SPA vs. for example .NET MVC website, with JS you will get awesome SPA (oh wait, do you really need that?) - easier way to create dynamic stuff but with cost of bigger complexity which probably comes in ways as project management, DevOps, testing. I was developing some SPAs in Angular, React and of course there are some great things but I do not see the pure reason because of additional complexity to develop everything in this "modern" way.
• stavrus 6y ago
  What's frustrating to me is that even though a lot of these frameworks and tools keep advertising themselves as making you more productive and letting you write less code in the pursuit of better client experiences -- ie, creating an "SPA", a single page application -- they keep adding more tools your way and more required boilerplate for you to write. You can argue that it's inevitable as they "mature", but then someone comes along a year later with a fix to those problems and you're forced to relearn everything to keep up. This cycle then starts over anew for the next 2-3 years as more tools and required boilerplate are added and someone gets frustrated enough to provide a new framework and tooling. I've gone through this, in turn, as I've developed applications from plain old JS, to jQuery, to Backbone.JS/Marionette, to AngularJS, to Angular, and most recently to React, along with the similar change in tooling through Grunt, Gulp, and Webpack. Each time as the amount of boilerplate I'm forced to write begins to frustrate me, a new framework conveniently rolls around and convinces me to switch. I haven't looked at Vue.js yet, but a co-worker on a different team showed me a React/Redux project and I ran away screaming -- figuratively, not literally! -- from the boilerplate involved (if you're wondering, so far I've been pairing React with MobX but the applications haven't been particularly big). The dev experience has been better each step, but it's not been an easy ride and it's obvious that these frameworks don't represent the end of the chain. All this time I thought this was just the required tax for providing a nice front-end experience, but recently I've been diving heavily into Blazor Server-Side and Phoenix LiveView on some personal toy projects to see what the server-side landscape is like, and it's a breath of fresh air. It's surprisingly quick and easy to write code that provides an SPA experience where changes on one connected client immediately propagate to other connected clients, and with so little code to boot. They have their pros and cons, but the dev/productivity experience has felt so much better. Because C# is such a great language, Blazor is super easy to jump into and immediately understand what's going on, and since it's part of ASP.NET you're not going to lack in good libraries/documentation/examples/support. However, it doesn't really have a good reload-on-changes functionality yet even while running under dotnet watch, as you'll have to manually reload your browser tab after changes. Phoenix LiveView on the other hand has a great reload-on-changes functionality for fast iteration, but its drawback is that it has a much steeper learning curve and initial hurdle. Fortunately it's offset by the fantastic documentation it provides, but it is something to keep in mind as it makes on-boarding people not used to Elixir/Phoenix a bit difficult. Honestly, if the OP article resonates with you, I recommend giving one of those two server-side frameworks a spin. It's nice to temporarily escape from the craziness of the modern JS landscape, and to not have to write your models twice.
• ravivyas 6y ago
  I kind of sympathize with the author, but when again it is bad requirements that make things complicated. I like to follow the concept of Boring Technology I built a CRUD dashboard with some data scraping and parsing capabilities for a friend recently, and because I could define what I used, i kept it simple and relatively boring The stack AppEngine (NodeJS), Google Cloud Tasks, BigQuery, Postgres and FireStore as a redis equivalent for session cookies. The front end has Zero JS, the app does not need anything fancy. I am using Nunjucks for templating and Tailwind for CSS. The stack seems large, but I have zero devops work, and the DB is the only thing that keeps running all the time.
• mellosouls 6y ago
  Reminds me of this satire (the original also linked in it): https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
• ElectricMind 6y ago
  Thanks. I no longer have a doubt if my next job will be "full-stack developer" or "Java Backend developer" :))
• sprkwd 6y ago
  I stopped doing FE development a few years ago because of the unnecessary complexity of everything. I've gone back to my roots and am now actively avoiding anything to do with the internet / online world. Bar HN & Mastodon.
• cutler 6y ago
  Try Rails and Stimulus before you give up. Next to no JS with snappy front-end rendering. I believe Laravel and Django have adopted it too.
• locallost 6y ago
  I agree with some things. But on the other hand people started using npm (or bower) because they were tired of manually downloading and linking dependencies. Of course you had to do like 5, but now that everything is on npm it turns out that those 5 have 10, and those than have 20, so... CSS preprocessors I don't like that much either, but having an autoprefixer is actually nice. The alternative could be in the future to just not use it. Maybe we're already there? It used to be difficult to get anything done. It was kind of, at first figure out how you will even get this complicated design to work. And every time you thought you had it, it turned out no, something broke in IE. This part got progressively better, to the point that I don't really test in multiple browsers anymore. But as things got easier, we found ways to make it complicated in other areas. And we can do nice things, but sometimes they don't add that much, yet cost a lot in terms of effort. There is some pain and friction with colleagues that always want to do something new because others do it. When you get older you stop caring about that, and want to keep things simple and replace things that are an actual problem. As others have pointed out, this is the same in any area. We had a discussion what to do a couple years ago, and one colleague was dead bent on using GraphQL for an API. He's good at his job, but the answer to why was basically "because others do it". We didn't and we're fine -- we didn't need it. So you're going to get that pressure to learn new things everywhere. I don't have a good answer to this other than focusing on learning things that will last, even beyond this one area of work. But figuring out what that is can also be difficult.
• Vinnl 6y ago
  I'm a few years older than the author, but otherwise have a largely similar history. But I love front-end! Yes, there's a lot of tooling, but I think the difference is that I see and appreciate everything that that tooling's brought me. It took many years for me to learn what I know now, but given what I know now, there's so much I can do now that I couldn't do before, or would've taken me a lot longer.
• germs12 6y ago
  This guy is in for a rude awakening when he finds out backend is no different.
• davidn20 6y ago
  I'm a fullstack developer and I started picking up more modern frontend frameworks 3 months ago. Has this person try to manage a large complex site with just HTML, CSS, and JavaScript/Jquery? It's a mess, a complicated mess. Sure, for small sites and small codebases, use basic tools. However, how many companies are building basic sites now? React, Typescript, SCSS, and all these other technologies came around not to make your life more difficult. It popped up because for specific use cases it makes your life a whole lot better. Also, backend is not any easier...
• the_gipsy 6y ago
  I stopped doing frontend work when I realized that everybody is working against good UX. Marketing departments, Product Owners, CEOs, all want you to implement dark patterns and small traps for short sighted metrics. On top, just everybody and his mother has an opinion on how the UI should look and work.
• phtrivier 6y ago
  Sad for the author. That being said, the first backend task will be "picking up a language", then "install the package manager for this language", then "install the build tool for this language", then "setup docker to create cloud-ready artifacts for the backend", then... etc. Of course, it's still possible to fire up a text editor and write your pure HTML / CSS / JS web page by hand, put it on a server, and get things done. Just like it's possible to fire up a text editor, and write your simple backend code in... wait a sec, no, you at least need a compiler or interpreter for that. Anyway. For which language again ;) ? Let's hope the author gets more excited by his or her next job.
• tambourine_man 6y ago
  You can still write PHP and jQuery. Most clients don’t care what stack you use as long as it works and it’s fast. I still haven’t found a good use case for React and I’m doing just fine. SASS is great, I wish native CSS was like that, but it’s not that nice to be worth a preprocessor. Same with typescript. Sure would be nice to have optional types in JavaScript, but not important enough to go through all these hoops.
• psikomanjak 6y ago
  I think the author is kind of mixing the coding for himself/fun and coding for someone else/money.
• yoz-y 6y ago
  So young and already jaded. To me the problem with frontend, and why most people I know want to avoid it, is that compared to backend the specifications are never clear, change more often, require a lot more boilerplate and is in general more verbose. If I look at code I've written, the backend/"useful" code is always fraction of length and complexity of the UI code, no matter the stack (be it gtk, swiftUI, jquery, pure JS or a reactive framework). UI often requires a lot of custom code because there is always that one bit that the framework doesn't support. An example would be a table displaying some data with metadata. Adding more stuff on the backend is easy, just update your endpoint with one more field in the response. On the frontend it might make each line too large for screens, so now you have to figure out how to place it in a way that fits. Sometimes it may not be as simple as just extending the line a bit.
• bokmann 6y ago
  Yea, also have you used Angular? Makes you want to quit coding in general haha.
• sigmonsays 6y ago
  everyone is ranting about complexity, but these tools are built for a reason. We learn to use the tools to improve the efficiency of the job at hand. Not all tools are useful, but lets make better ones! Also, All tools are not for everyone, so developers should be comfortable not working with specific tools.
• robin_reala 6y ago
  The problem the author has is that he’s focusing on the technology and not on the user impact. The point of working as a frontend developer is that you get to develop the interface between the system and the user, and you get to directly affect how good your users feel about their interactions with your company or organisation. If you start talking about how bad the flavour-of-the-month technology is then you’re missing the point. The tech you should be using is the one that enables the experience you’re building, and that tech can be anything between plain HTML and CSS, all the way up to WASM and WebGL.
• hellwd 6y ago
  As someone who got sick of old school PHP and server-side rendering, mobile development, AngularJS/Angular/TypeScript madness, backend development, pure database development and what not I can tell you one thing: Everything is in our head and it's all because of the fear of staying behind. Once you start listening to yourself and once you start focusing on solving the problems as simple as possible, you will be happy in doing any kind of work. It's OK to be aware of new technologies, but you should use only those that make you happy and that actually solve the problem in a simple way. Why should I feel guilty if I'm not using some technology? Keep in mind that many technologies, frameworks are just products and the main reason behind the hype is money. Focus on general topics like software architecture, clean code, algorithms, best practices, database design skills and make sure to isolate yourself from hype.
  • AndyMcConachie 6y ago
    As much as I completely agree with your attitude, and try to live it myself, software engineers don't get to make their own tooling choices. That is the fundamental problem here. We don't get to choose the technology(framework) that will result in the least amount of hassle and easiest to maintain software artifact. Instead, we get stuck using what someone else chose for us.
• IAmNotAFix 6y ago
  I have the same opinion except it's not that programming is more complicated than before, but that enterprise programming is more complicated than week-end programming. Side-projects are fun because they're free of so much of the bullshit. How much of this bullshit is actually a necessity to build something serious and maintainable is not entirely clear, but it's not 0 nor 100%.
• f6v 6y ago
  Honestly, this is applicable to many computational fields. I’ve done mobile, backend, and a bit of frontend. Now I do bioinformatics and guess what? It’s the same: the field is moving fast, dozens of new data processing tools pop up every month. A zoo of different algorithms, statistical models, machine learning techniques. And nobody cares about code style and automated testing. 9 out of 10 times you won’t be able to run the code the manuscript author has written because there’s either no code shared or it’s just not runnable. My point is you’ve got to defeat the tools fatigue and focus on something else. It’s a bit easier in life sciences compared to your typical b2b or b2c app.
• stephen82 6y ago
  Even though I'm not a front-end developer, I dealt with WordPress advanced custom development for a certain amount of time to realize web development - as we currently know it - is not worth it...like *at all*! As an OCD person I cannot count the number of times I got panic attacks for realizing how many tests I needed to go through to test: * have I checked my PHP code, packages, and settings? Are they all good? * is Composer and my various packages updated? * what about npm and yarn packages? are they updated? * wait...do I need worry about CSS as well now, to look for extra security measurements? WHY?! Oh yeah, CSS injection [1] /facepalm You cannot imagine how many times I jumped out of bed to run to my computer to double-check a security measurement on an infrastructure I thought I did not secure only to find out I already did an extra step that double-secured it... It's not worth it anymore. It's SO FREAKING STRESSFUL! I decided to stop dealing with web development as a whole and I'm playing with C and C++ now, like the good ol' days. I can't do multiple things at once. I live and breathe the UNIX philosophy: Do one thing and do it well. [1] https://www.netsparker.com/blog/web-security/private-data-stolen-exploiting-css-injection/ https://www.netsparker.com/blog/web-security/private-data-st...
  • Clubber 6y ago
    I started back the days of CASE and RAD developing Windows apps against a database then eventually am middle tier. You could build something useful, stable, and production ready in a couple of days or weeks depending on the complexity.
• bobkrusty 6y ago
  this is the most hilarious blog piece on HN i've ever seen
• neon_me 6y ago
  same good ol'story :) in reality we are all "always newbies" and we will be. Thats the modus operandi of always innovating/disrupting world. No matter what you are doing. You either stuck on your favourite patterns, learn new or die. Ask MDs, scientists, mechanics, uber drivers, whoever ...
• recursivedoubts 6y ago
  I would like to invite you to try htmx: https://htmx.org https://htmx.org It is a do-over for front end development: rather than trying to address the shortcomings of HTML as a hypertext by adding in more javascript, it addresses the shortcomings directly. I think you will find it to be a much more simple and understandable way to work on front end development.
  • ausjke 6y ago
    I'm trying htmx after years of frustration with all other SPAs and build tools and changes. after reading the site I still feel I need a little more information, is there known projects made with htmx somewhere for me to study? Thanks for the great work!!
    • recursivedoubts 6y ago
      It's pretty new but people are starting to publish information on using it: https://www.mattlayman.com/blog/2021/how-to-htmx-django/ https://www.mattlayman.com/blog/2021/how-to-htmx-django/ https://www.jerriepelser.com/blog/using-htmx-with-aspnet-core/ https://www.jerriepelser.com/blog/using-htmx-with-aspnet-cor... You can also join the discord server if you have questions: https://htmx.org/discord https://htmx.org/discord
      • ausjke 6y ago
        Great. Thanks!
• mpurham 6y ago
  > The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn. The lie we all tell ourselves! yes it is true one can pick up a language fairly quickly but knowing how to use the language properly and learning the language eco-system (frameworks, plugins, etc) takes time. Well at least once you have kids.
• u678u 6y ago
  I'm the other way around. The backend is both getting more complicated and getting replaced with standardized solutions. It seems its easier now for front end developer to write a whole solution with a standard back end like firebase than it is for a dev to write both back and front.
• gedy 6y ago
  Many/most? people don't like UI development, in particular UI state management. Including smart developers. "Front end complexity" complaints are frequently that, but misattributed to the code/tools/etc. I miss the simplicity of the static web too.
• DrFell 6y ago
  The most complicated web development stuff is the easy technology taken to extreme levels of pseudo-sophistication. The technology that's unpopular because it's too complicated to learn is actually easier to build real projects with, and maintain long term. The reason is because the easy stuff its too simple to have an architectural foundation or engineering vision. Easy to learn, hard to use. Sort of the learning curve version of a stitch in time saves nine. It's exacerbated in frontend because it attracts so many beginners. When the loudest voice is the junior developer, popular tech != good tech. That's why frontend is so chaotic and confusing. This is all sort of obvious, but nobody want's to hear it. When I've tried to state it in online forums, I'm either a troll or a gatekeeper. shrug
• ppeetteerr 6y ago
  A simple search returned a Medium article wherein the author talks about using React without all of the tooling: https://medium.com/@chrislewisdev/react-without-npm-babel-or-webpack-1e9a6049714 https://medium.com/@chrislewisdev/react-without-npm-babel-or... Overall, anyone who works for a large company will have to deal with a large toolset. That's how you get 10+ engineers working together without stepping on each others toes.
• hmans 6y ago
  I find it amusing that he says frontend development is complex, but states having to use SCSS to make the point. My dude, if you're using SCSS, you've successfully avoided all the _real_ craziness that's going on around CSS-in-JS and such! Other than that, I've grown quite bored of posts like this, and if I were a potential employer looking at a post like that, all I'd see is someone moaning (and even going as far as quitting their job) because of a little technological complexity, and would certainly not want to hire them for anything truly demanding.
• andrew-dc 6y ago
  I feel the pain here. Most the people I know who have been in the game for a good while every so-often remark: what was so bad about js, html, and css? ;) Of course, the reality is far more nuanced than that. All this said, I would strongly recommend anyone who's running into this front-end burnout phase to give Svelte a serious look. And no, I'm not on the take here, it's just my personal experience. Now, Svelte won't solve all of the OP's woes, cause yeah, you still need some tooling, and to get up to speed with some new hotness. But Svelte is about the closest 'framework' I have messed with that feels like simple js, html, and css - without loosing all of the hard fought advances in front-end. All of the new-skool tech without the feeling of over-engineered BS. For context, our ui team (just 3 people) have built a component library for our entire org, which includes many teams and deliver ui modules seamlessly across vast legacy applications. I can't imagine pulling this off with any of the other stuff I have used.
• tommyderami 6y ago
  I feel their pain to a degree, but this also reminds me a bit of someone who says 'When I was young, I loved building tree houses in my backyard with a couple of boards and some nails, now as a structural engineer, I have to do all sort of awful work like material takeoffs, load analysis, job site scheduling--it just isn't fun anymore!'. That's the nature of real work--small hobby projects or simple gigs are easy for a single person to write, but as soon as you bring multiple engineers, legacy system integrations, infosec reqs, etc. things get complicated quickly. It's a big ecosystem out there though, and people are inventing new way to work all the time (Hotwire and Sapper both have interesting ways of doing things compared to the current status quo). All that to say, I hope they find their bliss, and maybe a chance of scenery will at least help remotivate in the face of fatigue with their current set of frameworks.
• iainctduncan 6y ago
  Having been through all that myself for years, and now happily programming for grad school on a thing that IS JUST A THING, I totally sympathize. (One program, two languages, that's it. Ahhhhhh, it's fun again!) WebAssembly may be somewhat of an escape hatch. I was interested to see in a diligence I was conducting how well Microsoft Razor was working for a firm we examined, so that all their frontend is C#, using the same backend code they already developed, and one build pipeline. It is making them happy and productive, can't fault them on that. I've done the whole thing on the front end, dating back to the old days of Dojo and Ajax through pixels, though NG, React, Reframe, etc, and even now, it's such a gong show. Just try mentoring a brand new dev and you realize the stack of elephants for tooling is such a stupid, awful situation.
• whycombagator 6y ago
  Do frontend devs have on-call? Backend devs do. Frontend devs also have less algorithmic FAANG (and others) interviews[0] [0] https://mobile.twitter.com/dan_abramov/status/1078658656344903683 https://mobile.twitter.com/dan_abramov/status/10786586563449...
• peterthehacker 6y ago
  I’ve been feeling the same way about modern HTML/JS/CSS. The tooling has become too cumbersome and languages like TypeScript, SCSS and even Elm illustrate how the community needs a new frontend toolset. On top of that tools like React Native and Electron add even more complexity to the problem. I’ve recently started looking at Dart/Flutter - https://flutter.dev/ https://flutter.dev/ - which looks like it might have some potential to fix a lot of these problems. Has anyone here used Flutter and feel like it addresses these problems well?
• eyelidlessness 6y ago
  I have a very similar career trajectory, but starting a few years earlier. Remember web rings? Anyway I think there were two phases of the complicated web: - there are build tools emerging (grunt, gulp, etc) and now web apps have a build step to automate certain complexities like minification, but you write more or less plain HTML/CSS/JS or maybe transpile if you prefer. - the build tools are your entire process and the languages you write in are constructed by an infinitely configurable set of inscrutable plugins. I didn’t intentionally shift toward backend, but it did happen gradually between those two phases. Having spent the last few months getting reacquainted with frontend, the phases feel very distinct. I know HTML, I’ve gotten caught up on CSS. I’m perfectly comfortable with React and I love JSX for the most part. But I spend most of my time appeasing/fighting with tooling. Even though I’m writing in the same language (TypeScript) that I’ve used for years and feel very comfortable with on Node, all the frontend types feel like a funhouse mirror reflection of the language I know. I’ve lost entire days just trying to satisfy types on a HOC. I’m not giving up because I’m excited about my project but I can honestly understand the author’s feelings. I sincerely don’t think it has to be this difficult. And I can’t imagine being new to programming walking up to the current frontend process.
• luord 6y ago
  While I don't (yet) hate svelte/vue/react/etc and their tooling, I recently found out about htmx[1] and I must say that it's definitely changed the way I'll build applications going forward. It's the epitome of applying the KISS principle for building interactive web applications, not in small part because it allows the developer to keep the UI code in a single place, backend templates, instead of spreading it around[2]. In my particular experience, I've found that htmx pairs really well with my backend microframework of choice, flask. In fact, using htmx means that there isn't a division between backend and frontend as much as there's a backend with some extra attributes in some of the tags in the templates, and a few extra rules deciding which template to serve at specific endpoints. [1]: https://htmx.org/ https://htmx.org/ [2]: Having spent most of my professional life deep within js/ts frameworks, I thought that progressive enhancement was either a pipe dream or required duplicating at least a significant portion of the UI code on both ends. Htmx showed to me that such ain't necessarily the case; `hx-boost` in particular is a godsend.
• harel 6y ago
  As someone who started a few years earlier, and speaking as full-stack programmer, as it's called today, I can tell you it was always like that - an ever increasing complication graph. However, I like it. I don't miss the tcl, perl, coldfusion, php files all mixing everything up. I don't miss FTP as a means of deployment. I don't miss configuring the first Apache webserver, or setting up the Sun servers and using csv text files as databases. I embrace the complexity because it's there for a reason. Most of it. Some of it at least. It solves problems we already forgot we had. And it's cyclical. We'll soon forget what the problem was, go back to square one, and given some time arrive back to where we are today and then some. My advice - embrace the complex, reject the complicated.
  • ChefboyOG 6y ago
    This. It's a cycle of bundled complexity to unbundled "simplicity" and back. I'm not so sure it's even entirely unique to software.
• midrus 6y ago
  Sadly you will find the same thing on backend, and even on infra, so better to think in switching to do something else not computer related if you don't like it. On the frontend, people are crazy with React, redux, css-in-js,etc,etc, on the backend, same thing with dozens of different languages all of which we're migrating away to Go, microservices, grpc, graphql apis, etc, and on infra with kubernetes, more Go, all the amazon ecosystem, ingestorwhatevers, etc. As I've said many times, everyone wants to have fun. You can still do things The Old Ways... it still works... but yeah, pretty difficult to do it that way at work, so that is something mostly for your side projects, etc. Also, to some extent, some of this is necessary. For example, I like a lot the "modern old ways" of doing frontend, such as the way it can be done with Hotwire, intercooler, htmx, Unpoly, etc... but I agree that once you're part of a larger team, React, Redux, etc... provides a more streamlined way to build your application (once the gazillion decision of the tooling is made). Doing it the "old way" doesn't scale with people, as everyone will have its own supercool shiny idea of how to do things. Also, the "webpck, babel, etc are too complicated" are not a valid argument anymore in my opinion. Those are pretty low level tools, compilers, etc. Just look for a high level tool... in React you have Next, in Vue you have Nuxt, if doing plain js you have Parcel.... And, again, once the honeymoon is over you'll feel the same about backend and infra at the very least (I've been there)...
• dave333 6y ago
  I am now retired after 40+ years mostly front end coding and the only examples of my work still running are some plain old javascript game sites from 2005. I switched frameworks/languages/toolsets about a dozen times over the years and finally reached the point where I was too old to learn the new stuff (React and its evolving ecosystem). Some tools have a longer than average shelf life - things like Unix utils, jQuery, git, node - what are your favorites?
  • 816238721639812 6y ago
    Why did you feel that you were too old to learn the newer frameworks, if you don’t mind me asking? For context, I’m a young(ish) developer and I often wonder at which age will my brain plasticity will stop being able to learn and keep up in this career. I’m also curious if rather than brain plasticity being a problem in the future, the more likely issue will be losing enthusiasm to constantly learn the latest shiny framework.
    • tylerchilds 6y ago
      Not who you asked, but I'm 31 right now. Started doing frontend at 17. When I turned 30 I made a conscious decision to not use any more free time to keep up with the ever evolving landscape. I'm not sure if it's my brain losing plasticity or if I'm just realizing how much keeping up with all of the latest technologies doesn't actually make me better at my job. My job being to leverage technology to satisfy business requirements. That said, I'm definitely less of a team player because my answer to questions now is, "I've got no idea" compared to "whoa, that's really lucky you asked because I just read this article yesterday, let's try that out" It seems like I'm in the minority at work though. I posted this article like, "DAE?" and the answer was nah.
      • 816238721639812 6y ago
        That makes a lot of sense, thanks for sharing your experiences. This job really does demand a lot from your free time. I can see that not being a pattern I’d like to continue indefinitely either.
• ryanelfman 6y ago
  Try out .NET 5 with Blazor. You will be able to use 1 language (C#) on server and client side and a single package manager (nuget). Install visual studio and your good to go
• kodah 6y ago
  I feel the friction. I'll toss another perspective your way though. I'm a software engineer that primarily works in infrastructure and systems engineering. I end up writing tools that users mostly use in their shell. Sounds pretty uncomplicated right? Write a command, include some flags, produce some output. Not quite! Some notable demands I've received over the years: - Backwards compatibility between incompatible CLI's - Roaming profiles and persistence - Command/flag/value auto-completion - Hierarchical consumption of defaults/profile/flags/environment variables - CLI's generated from backends There's lots of interesting frameworks and tools you can use to design all these and more, however, as users add demand I found myself having to integrate all of them quite curiously, then they all became bespoke projects. The only consistent way that I have to manage this level of uncertainty is through testing. I have very finely scoped and defined unit, integration, and E2E tests that all run various functionality and ensure my contracts so that while I'm writing a feature I don't need to be constantly worrying I have broken some behavior by rewiring all of these components again. The only other tool I have against the chaos is inline documentation. I rarely use consolidated documentation sources anymore, because it always turns into another task that has to be done as an after-thought with this level of complexity. I do also work on big infra products, and these run into many of the same problems the author described.
• beders 6y ago
  "The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn." Time to give ClojureScript a shot? Great time to get acquainted with Fulcro or Re-Frame. Both have new docs and videos out.
• slmjkdbtl 6y ago
  front-end is not bad for complicated, it's bad because people don't know what they need and invent / use unnecessary and bad tools
• sgt 6y ago
  Flutter web simplifies web app development in this regard. It's not fully mature yet but I recently wrote a web app using Flutter web that had 250k users in a week, and it works beautifully.
• asdofindia 6y ago
  Every tool that the author complains about serves a purpose and are optional. Using frameworks can help avoid the complexity of configuration too. https://asd.learnlearn.in/use-a-framework/ https://asd.learnlearn.in/use-a-framework/
• c0smic 6y ago
  It's all about trade offs. No one is required to use all the latest tooling and frameworks, and writing things the 'good old way' still works, it'll just come with trade offs. Pick your poison.