Live data from Hacker News

Ask HN: Getting tired of complexity in web development

news.ycombinator.com

61–70 of 292 posts

Re: Ask HN: Getting tired of complexity in web development

#61

no such thing as frontend development. only full stack. and react for all the trillions of words written about it, what can you actually do with it? not much. also it's over-saturated as hell. you think there's high demand, you're right, now try applying for a position and see how it goes. there are two types of roles in modern web dev: 1 .90% of jobs are code monkey work: extremely saturated, you are competing with…

While I agree with the message you are trying to convey, the 2020 case doesn't have to be more complicated than the 2010 case:

2010 edit an html button:

0. Install an ftp client (you need to mention that if you mention installing git)

1. pull the file from ftp or sourcesafe/svn

2. edit the button

3. upload to ftp

2020 edit an html button:

1. clone the code 2. edit the html button 3. commit changes

Re: Ask HN: Getting tired of complexity in web development

#62
post #27

Earlier quoted context omitted.

Thing is if you understand php you dont really need a framework. Sure composer packages are a must to avoid rewriting whats out there, but a framework not so much. When i conducted interviews i was shocked at how many php devs had no clue about what an sql injection is, they almost all answered “the framework does it for you” and it was such a basic thing.

Oh god ORM's, pointless waste of time and just an excuse not to learn SQL.. almost as bad as the #1 PHP fallacy; Smarty (which is still a thing).

This point of view is a fallacy itself. ORMs are about productivity and maintainability. Some of us write enterprise applications where ORMs are a godsend. They're not a replacement for being knowledgeable in SQL whatsoever.

Re: Ask HN: Getting tired of complexity in web development

#63
post #47

I call this the "path to enlightenment." You have discovered that the most popular toolchain is overkill for 95% of the things its used for. The problem is that's true literally across the board. You move to the backend and you have to deal with people who fell in love with microservices and weird databases that they didn't need. You move to ops and you have to deal with k8s when a single container would do. If you t…

> Why does this happen? It happens because these technologies solve real problem for some subset of their users. Usually when people are saying that technology has become too complicated, it's because they happen to be looking from a perspective where the problems that the technology solves are invisible to them. That doesn't mean that the problem isn't important - it just means the problem isn't important for them .…

My sense is that is wrong. Case in point, I deal with a group that has a relatively elaborate set of excel workbooks to manage their process. None of the workbooks are great, all of them created and maintained by different teams, and there is persistent discussion of needing to accrue tools or some guy even threw together his own MS Access db to substitute for the workbooks. What they do is not at all beyond what Excel could handle, but it is the lack of fundamental process and methods to design a proper system that is the code and fundamentally problem.

I feel that is frequently the issue, fragmentation and derivation caused by a lack of fundamental first principles thinking, willingness to tackle the issue from the ground up. The outcome is then talk of bolting on yet another tool or some fix that really only ads debt.

Re: Ask HN: Getting tired of complexity in web development

#66

I call this the "path to enlightenment." You have discovered that the most popular toolchain is overkill for 95% of the things its used for. The problem is that's true literally across the board. You move to the backend and you have to deal with people who fell in love with microservices and weird databases that they didn't need. You move to ops and you have to deal with k8s when a single container would do. If you t…

Speaking of ops. What is the simplest reproducible way to accomplish this task. - create vm instance ( setup firewall, users, network dna, stuff) - install : apache, runtime - install app.

Either the snapshot route to have a base image you can then run a single script to install the app. Or use something like Ansible to have reproducible configuration.

Re: Ask HN: Getting tired of complexity in web development

#67

Earlier quoted context omitted.

> request sudo from IT If you work for a company that doesn't give you Sudo on your own machine as a developer by default, find a new job Don't work for companies that still treat their professionals like children.

Easier said than done. This style of doing things is very common in large corporate environments such as financial services. The first time anybody works at a place like this they are shocked by all the IT red tape, but it's an interesting (and frustrating) rite of passage. It takes maturity and experience to understand that there is always a reason for "stupid" complications.

These organization should change their infosec posture to support sudo on dev machines as standard issue, especially if you’re issuing laptops. Maybe I’m immature but I’d prefer not to suffer as such for the sake of a “rite of passage” from ages past.

Re: Ask HN: Getting tired of complexity in web development

#68

I call this the "path to enlightenment." You have discovered that the most popular toolchain is overkill for 95% of the things its used for. The problem is that's true literally across the board. You move to the backend and you have to deal with people who fell in love with microservices and weird databases that they didn't need. You move to ops and you have to deal with k8s when a single container would do. If you t…

>Why does this happen?

A lot of people value more enhancing their résumé than solving problems

Re: Ask HN: Getting tired of complexity in web development

#69
Like you I tend to agree that the effort delivering front end projects often seems to outweigh the value added over recent years. I can think of half a dozen projects I've seen over the last few years where the effort teams put into figuring out stacks of new tools was an order of magnitude greater than the value added (and most of the projects failed to deliver or became haunted forests soon afterwards which is even worse!) It's not sustainable, businesses are wasting far too much money and too many talented developers are left feeling inadequate.

The most important thing in any organisation is to ensure teams are setup to succeed - that means they're using tools which enable them to work efficiently, ship easily and reliably, and their work can be maintained in future.

With that in mind, my advice would be:

1. Ensure there is a process where new tools are scrutinised by peers. I always push developers and teams to explain their tech choices in terms of the value added and often as we dig into this together the justifications melt away. Asking for a timeboxed proof of concept can also be effective - battling toolchain woes and trying to manipulate tools into solving the problems a team actually has often helps lead to better decision making (think https://boringtechnology.club/)

2. Try to work in organisations where developers can be close to their users and are empowered to suggest new features and self serve analytics data. Teams able to build empathy with their users and are motivated to solve problems for those users are more likely to favour choices which provide value quickly - this is a big nudge towards making simpler choices.

3. Give developers space for learning and experimenting. Whilst tempting, picking up a suite of new tools to deliver each new project is a really crap way to encourage self development because those new tools will more often be a big distraction than a force multiplier. Many developers are highly motivated by trying out new tools and frameworks, and some of those might lead to something great in future, so give developers the time and space to try them and make sure their learnings are shared with the team to help level them up too.

Re: Ask HN: Getting tired of complexity in web development

#70
Can I ask what exactly you're tired of in the frontend world?

Is it constantly having to relearn new ways of doing the same thing, without any tangible benefit? If so, yeah, that really sucks, but I guess that's the unavoidable growing pains of a rapidly-expanding industry with different companies all inventing their own wheels. Have you ever thought about working in a slower-pace field (whether it's a different vertical, or a different part of tech, like firmware, hardware, enterprise backends, legacy business apps)?

Is it having a bunch of competing Javascript frameworks (Next/Nuxt/Gatsby/Netlify) and languages (Typescript, React, Vue, Svelte)? If so, it doesn't really matter, just choose one you like and stick with it and find jobs that use it. It doesn't matter how many more spring up, wait a few years and either the dust will settle or something new will come along anyway, but you can skip all the in-between ones. They are all "good enough" these days, there's no need to let the perfect be the enemy of the good.

Is it the buildchain/toolchain, like webpack and babel and parcel and all that crap? If so, maybe use a bolts-included framework like Next.js that takes care of all of that for you with sane defaults -- that one framework can replace a lot of what Redux, React Router, Axios, Create React App, etc. do, and it preconfigures the common things (Typescript and ESlint) for you so you don't have to tinker with that.

Is it having to clobber together a hundred third-party NPM packages to make a functioning site? If so, well, you can either go bolts-included (something like MUI which takes care of a lot of the mundane UI), or go the opposite direction and make everything yourself. You don't HAVE to buy in to the greater JS ecosystem if you don't want to... most of us are just lazy.

FWIW, just as an anecdote, I moved from fullstack to frontend JS and have never been happier with the simplicity. Yes, the JS ecosystem is absolutely a mess, but at least it's ONE ecosystem with messy components, rather than ten smaller ecosystems trying to coexist. Back in the LEMP days (which wasn't really that long ago...), to be a web dev, you had to know some subset of HTML, XHTML, XML, JSON, SQL, Apache, Nginx, Varnish, SQL, Postgres, MySQL, Maria, Perl, PHP, xdebug, Laravel, Symfony, Ruby, redis, memcached, DNS, HTTP, HTTPS, ssh, VPNs, Linux, systemctl, monit, TCP/IP, iptables, Docker, Drupal, Wordpress, Liquid, jQuery, each browser-specific JS (no ES6 yet), CSS browser prefixes, CDNs, cache expirations, S3, EC2, EBS... it was ALWAYS a mess. But these days so much of it is abstracted away behind frameworks and Jamstack hosts. The frameworks are complicated, yes, but they are shielding you from even more complexity. In like 100-200 lines of Next.js code combined with a headless CMS (or someone else's backend), you can do what used to take ten different frameworks in four different languages. Then you can one-push deploy it to the web and it's automatically CDNed and HTTPsed everywhere... in like a minute. It used to take days & weeks to figure all that stuff out, and every part of it would constantly break under load or whenever someone forgot to update a certificate. These days we mostly take all that stuff for granted, and you can just write UI code and not worry about the rest of the stack so much. THAT should be the joy of modern frontend, to allow you to code for UX instead of against your tech stack.

Maybe, instead of hating the job overall, have you thought about what specific parts of it you actually DO like? If you like the design part, maybe move into UI design? If you like the UX part, become a UX person? If you like the actual frontend coding part but not the buildchains and third-party packages, find a company that already has their own devops and frameworks set up so you don't have to do all that? Or think about doing frontend work in a vendor-dominated space (meaning Apple/Microsoft/Google apps, not web apps) using a different presentation framework? If you like interactivity, maybe games dev? If you like solid engineering rather than quick and dirty UI code, maybe more enterprise backend stuff, or work for a SaaS/PaaS vendor instead of the frontend stuff -- i.e. you don't have to work on end-user facing frontends, but maybe dev-facing frontends like monitoring dashboards or the frameworks themselves or admin panels or whatever. Or are there some special frontend techs/use cases you really enjoyed working with outside the DOM, like Canvas or WebGL or WebAssembly or WebSockets or whatever? Real-time multiplayer sync? Web maps? Edge architectures and serverless?

TLDR (and really sorry that was so long and ranty), one of the incredibly lucky things for us as web devs is that there are a million sub-paths you can transition to without having to entirely reinvent yourself. Just a few weeks/months of learning a new system and you can start working in it, vs other professions that have to spend years back at school just to enter a field. You just have to find your own niche(s) and move towards them rather than letting your employers & jobs toss you about in a direction you don't like. For me, that was getting away from the backend and the rest of the stack, but for you it might be another direction. Good luck...!

Post reply on HN