Ask HN: Has web development become insane or am I stuck in my ways?

97 pointsby davzieover 3 years ago

I've been working in web development coding mostly in PHP / Laravel since 2008. I enjoyed my time at the beginning when everything was procedural code and things started changing (for the better).At the digital agency I worked at, we moved to frameworks like Laravel and the frontend side of things was pretty static with custom CSS and some custom Javascript. Everything was hosted on a big dedicated server that would eventually become a VPS per client. The web was really simple then but understandly so were users' expectations of what the web could do and so there wasn't this mismatch that I feel I'm finding now.Fast forward to today and I'm doing primarily product development for early stage startups.CSS is a problem that is solved with Tailwind (for me at least anyway, I know it's a contentious topic). Backend is a problem solved with Laravel which truly does provide everything I've ever needed and in cases where it hasn't (for compute heavy services), I've pulled those areas out into a mini Go service and whacked it on a separate server. Javascript is just a problem...Anecdote 1: I've worked at startups that had Laravel Monoliths where they tried to decouple it into microservices of their own, but this failed; it introduced so much complexity, mental concentration overhead of switching between code-bases and reduced developer autonomy: unless you knew how to deploy these new things and how code libraries should be shared amongst the new services you might as well pack up your toys and go home; you're not smart enough for this. Anyway, the services were bought back into the main repository because it was getting out-of-hand and frustrating to work with.Anecdote 2: I recently deployed a Laravel app for a startup on an EC2 server. It worked great. I used Laravel Forge to do it and it took me half a day at most (once the dependancies I needed in PHP extensions were sorted). The startup wanted to move to Docker and have a CI / CD system. Previously I could just push changes to `master` and it would deploy using Forge. I watched as a CI / CD system was built that when production moved to it, it kept falling over and not really working very well. Additionally my autonomy to fix things was then taken away because there are layers or technologies stacks some of which I know but some of which I don't in the way. The whole thing became so frustrating to see. What was a perfectly working server that took me half a day to setup has now taken over 3 - 4 engineers full time work to end up with something that gives 0 benefit (except the idea that the server can never die, but that doesn't seem to be the case because it kept dying on any deployment and ended up with more downtime than the EC2 server ever had).So why are companies with technology stacks that really arne't getting huge amounts of traffic or require huge amounts of complexity, choosing to use microservices based architectures or build their entire application in something like next.js which requires wiring together so much stuff (Prisma, Auth0) etc. Why do we introduce so much complexity that needn't be to this entire thing?At some point, even though my speed of delivery with my framework and stack setup is frankly very fast and I can provide real value to people, it seems the perceived value of the above shennanigans is greater than the value of actually shipping stuff that matters if you look at the job boards, technologies used and pay given. I would love to be Bilbo Baggins in The Shire minding his own business, but I worry that if I don't jump on the bandwagon of overengineering everything to make myself feel smart then I'll quickly become irellevant in the job market. Am I completely missing the point of why these things are being done or is modern web development choices with regards to language and architecture just certifiably insane?

33 comments

brendanmc6over 3 years ago

I came late to the software and web development game. I just wanted to prototype a tool I needed and ended up becoming a full time developer.After grasping HTML and CSS basics, prototyping my heavily interactive tool seemed impossible with JS alone, until I learned React. React solved real problems for me. Create-react-app with a firebase backend got me VERY far with zero formal education.But I struggled with SEO, load times, and needed a sprinkle of server-side logic. Next.js solved those problems, and more.As my prototypes grew into products, complexity was hard to manage. Refactors were impossible, even with small, modular components and well tested functions. Enter TypeScript. The single most important tool in my toolbelt. I refuse to work in plain JS now.I'm several years in now, at my 2nd full-time dev gig and working on my 3rd side-business. My stack is Typescript, Next, vercel, firebase. Both at work and at home. Hardly any third-party dependencies needed beyond these (stripe, coingate, mapbox). I write most my CSS by hand with css grid because its the least verbose way I've found so far. I auto-format with Prettier.I can use types and tests across my stack, I can enforce bespoke auth/permissions behavior, all kinds of queries, media upload, pretty much everything I'll ever need outside of real-time collaboration. I can build and maintain profitable products by myself. I've done it.This also happens to be a very popular stack. What's insane about it? Every alternative I've looked at looks way less sane. Multiple languages and repos for one app? No thanks. Managing server instances and databases migrations myself? I hope I never have to. Software is fun, but I like making products more. JavaScript just happens to be the best way I've found so far.

评论 #28282247 未加载

评论 #28280505 未加载

clivestaplesover 3 years ago

My personal experience is this: I love building stuff. I love the web. For a long time I loved React/Vue but over time I began to worry about desktop, mobile, PWA, future-proofing and found myself way over-thinking MVP and proof-of-concepts stacks. I tried and tried to limit my scope but found it was really hard to have discipline. Should it be CRA or Next.js? They are both awesome so I can't really decide. Should I use react-native-web so that I can put out mobile apps? How important is being in the app store? Etc, etc, etc.One weekend not too long ago, I started a Rails app with Hotwire and found myself wonderfully, nostalgically productive again. Maybe I'm old, maybe I'm burnt out but I can tell you one thing: I'm having fun and building neat, performant, and fast web apps. I hope that speaks for itself when I look for my next job.

评论 #28286598 未加载

johnwheelerover 3 years ago

I've gotten to the point in my life, where I'd much rather work with people with a good sense of humor over smart people. Smart people do really dumb things. At least funny people can laugh about the dumb things they do instead of hold a tribunal.

评论 #28280875 未加载

评论 #28288085 未加载

评论 #28283880 未加载

PaulHouleover 3 years ago

Every happy web developer is happy in the same way, every unhappy web developer is unhappy in a different way.Other people would tell a story similar to yours except it revolves around Ruby on Rails, React, Docker, CSS, npm, emotion, or some other tools or standards.You either are in a state of peace with your tools or not, and that is something that can change over time. For my job I work on a React application that was started by other people that has some good ideas in it but has plenty of accidents built in.I was doing a side project and was tempted to make a little application in Svelte, which would have been a perfect fit. I used React instead because I wanted to build on and extend my experience. I had a 60kb bundle which might have been 20kb in Svelte but the graphics files are way bigger than that and it loads faster than a speeding bullet as it is.That's the way I attain peace.

评论 #28276048 未加载

评论 #28283896 未加载

tethaover 3 years ago

From my point of view, a lot of people want to use the big stick the FAANG guys use, but they haven't learned that the big stick is heavy, to stretch an analogy. I'm overall happy I have seen a bunch of different workflows.For example, I've been on the operational side of a leading browser game in germany some 5 - 10 years ago. Obviously, it must have been an amazing CI/CD workflow with great automation. No. The global deployment was me. With SCP. And we made money. I'm not necessarily proud of that on a tech level, but it worked. The job after that... we made money by using chef to copy war-files into tomcats and then we had some application to sell. Again, it's not technologically amazing, but it has a huge advantage: It's simple to get right, and hard to get seriously wrong.Now, still at the job, but with a changed scope, yes, we are embracing docker and a container orchestration. But we do so, because we have to scale from 10 developers to 100 - 150 developers and we cannot handle the complexity in a central config management. We cannot support the 3-5 languages and frameworks necessary centrally anymore, so it makes sense to introduce a framework that's easier to cooperate on, in the layer that needs cooperation. It increases the total tech stack complexity, but it simplifies the things the individual team has to deal with, so it's a net benefit for most people.But all that is driven by necessity. If you tell me to deploy half a dozen of same-blueprint php/spring boot/.NET Core apps on 1-2 servers without any infrastructure, I'd look at some ansible and some cheap VMs. Or if there is a natural thing like capistrano or whatever Laravel Forge is, that. I like not doing work and making mistakes hard to make.

sprainover 3 years ago

I have seen many trends, frameworks and „best practices“ come an go. The app our company provides is based on very basic tech, with little js, and server-rendered pages. But you know what? Our clients love it, we are profitable, and we keep growing while being able to keep the dev team small and flexible. Just ignore the hype and focus on what your users actually need and want.

sergiotapiaover 3 years ago

Yes it's insane. The javascript world in particular suffered greatly from people carving up a name and conferences for themselves by building frankly ridiculous tools that the vast majority of people don't even need to reach for. But FOMO takes over.Then you have the extremely low barrier of entry, resulting in `is-odd` packages polluting the shit out of the ecosystem.Then you have everyone and their mother becoming a "JS coder" and bombarding twitter with dev.to articles.You end up in JS hell.The solution is to eject and avoid javascript as much as you can. At this point it's already too late to reverse course, or worse the majority don't even want to reverse course.I've know many people, including my younger brother who said "fuck this" and went full backend to avoid working with npm/node/js.

评论 #28277449 未加载

评论 #28277652 未加载

评论 #28277345 未加载

评论 #28284264 未加载

评论 #28281142 未加载

harryvederciover 3 years ago

> Why do we introduce so much complexity that needn't be to this entire thing?Ignorance, fear, and our urge to pick The Best option.If something is complex enough, at some point everyone is ignorant to some degree. That makes it easy to let fear get a hold of you. Still: whenever you invest, you want to invest in The Best Option since your resources are limited.You're a professional photographer, and you need a new camera. Your old one lasted a decade, so anything you'll buy now will be better and cheaper than the old one. Guaranteed! It's unlikely you know everything about cameras, though. But since you're going to invest in one, you want to get The Best option for the price. You're reading blog posts, reviews, and random comments by people on the internet, and it's becoming harder and harder to decide. There are so many factors involved that you become paralized, you don't know how to decide. Also, you don't know exactly if you're going to be making pictures in the jungle or in the ocean, how many pictures you're going to have to be able to take and how long your battery should last.Then you read that the world's most successful photographer uses a camera that is rumoured to be able to handle all those situations, and has auto-renewing battery and infinite storage. The pricing is a bit unclear, but at this point you're so fatigued that you decide to just get one and find out along the way. At least you know it has the potential to be The Best.

brundolfover 3 years ago

> At some point, even though my speed of delivery with my framework and stack setup is frankly very fast and I can provide real value to people, it seems the perceived value of the above shennanigans is greater than the value of actually shipping stuff that matters if you look at the job boards, technologies used and pay given.One dimension of this is that it isn't just about your own ability to be productive as a solo developer (unless you limit yourself to solo-developer jobs, which can be an option!), it's about the org's ability to be productive as a (constantly changing, mixed-experience-levels) group. It's frustrating to see one's own productivity suffer for the sake of aggregate productivity, but it's a reality of our industry.I can't speak to the particular situations you described but I can speak to this being a real trade-off that often has to be made.

jstx1over 3 years ago

I'm not a web developer so maybe I'm missing something... What's your thesis here? That you're very efficient with a stack that you've been using for 13 years? That other people's stacks and architectures are overcomplicated?If what you're doing works for you, just keep it up. I don't think that you have an obligation to add complexity to what you're doing just so you can stay relevant.

评论 #28281857 未加载

samoraaiover 3 years ago

Totally with you! We’re in your “Anecdote 1” situation at the moment, moving separate services back to a glorious Monolith & Monorepo… Also just anecdotal, but I can confirm that jumping on the SPA/Vue/React bandwagon and the complexity that brings hugely decreased our productivity. And I think if I’m really honest those decisions to move to JavaScript heavy apps were definitely a bit FOMO based in the sense that you don’t want to be left behind with a “gap” on your resume… makes me wonder how often decisions are truly based on “the right tool for the job” or maybe even more importantly “the right tool for the team”.

评论 #28279829 未加载

solarmistover 3 years ago

My biggest reason to use CI/CD after been at startups and big companies is to have a repeatable setup, build, and deploy. By taking the human element out of the machine setup and release/deployment phases a whole class of mistakes are mitigated.Sure, you're fine with running and managing these servers, but what about the new hire who replaces you when you move on?Specifically it forces most of the DevOps tribal knowledge to be coded/documented. Those "Oh, that's right I needed to recompile the mod_wsgi extension manually because this version of the CentOS didn't support python 3" moments go away. (This is a real example from the last server I needed to setup by hand.)It conveniently it also makes setting it up on a new machine a piece of cake. Clone the repo, run the setup command/script and run theIt took me a while to grok, all of the pieces, but I'm glad to have it.That said it can get extremely complex (and by extension fragile) for little benefit. My entire setup and deployment are controlled with two scripts one for creating a cluster (CDN, DB, message queue, app server, monitoring) and one GitHub action script for CI/CD.It's all very understandable even for people who've never worked with these technologies before. Writing the scripts on the other hand take a lot of knowledge and it took me a month to really grok what I was doing.

amerkhalidover 3 years ago

Web development has become insane indeed. At work, I tell myself, technologies change and we need to adopt or we will be left behind.But it is not as joyful as it used to be. For personal projects, I have been using Laravel, I run it on my local machine using Laravel Valet. I got a tiny CRM, chores manager, and various other little one off tools. Laravel is today's MS Access. In early 2000s, I built various applications for small businesses using MS Access.But my skills in PHP/Laravel leads to web development jobs. Which means everything that you have mentioned.So I am slowly exploring new options. Earlier I was playing with Python and Data Science. Jupyter Notebooks are fairly portable, and let you visualize data in fun ways. And I figured Laravel/Nodejs > Django > Data Engineer > Data Science should be easy. But it wasn't as enjoyable. I like building tools.Now I am exploring desktop application development. I looked at Electronjs but that reminded me too much of work.I have started playing with Swift/MacOS/Desktop app development. Apple's development ecosystem using Swift seems great. So far no real issue though I am not doing anything advanced. What I like about it is that I can actually build apps that I can share with my friends without having them install a bunch of dependencies on their machines. The debuggers are awesome. Also I am exploring artistic apps like AR with sound effects + visualizations. You are closer to hardware and can do some pretty cool things.I am not sure how the job market for Swift macOS development is but my goal is to find some sane challenging but not overwhelming (CBNO) programming opportunities.

PragmaticPulpover 3 years ago

Software development is all about picking the right tools for the job. The right tool is a function of problem complexity, team size, experience of the team, maintainability, and other factors.There are two main types of tool selection failures I see:1. Teams that try to choose the “best” tools according to what they perceive as the state of the art without regard to the problem their trying to solve. This tends to become a game of picking whatever they think FAANG might be using, even if their problem is orders of magnitude smaller and simpler. At the extremes, these are the teams that end up building a Kubernetes-deployed custom React-based CMS with server-side rendering when really they could have set up a Wordpress install with a custom theme in a couple of weeks.2. Teams that embody the phrase “When all you have is a hammer, everything looks like a nail.” These teams have been using the same tech stack for a long time and they’re so good at it that they refuse to consider anything else. Instead of trying new tools, they try to brute-force their current stack to get the job done. Some times this works well if the problem is a good fit for the stack. Other times, they waste a ton of time and money doing things that could have been solved quickly by trying a new tool.None of us are perfect, but most failures fall into one of the two categories above. Eager startups often struggle with #1 when they have a pseudo-CTO cofounder who wants to pick all of the technologies but hire someone else to do all of the work.My approach is to draw up multiple proposals with different stacks and present them with an overview of possible risks, benefits, and timelines. Usually once it’s all laid out, reasonable engineers might recognize that the right tool for the job isn’t always the trendiest tool. It takes some good presentation skills to navigate this but it can be done.At the same time, I see some opportunities for you to grow your experience a bit. A CI/CD system has real benefits for delivery, but it shouldn’t require 3-4 full-time engineers to get going. It’s worth learning how to do this right so you can actually evaluate it, rather than dismissing it as useless complication. Frankly, setting up a basic CI/CD workflow with modern tools like GitHub or Gitlab isn’t a big chore. You should be able to come up with something usable and a good understanding of the basics in a workweek by yourself.

评论 #28276772 未加载

llaollehover 3 years ago

Yes - overengineering is a disease. As it is discussed extensively on here, most companies are not Google or Netflix. Engineers usually opt for the most complex option, when there are multiple factors to consider - reliability, development time, is this massive setup cost worth the effort given our load, etc.

thanatos519over 3 years ago

It's certifiably insane.

jmfldnover 3 years ago

I think in some cases at least, this is an example of cargo culting ie. copying big tech without knowing why. Other reasons include resume driven development. Some devs, either inexperienced or plain poor experienced ones, like to entertain themselves by making things complex.However, all of that said, in your particular case, a CI/CD pipeline using docker / EC2 doesn't really sound that mad. The patterns are super well understood there. Maybe it's just a case of getting used to it? Fwiw, we do pretty much that and we have fully automated deployments without much hassle. We use ECS / Fargate too which might sound like a other level of black magic but honestly, serverless is pretty amazing too. I don't even have to think about EC2 now. I'm not saying this to showoff, the point is that this new tech maybe takes some getting used to, but maybe it's just a lack of anyone experienced leading the way on it and helping you out?As for microservices, that can be a nightmare when done wrong but it totally depends. If you just split things up without really understanding why, you're now going to have two problems as the old adage goes. The distributed monolith is the worst of all worlds, especially when the boundaries between services are poorly thought out. If in doubt, and unless you can articulate exactly why you're creating another service, build a well structured monolith imho.

sdevonoesover 3 years ago

What a software engineer needed to know in the 90s to build an e-commerce website:- PHP, HTML, CSS, JavaScript, Mysql, Apache, Linux, FTPWhat a software engineer needs to know today to build an e-commerce website (let's say, we keep using PHP):- A PHP framework, HTML, CSS, JavaScript, React, Typescript, scss, Mysql, an ORM mapper or similar, Nginx, Docker, K8s, GitLab (or GitHub) CI/CD, Git, Linux, be familiarized with some cloud provider (GCP/AWS/etc), oauth, DDD, SOLID, ...The reason: user requirements today are way higher than in the past. And, we all are users. Personally, I, as a user of the internet, wouldn't mind not having banking apps, or SPAs, or 2FA, or "sign with Google", or push notifications, or all these "nice" things we have came up in the last 2 decades. I don't need it, I don't like it, and as a developer I would be even happier if we never introduced them in the first place.Note: yes, a developer nowadays needs to know all the stuff I mentioned above. Just check out job descriptions out there, companies are no longer looking for simple individual contributors, they want engineers that own the whole product from conception to deployment. Very sad panorama, to be honest.

mgover 3 years ago

Did the microservices introduce so much complexity because they were built on some complex "microservice stack"?How would you think about a simple approach to microservices based on http requests? Say we have an application that resembles Twitter and want to split the "messages" functionality off the main codebase. We could run all "messages" functionality on a different server. Served by a completely different codebase. When the user asks for a url below /messages/ we simply do a "GET messageserver.com/messages/...?uid=<userid>" get the result, put it into the template we are rendering at the {messages} placeholder and output the page to the user.

评论 #28277019 未加载

sparker72678over 3 years ago

It’s definitely insane, but you came into this part of the field when it was still fairly young.13 years is a long time for technologies to build on top of each other, and while more things are possible now than ever, a trade off of that is that complexity is higher than ever, too.Also, the boring middle road doesn’t get the press. No one is writing stories about all the little apps and services chugging along with their solid rails or laravel or whatever backends, serving basic html or API requests all day.

the__alchemistover 3 years ago

Yes - it's insane.HTML/CSS/Carefully-managed (modern) JS or Typescript is the way to go. A backend framework that supports DB migrations, authentication, templating, and email. This wouldn't have been reasonable 5-10 years ago, but is now. (Eg modern JS DOM API and language features, CSS grid and flexbox)Maybe a declarative framework for a complex SPA.Domain-specific languages, poorly-performing frameworks, and excessive use of dependencies is pervasive.

DangitBobbyover 3 years ago

Sometimes k8s, docker, and/or microservices are the right choice. Sometimes CI/CD is necessary and sometimes it's overkill. I think your best path forward is to learn some of the new hot technologies and recognize when they are valuable. If someone else forces you to overengineer or overcomplicate, the best you can do is advocate for something better and then be the guy who can do it anyway.

评论 #28281045 未加载

cblconfederateover 3 years ago

Whenever this topic is brought up i wish people replied with concrete, specific situations rather than rationalizations that masquerade as abstractions for their choices. I 've had the luxury to be a solo dev , and every time i look up at a new shiny name that seems to be popular here (so many names! seemingly without hierarchy), i end up wondering "why isn't this thing useless"

blablabla123over 3 years ago

Personally I always prefer Microservices and some sort of CI pipeline over a classic Monolith. Yes, it's painful sometimes but when using some best practices (e.g. one DB per service) it works surprisingly well and can offer benefits that monoliths just can't. But I think it's fair to write Monoliths for new projects - many people do.

评论 #28281015 未加载

toredover 3 years ago

If you have decided to go microservices the most important part to have is good tooling to handle them.Log tracing over multiple services, how to get an address of another service, deploy services independently from each other, track deployed versions of services, multi instance handling of same service, etc.If you don’t have great tooling you will struggle.

raztogt21over 3 years ago

Use <a href="https://redwoodjs.com/" rel="nofollow">https://redwoodjs.com/</a>. My journey has been from no frontend framework -> Vue.js -> React -> Next.js -> Redwood, and I'm the most happy with the tooling at the moment.

p0dover 3 years ago

Programming is like music and you are a Rush fan. Even Rush fans have their favourite periods of Rush. It wouldn't be a very fun world if we all had to like AC/DC :-)

joshxyzover 3 years ago

it is insane, yes.as much as possible i try to simplify everything in work, get rid of the extra complexities people introduce from these new hot things.key questions- can developers code and test on their own- how much devs are needed to stage features- do developers have autonomy on their own projects and assignments- how much friction is there to onboard new developers- how much mental bandwidth is required to keep track of the whole stacklike, we're not even a fortune 500 company serving to hundreds of thousands of people, keep it simple guys

gjvcover 3 years ago

It's been insane for a long time.

diragonover 3 years ago

Why do you use Laravel instead of just plain php files?

codegeekover 3 years ago

It is what all the cool kids are doing.

Nicksilover 3 years ago

No, it's utterly insane.

wetpawsover 3 years ago

No offense, but yes, you stuck in your ways and likely never shipped a real scalable web app at the scale that is expected today.

评论 #28281058 未加载

评论 #28281386 未加载