[HN Gopher] Ask HN: Getting tired of complexity in web development
___________________________________________________________________
Ask HN: Getting tired of complexity in web development
I have a few years of experience working mostly on the frontend
with React and am getting more and more frustrated with all the
added layers of complexity needed to work with most common frontend
frameworks. I've hit a point where it just doesn't seem like the
end justifies the means in the vast majority of cases anymore which
really doesn't make me excited to work on much in this space now.
The one redeeming quality of doing this kind of work is that it is
in very high demand, and I worry that the price of becoming more
specialized or doing something more enjoyable with less bloat is
that it becomes much harder to find jobs. Has anyone either
switched from doing web development type work to something else
they enjoy more for similar reasons? If anyone considers themselves
very specialized in an area, do you worry about job opportunities?
Author : jelan
Score : 163 points
Date : 2022-10-08 17:06 UTC (5 hours ago)
| levkk wrote:
| I had a great experience with Hotwired Turbo and Stimulus.
| npteljes wrote:
| >Has anyone either switched from doing web development type work
| to something else they enjoy more for similar reasons?
|
| I became a manager of engineers, so now these all are not my
| problem anymore. I'll do my tinkering in Factorio and Entropy TD,
| and I build as big of a spaghetti as I'd like.
| alberth wrote:
| PHP.
|
| Use PHP, it's so crazy easy for web development.
|
| - No compiling,
|
| - no middleware,
|
| - no state (which also means no memory leaks),
|
| - just drop a file on web server and it works (no crazy CI
| pipeline),
|
| - the documentation is fantastic,
|
| - it's extremely fast, and
|
| - no surprises because it's tried and true.
|
| PHP is so under appreciated.
| super256 wrote:
| > - no state (which also means no memory leaks),
|
| Ehh, what? Sessions are state.
|
| > - just drop a file on web server and it works (no crazy CI
| pipeline)
|
| Except when I have to set-up php-fpm, opcache and configure
| countless parameters in php.ini.
|
| > - the documentation is fantastic,
|
| Yes, but I still have to check it for useless constructs like
| "mysql_real_escape_string" vs "mysql_escape_string" which
| should have never existed in the first place.
|
| PHP didn't earn its reputation without a reason. But I'm glad
| to hear that certain things are improving.
| yrgulation wrote:
| The issue with php is the type of developers that use it and
| bloated frameworks. Nearly all developers still debate wether
| to use setters and getters and have no clue how to use the
| language itself, as a result using over engineered frameworks.
| The language itself is nice but is swamped by amateurs.
| tobinfekkes wrote:
| The "PHP is full of amateurs" trope is so tired.
|
| You know why there are amateurs? Because it's simple,
| understandable, maintainable, low barrier of entry.
|
| You know what amateurs do with simple things and time? Become
| professionals. Then they solve other people's problems,
| rather than solve never-ending developer problems we create
| ourselves.
|
| Having done PHP development for +12 years, I have never once
| had a debate about getters and setters. Nor did I know that
| was something to even debate about.
| yrgulation wrote:
| You are right about the reasons there are so many amateurs
| in the php world. But i disagree with the statement that
| they become professionals over time. If you keep doing the
| same wrong thing over and over you just become better at
| doing the same wrong thing over and over, many being just
| old junior developers. Add the fresh supply of amateurs
| entering the php job market each year and you are stuck.
|
| There are elites among php, you may be one of them, but
| having interviewed hundreds believe me the quality is very
| very low.
| bottlepalm wrote:
| I tried out PHP recently for a project because I have fond
| memories of it, but didn't end up going with it. I want server
| side rendering for the SEO benefits, but I also want some good
| 'app like' interactivity on the page. Doing the app like stuff
| with PHP is possible, but you kind of have to have mirror
| routines, one to load the data, and other api calls to update
| the data using whatever binding library you choose.
|
| The good client side rendered js frameworks, react/svelte/vue
| have SSR solutions, but they also have their own servers for
| enabling SSR - next.js and sveltekit. So if you need SSR, SEO,
| good client side interactivity - you might as well as used
| those pre-packaged servers. You also have the added benefit of
| working in a single language across the stack. Laravel's front
| end recommendations aren't great -
| https://laravel.com/docs/9.x/frontend
|
| I do like how react packages html/css/js as components and that
| you get static typing across the typescript to html bindings
| which makes the code more maintainable. Also react has a pretty
| good front end component library with MUI. You kind of have to
| 'kitchen sink' the front end libraries with PHP as there's no
| compiler to weed out the ones you're not using - plus you need
| to use a CSS library, and 'bring your own javascript' to
| utilize them with where MUI includes everything wrapped as
| components already.
|
| Interested in others thoughts on this.
| jchook wrote:
| Also good about PHP:
|
| - mostly backwards compatible with easy upgrades, even between
| major versions
|
| - many new features all the time for better static analysis,
| type safety, speed, succinct code, etc
|
| - designed for use with Web
|
| - PHP itself is a (good) templating langue, so no need to
| reinvent the wheel there
|
| - FFI interface for integrating native code
|
| - easy to learn
|
| Some downsides though:
|
| - Single threaded with typically blocking I/O and no built-in
| async paradigm means it's like 1/1000 as fast as something like
| node for I/O heavy applications, even when using something like
| ReactPHP
|
| - Need something like FPM to fire up one whole process per
| visitor
|
| - Many core language features like OOP, type hints, lambdas,
| etc are a bolted-on afterthought and still only 60-90% there
|
| - Still no typed resource handles until PHP 9+
|
| - Syntax is cumbersome in many ways, though improving
| icedchai wrote:
| For my freelance work, I did a ton of "old school" PHP (no
| frameworks.) A few years back, I tried Laravel and it was
| incredibly productive.
| mediascreen wrote:
| There are a few things I think you could do about it:
|
| 1. Find somewhere to work were they use a tech stack you feel is
| more appropriate.
|
| 2. Work at a smaller company where you have more say in the tech
| stack and tooling.
|
| 3. Find a company or team where someone else works on developer
| tooling and automation, so you only need to worry about site
| building.
|
| 4. Freelance and specialise in what you enjoy working with.
|
| I work at a small (15 people) web agency where I have a large say
| in what we use. It's surprisingly little React/Vue, a bit of
| WordPress (not everyones favourite maybe) and a lot of backend
| work on APIs and admins in Laravel and plain PHP/HTML with some
| vanilla JS. Only about 10 percent of the clients ever care what
| stack we use.
|
| All of our 60+ projects are setup the same way:
|
| 1. Pull down the repo and run "docker compose up" to start you
| local environment. Any composer or npm commands should be run
| through docker compose, so no local installs (except docker) are
| needed.
|
| 2. Push to staging branch to deploy to staging and merge to
| production branch to deploy to production.
| exabrial wrote:
| Use a component based framework like Primefaces and you'll
| realize you can push code way about 10x faster than a js stack.
| locallost wrote:
| I had an epiphany two years ago when GDPR came into effect. USA
| Today had this fancy page, but to comply with the new law they
| created an eu.* subdomain where they basically just showed
| articles. Text and images and very basic css, not even a fancy
| navigation. It was blazingly fast, just doing normal complete
| reloads between pages. I bet it was even cheap to make. So I
| realized, actually most of these things like SPAs are not truly
| needed, not even AMP was needed, they are just a bandaid on the
| complexity we add ourselves, and the kicker is, the users for the
| most part don't care about any of that. They just want to consume
| your content.
|
| If your heart is still in it, I'd try to learn a skill that will
| be relevant forever. Something that would be a part of a
| university curriculum, not a framework. As others have pointed
| out, other areas of the industry are not necessarily better. An
| anegdote from a colleague there: he was maintaining a simple PHP
| backend where people bought stuff the company was selling.
| Another team built a replacement for this, real engineers,
| microservices, elasticsearch, containers, kubernetes, took
| forever. They switched it on and a week later noticed they are
| having less sales. They switched back to their legacy backend and
| everything was fine again.
|
| edit: also I interviewed a bit last year and it was mostly that
| you'd think people are making space shuttles. You get asked all
| these technical questions, about JS and so, and then when I asked
| about, hey what do you actually do as a developer, what are your
| daily tasks. And the answers are, well we had to recently make
| our gallery page responsive. Sad.
| gjvc wrote:
| _If your heart is still in it, I 'd try to learn a skill that
| will be relevant forever._
|
| Electrician
| wetpaws wrote:
| Good, mor job security for us.
| kyleyeats wrote:
| Don't tell anyone. They'll think you're the problem. Just smile
| and install the latest tooling.
| [deleted]
| WheelsAtLarge wrote:
| This is why new frameworks are created. Someone gets upset over
| X, in this case complexity, and then creates something to fix the
| situation. That's why React came to be. The incompatibilities
| between frontends made it hard to produce a good product so
| eventually we get what we have.
|
| The fix is to reevaluate and start over. That's way harder than
| continuing to use what's available so things continue as they
| have been.
|
| I haven't used React for a while but it definitely made
| developing for different browsers much easier but it you wanted
| to do a simple app it was way harder to use it. It all comes down
| to what you are creating and reaching for the right tool.
| diob wrote:
| The weird thing is, having been in frontend dev since around 2013
| I feel like it's the simplest it's ever been.
|
| I'm more productive than ever, but I suppose mileage varies.
| klyrs wrote:
| I haven't done proper web development in a very long time, but I
| recently did some work with a front-end contractor. I made some
| self-effacing comment about not knowing frameworks and all that,
| and he gave me an amused look and said that he doesn't bother
| with them. He showed me his code, and it was all quite easy to
| read and looked very maintainable. His output is great, and to my
| knowledge we've almost never had post-deploy issues.
|
| In my career, I've witnessed a lot of "framework"-style vanity
| projects (several were my idea). Fewer than 100% of them have
| been boondoggles (but that's the most generous estimate I'll
| give).
|
| Food for thought, you might be better off without.
| npalli wrote:
| >> but I recently did some work with a front-end contractor
|
| All no-framework-needed examples seem to boil down to having a
| simple enough problem needing just one (or few) front end
| developers. Would be good to hear how a larger team (say 10+)
| managed without one.
| coffeefirst wrote:
| 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 try mobile app development, let me know, I've
| never tried but I doubt it's exempt.
|
| Why does this happen? No idea, but it's not lost on me that a lot
| of these things are backed by huge companies with giant piles of
| money who are using them as marketing.
|
| The only thing you can do (besides leave it all behind and open a
| taqueria) is be a voice for simplicity. What are we going to
| build? What tools make sense for it?
|
| The problem I'm running into is a lot of people _expect_ to use
| React in the same way many of us once relied on jquery. So if
| that 's the case and we must use some React, what can I do to use
| it in the simplest and clearest way possible?
| P5fRxh5kUvp2th wrote:
| It happens because everyone wants to imagine they're smart and
| just happen to work for a no name company.
|
| The intelligence is in the end result of the engineering, but
| no one wants their work to be so simple it could have been done
| by a junior.
| Buttons840 wrote:
| > The only thing you can do (besides leave it all behind and
| open a taqueria) is be a voice for simplicity.
|
| You can also learn to leave work at work. Keep your side
| projects simple, if you have any. And rest easy knowing that at
| work the efforts of one person, you, create enough maintenance
| work for two people; enjoy that job security.
| noduerme wrote:
| I just still use jQuery or vanilla typescript when building
| frontends. To me it's so much more readable, and I almost never
| have to worry about newer code not playing well with older
| code. No client has ever even asked me what framework was being
| used. If the software works and the code is well documented,
| the fewer frameworks you use the better.
| invaliduser wrote:
| >Why does this happen?
|
| A lot of people value more enhancing their resume than solving
| problems
| register wrote:
| Simply this
| agumonkey wrote:
| a lot of companies value shiny resume than complex problems
| solved
| tejtm wrote:
| In scientific/academic environments (the only type I can speak
| of) I have sometimes wondered if my fellow computerists have
| complexity envy.
|
| What we need to do is not that complicated but making it so
| distracts from understanding the harder problem at hand while
| appearing to be working furiously.
| bobthepanda wrote:
| This is basically the technical equivalent of bikeshedding,
| which has been known for a while.
| https://en.wikipedia.org/wiki/Law_of_triviality
| michaelchisari wrote:
| | _Why does this happen?_
|
| Because nobody wants to hear "that feature isn't viable given
| our architecture."
|
| So we build systems that can accommodate any possible future
| feature. No matter how unlikely. And no matter how much
| extraneous complexity it adds now.
|
| In order to maintain simplicity you have to _enforce_
| simplicity. And tech business culture doesn 't like that.
| ScottStevenson wrote:
| >Why does this happen?
|
| I wrote about a hypothesis here:
| https://medium.com/@scott.stevenson/how-to-finally-make-some...
|
| Most of us are scared by the ambiguity of actual creative work,
| so unless we are under the threat of deadline, we seek out
| "structured games" to play so that we can put off the anxiety
| of freeform work. These games are:
|
| (1) Tool Game: Researching and setting up tools (2) Learning
| Game: Books, podcasts, courses (3) Maintenance Game: Cleaning
| up our desktop, desk, house, etc. (4) Process Game: Setting up
| new processes and following them
|
| The knowledge that things are actually easy and straightforward
| means we actually need to do the creative part of the work--
| many people are not ready to face that knowledge.
| the-printer wrote:
| > (1) Tool Game: Researching and setting up tools (2)
| Learning Game: Books, podcasts, courses (3) Maintenance Game:
| Cleaning up our desktop, desk, house, etc. (4) Process Game:
| Setting up new processes and following them
|
| I...I...I am triggered by this.
|
| So it's as if, people such as myself are on the hunt for
| artificial positive feedback loops that are functionally
| beautified masks of procrastination. Fueled by, perhaps a
| subconscious lack of confidence, or a sense of ignorance.
| Something to that effect.
|
| So now imagine an entire department, teams, organizations all
| suffering from this? This can explain a lot.
| hakunin wrote:
| I wouldn't write these off entirely. One of their positive
| outcomes is that you get to switch. Switching is important
| so you don't get bored or fed up. Just don't take these
| things too seriously, and don't stick your newfound hype
| into everything. Let things breathe, sleep on them. For
| like a few months or years.
| hooloovoo_zoo wrote:
| I call these games 'using emacs'. (as an emacs user)
| pindab0ter wrote:
| I use Arch, btw.
| adrianmsmith wrote:
| > Why does this happen?
|
| A few answers already but let me add one: Complex technologies
| favour seniors who are capable of understanding the complexity,
| over juniors who might struggle more. And it's seniors who make
| the decisions on what technology to use, so I think it's
| "rational" if they (even subconsciously) make choices which
| benefit them. They don't want to get replaced by cheaper
| juniors.
| plugin-baby wrote:
| I've observed the opposite - less experienced devs tend to
| want to use more complicated and extensive/invasive tech,
| without understanding if it's appropriate or what its
| limitations are.
| deltasevennine wrote:
| >Why does this happen?
|
| I highly disagree with everyone else. This is the answer why:
|
| Because there's no clear or definitive answer to What's best
| the "best" architecture or system for building these things.
| The entire industry is full of people making up stuff without
| anyone truly knowing anything.
|
| For the shortest distance between two points we can calculate
| an answer. there's a definitive optimum. The question of what's
| the best web service is infinitely more complex. The inputs are
| huge in number and even the definition of "best" is complex and
| hard to define... So in short we essentially have no
| mathematical theory for software design and technology that can
| help us define what is "best." It's the same problem they have
| in Art and Design.
|
| So nobody actually knows what is better BUT they think they
| know so they build wrappers around bad technology or they build
| completely new frameworks NONE of which actually provably move
| the needle forward. In fact the needle can move backwards and
| nobody knows!
|
| When something can't be calculated, it's "Designed." This is
| the difference between "design" and calculation. Anything
| that's designed is basically some human wandering around in an
| area almost aimlessly without ever truly knowing what is
| optimum. They just use their gut and find some sort of answer
| that somewhat works. This is the current and past state of the
| programming industry. That is why on some intuitive level we
| can see that a lot of the industry looks like it's moving
| backwards.
|
| Let's say we do have an equation that can take all the
| components that go into web application development and give
| you a numerical rating on how good it is. If we had such a
| model, my best guess is that if we took a system from the past
| and compared it to a system now, the Modern system will
| actually have a LOWER numerical rating.
|
| But that's just my guess. As of now, nobody can truly define
| what that numerical rating represents and nobody knows whether
| some new framework or design methodology actually increases the
| amount of points. We are doomed forever to exist in this
| endless design loop until someone finds a mathematical model
| that can prove and layout the big picture from a quantitative
| perspective.
| johnfn wrote:
| > 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_. The easiest way to motivate this is to
| imagine the kinds of problems that need solving at large
| companies with thousands of employees. They look vastly
| different than the problems of someone like me working on a
| side project by myself.
|
| e.g., TypeScript might not be useful for some single-person
| teams of developers. It's quite useful for teams of around 5,
| and it's unthinkable to work without it in teams of 100+. Does
| this mean that the single-developer team is wrong?
|
| (I'd actually say the same thing about React. If you're a one-
| man team, go ahead, do whatever you want. But if you're working
| with 100 other engineers, god help you if you're all directly
| manipulating the DOM with vanilla JS.)
|
| Most "complex" technology is solving many problems for many
| different smallish subsets of its users at the same time. To
| the average bystander, it can look like the technology has
| gained huge amounts of unnecessary complexity, but it hasn't,
| not really - it's just complexity which isn't directly relevant
| to you.
|
| (OK, and yes, some other technology is just needlessly stupid,
| but...)
| ok123456 wrote:
| Typescript is basically required to keep you from shooting
| yourself in the foot with Javascript.
|
| Type annotation also serves as a form of 'hard'
| documentation. If it's wrong or no longer correct, it will
| make things turn orange in your IDE and make your type
| linting tool go bonkers. Even as a single developer this has
| tremendous benefits. It's much easier to come back to
| something you wrote months/years ago and get back into it
| rather than having to go through each function to see what it
| returns under every situation.
| frankfrankfrank wrote:
| 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.
| bobthepanda wrote:
| Right. React can be the correct tool for some problems, but
| if your problem is your team is not thinking big-picture
| enough to address maintainability, React is not going to
| magically make that better.
|
| Honestly, I don't think it's even that bad for basic
| development (they literally have a CLI command that
| generates a very basic webapp immediately.)
| CodeSgt wrote:
| I agree with the sentiment so this comment is more of a
| nitpick than anything constructive, but I do feel you may
| have missed the mark with the typescript example.
|
| Even if you don't want to _use_ TS in it 's full glory, you
| can just rename your files with a `.ts`, turn strict mode
| off, run everything through the compilation step, and weed
| out a category of simple mistakes from that alone. Add in
| that you can slowly add in certain rules to reach a level of
| strictness as you need and I see no reason how a JS dev would
| be better off writing vanilla JS than _at least_ using TS and
| only running the compile step. Of course, I think taking the
| time to learn and fully utilize typescript the best path
| forward, even those with absolutely no desire to learn it can
| utilize some of it 's strengths by reading the docs for 15
| minutes.
|
| Far from an unnecessary complexity, it's because an
| incredibly helpful tool at all levels.
| johnfn wrote:
| I'm an enormous typescript proponent - I use it every day,
| even for the smallest, most trivial things :) in OP I was
| intending to steelman the anti-TS argument, but maybe I
| took it too far!
| jcparkyn wrote:
| I'm a big TS fan, but for that type of person I feel like
| JSDoc + checkjs would suit them better. That way they don't
| have to deal with the hassle of making TS work with the
| rest of their tolling and build process.
| zackees wrote:
| tomg wrote:
| > Why does this happen? No idea, but it's not lost on me that a
| lot of these things are backed by huge companies with giant
| piles of money who are using them as marketing.
|
| Your whole post is spot-on :)
|
| My two cents on the answer to this question:
|
| - New tools / frameworks / libraries / etc often position
| themselves as "solving" some perceived deficiency of the prior
| generation of that thing. So it can be attractive to want to
| move over to something that solves a pain point. (Whether it
| actually does, or whether it just replaces it with a new pain
| point is another thing...) Monolith to microservices is an
| example.
|
| - At least for me, if I'm starting a new project (especially if
| it's in a space I'm not that experienced in), it's tempting to
| choose what looks to be the simplest choice, which could be for
| example a niche database technology suited for my exact need
| (even if in reality a regular SQL db would be just fine).
|
| - Engineers like to play with new toys!
| kbrannigan wrote:
| 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.
| eddsh wrote:
| Honestly I use bash for this. I keep a local repo of
| .deb/.tar.gz files and scp them onto a machine which makes
| them reproducible. I use uvt-kvm for VMs, config files to
| cover basic settings, and that's basically it. I run a fairly
| decent sized test lab with multiple servers that have to be
| reproducible, quick to edit, and install fairly complex
| toolchains.
| gregjor wrote:
| Set it up once. Snapshot an image (called an AMI on AWS, but
| applies on all cloud services). Use the image to make new
| identical instances.
|
| You can also script the process with (for example) Terraform.
| chrismarlow9 wrote:
| Nearly every company I've ever worked for could get away
| with only using:
|
| - packer for images
|
| - terraform for prod infra
|
| - vagrant for local dev
|
| - pssh for ci/cd and config management
|
| And in some cases I would say they'd be far more efficient
| with this setup.
| skydhash wrote:
| 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.
| icedchai wrote:
| You launch the instance with "aws" CLI, passing it a user-
| data script (cloud config) that does all the things you
| describe with simple shell scripts. You install the app by
| copying it from an S3 location (build output), which is also
| defined in the script.
|
| If you later want to port this into terraform, you can.
| nikanj wrote:
| Heroku or alternatives
| betaby wrote:
| create - terraform, install / manage - cfengine / ansible /
| chef
| aprdm wrote:
| A single ansible yaml
| Eduard wrote:
| All the responses you got so far suggest exactly what this
| "Ask HN" actually wants to avoid: Terraform, AMI, Packer,
| Ansible, Chef ..., the list goes on
|
| Here is my suggestion for keeping it simple, by solely
| relying on skills you will need anyways: git and shell
| scripting.
|
| - Write a shell script that executes all those commands you
| would run manually to set up your system.
|
| - Put up a git repository in the `/` directory, `.gitignore`
| everything by default, and explicitly git-notignore all those
| configuration files and user files/maintenance scripts which
| are relevant for your environment. Use githooks to also
| track/restore file permissions and ownerships of these
| tracked files.
| bingo-bongo wrote:
| There is already many answers to your question and not to be
| rude, but I think it perfectly shows part of the problem OP
| is talking about.
|
| Every single answer goes straight to name dropping various
| specific techs/tools and I don't doubt it really is the most
| simple way for each poster. But I think a much better answer,
| would be a bunch of questions that dig into what kind of
| problem you are trying to solve, what are the circumstances,
| skillset, limitations, budget, is it 1 tiny private app for
| fun or a couple of apps your team or even company depends on
| etc.
|
| Because it depends on the specifics in _your_ situation and
| jumping straight to _a_ solution, without understanding
| _your_ problem, is imho part of the over-complexity-problem
| in our industry.
| hnuser847 wrote:
| > The only thing you can do (besides leave it all behind and
| open a taqueria) is be a voice for simplicity. What are we
| going to build? What tools make sense for it?
|
| I tried to do this at several companies and ended up feeling
| like a pariah. At the end of the day, engineers, especially
| younger ones, like to follow trends, "learn new things", pad
| their resumes, and build bespoke solutions. Trying to fight
| against this will only make you look like a troglodyte or a
| party pooper.
| idlehand wrote:
| As a younger dev I see the opposite in my corner of the
| world. The senior developers spend countless hours debating
| the best design, engineering large architectures to bounce a
| handful of kilobytes of information around in the just right
| way to achieve architectural purity. Then they do greenfield
| development with old tech that is simultaneously somehow both
| old and barely used, as if to generate their own job
| security.
| somehnacct3757 wrote:
| I worked at a company long enough to go from young dev who
| wants to use shiny new tech (and is told no by party pooper
| experienced devs); to the party pooper experienced dev for a
| new group of young devs.
|
| I know I'm right, as I'm now sure the devs telling me no were
| right, but I'll be pushed out same as they were.
|
| Young blood is naive and cheap and plentiful so they will
| always have the momentum advantage. They're the ones that
| promise the moon to other departments and then stay up all
| night covering their tracks when they were wrong.
| unity1001 wrote:
| > Why does this happen?
|
| We humans are creative creatures. When we are doing the same
| thing for a long time, we tend to get bored and make change
| happen. We 'improve' things, we move things about. We 'make
| things better'. So we are not bored anymore.
| yrgulation wrote:
| This stems from the fact that many in web dev are not really
| engineers. There's a lot of reinventing the wheel and cult like
| following of various tech influencers. Instead of extending
| existing libraries people just fork repositories, add minor
| changes, and advertise them as new. A lot of architectural
| patterns are just a soup of concepts thrown around without proper
| planning or understanding of dry or solid.
| erlich wrote:
| A big problem is for anything to be successful it had to be
| similar enough to the last thing. E.g. all the new frameworks
| that look and feel like React. Every new thing is constrained
| and sticky taped onto the older thing. So no one can ever step
| back and ask themselves what the truly ideal thing is.
| mouzogu wrote:
| 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 global workforce who will work for half your
| salary or less. i will get downvoted, probably cos there so many
| bootcampers and others who don't like to hear this reality.
|
| 2. 10% of jobs at top tier tech companies that pay the top
| salaries. good luck with the 10 stage interviews, aptitude exam,
| leetcoding and then getting ghosted.
|
| the complexity itself just comes from the amount of steps
| required to do something trivial:
|
| 2010 edit an html button:
|
| 1. pull the file from ftp or sourcesafe/svn
|
| 2. edit the button
|
| 3. upload to ftp
|
| 2020 edit an html button:
|
| 1. install git
|
| 2. install npm, node
|
| 3. clone and install the code
|
| 4. deal with myriad node js errors
|
| 5. deal with myriad deprecation warnings and other issues in npm
|
| 6. start local environment
|
| 6.1 local requires docker
|
| 6.2 install docker
|
| 6.3 try to start docker
|
| 7. docker requires sudo
|
| 8. request sudo from IT
|
| 9. fill a form explaining why you need sudo
|
| 10. install docker
|
| 11. start the local environment
|
| 12. edit the html button
|
| 13. local server not refreshing
|
| 14. fix local tooling issues
|
| 15. commit changes
|
| 16. your changes are 10 commits behind the branch
|
| 17. try to merge automatically, cannot be merged
|
| 18. make a PR
|
| 19. smug know it all "senior" developer with 2 years experiences,
| gives a bunch of nitpicky comments on the PR and refuses to merge
| it
|
| 20. go back to step 6
| mike31fr wrote:
| 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
| vultour wrote:
| You can't test the 2020 code without Node.
| sliq wrote:
| you nailed it! this is exactly the problem. everything is
| horribly overcomplicated these days. i've 13 years of business
| experience and it gets harder and harder to even set up the
| most simple "hello world" demo of most frameworks. also the job
| market represents this insanity too: 5 years ago I easily got
| senior positions, now i don't even know the words inside most
| job descriptions even in my field. And on top of all, stuff
| like kubernetes, kibana and prometheus now also is often
| expected from a typical backend developer. absolute mayhem!
| erlich wrote:
| It's crazy and impressive how we devs created this fucking huge
| industry where hundreds of millions was spent to solve a
| problem that didn't really exist and actually made things
| harder and more expensive.
| bluefirebrand wrote:
| > 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.
| peatfreak wrote:
| 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.
| jitl wrote:
| 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.
| 9wzYQbTYsAIc wrote:
| Some organizations still haven't adjusted their infosec
| posture to allow git, let alone sudo.
| oneplane wrote:
| I think it's very easy to not work there, just leave and
| don't go back. I suspect most people that stick around
| either don't know any better or do it for the
| money/status/whatever and not for the technology.
| npteljes wrote:
| Come on now. With modern flow, you have to "install git", but
| in ye olde times you don't install svn or ftp? And back then we
| didn't have gatekeeping seniors? And we request sudo now, and
| not back then? I think you got that confused.
|
| Old software sucked a lot, and automation sucked a lot. Weird
| issues where you HAD to know what went wrong, because
| handholding was looked down upon. The lack of automation meant
| that servers were pets, you looked after them, groomed them,
| maybe even sang a song to get the piece of junk going. Modern
| automation means you mostly care about the blueprint, not the
| actual instance. If it's not working properly, you reimage. If
| you need more, fire up more instances.
|
| Also, what can you do on the frontend only? I have two examples
| from the top of my head:
|
| https://www.photopea.com/
|
| https://simplepdf.eu/
| jugg1es wrote:
| I've been doing front-end development off and on for 25 years and
| I still had a moment like this just this week.
|
| A different team updated a library we're supposed to use and all
| of a sudden, the deployed service was crashing on startup (worked
| locally). It appeared as though the problem was some EMCA6 syntax
| wasn't playing well with Babel configuration that seemed fine to
| me.
|
| I got so frustrated that I ended up removing Babel (because it
| wasn't needed to begin with), which meant I had to change all the
| import statements to 'require' and had to change all the export
| syntax to CommonJS. Finally got it working after many hours and
| refactoring...
|
| Except then I realized that the base docker image in the
| dockerfile was node 12 and not 16. If I had just updated the
| dockerfile, I wouldn't have had to remove Babel and would have
| saved myself a day.
|
| Modern front-end development is sort of like child birth. Your
| brain conveniently forgets what it felt like to push a watermelon
| through a straw.
| [deleted]
| didip wrote:
| Frontend development jumped the shark for sure.
|
| Why can't we go back to the old server-side template rendering
| and use progressive JS for interactivity? Just like the good old
| days.
| incrudible wrote:
| You can do that if you're building a website, but people want
| to build desktop-class applications these days, and you can't
| just sprinkle some JS on server-side rendering and make it
| behave like that. Also, the same people with a lot of
| experience in backend work probably aren't that good at
| creating GUIs, and vice versa.
| lhorie wrote:
| I transitioned from product work to platform/dev productivity
| work (think frameworks, internal tools) surrounding the web
| stack, which is a form of extreme specialization. It effectively
| means I'm not directly dealing w/ useEffect stale closure sort of
| crap, but instead I work w/ things like supply chain management,
| CI flakiness and build optimization, which involves developing a
| skillset that doesn't really fit into the "jack of all trades,
| master or one" narrative; it's more like developing depth in a
| wide array of obscure things plus a large dose navigating
| "working groups" to complement a workforce composed largely of
| React experts.
|
| Career growth is currently primarily coming from increased
| internal impact at a large company. In terms of future career
| growth, most of the recruiter spam I get for
| Senior/Staff/Principal roles is below my current pay grade, so I
| expect that further growth will require shifting more and more
| into director track.
|
| </two-cents>
| pcurve wrote:
| Amen. I would even say the same thing about UI/UX design, with
| tight coupling with react components with naming conventions and
| tokens. Overly complex design systems.
|
| It all sounds great in theory, but it comes with so many baggage,
| and only tends to work in certain SV type companies.
| i_like_robots wrote:
| 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.
| ostenning wrote:
| My academic background is Electronic Engineering and embedded
| development but found myself in fullstack and then frontend
| development roles for over 7 years. I began to experience what
| you described, essentially a bunch of hype technologies
| bandwagoned by junior devs and HR recruiters spouting buzzwords
| and insane abstractions, npm dependency hell and glue code coming
| out of my ears. The whole ecosystem is crazy.
|
| The worst part about it is the technical debt that companies
| encounter. Technology should be serving business objectives,
| first and foremost. If your tech-stack is outdated in 2 years
| time, something is really wrong.
|
| I've gone back to EE, hardware engineering and embedded
| development. I think this specialization probably reduces job
| availability, but I can always fall back to webdev in tougher
| times if I have to, and its something to set me apart from all
| the 8 week bootcamp coders flooding into the webdev market
| uhrush wrote:
| Could you give some examples of the complexities you're tired of?
| oneplane wrote:
| It's business-generated complexity, not complexity out of
| necessity. And I don't mean business made the complexity
| directly, but it's an indirect effect of trying to commodify
| developer jobs.
|
| If you have a job posting describing "work on our website" you
| get all sorts of random candidates that have no real place in
| your company, but when you say "developer with framework XYZ
| experience" you can skip everything, judge their framework
| experience and move on (or so it is thought to work).
|
| This means that to be attractive you need to use it as a
| developer, but inside a company this stuff has to be used to make
| sure that the current developer(s) can be replaced easily (not
| how it realistically works beyond CRUD apps), and expanding the
| workforce is easier because attracting developers with technology
| keywords is easier than business job descriptions.
|
| End result: using technology not because it's the best fit, but
| because it is off-the-shelf. Essentially a modern version of
| using Oracle and Windows NT 3.51 back in the day, you're using it
| because it's an easy off-the-shelf keyword, not because it
| actually has anything to do with what you are technically trying
| to get done. Enterprise IT and HR shaking hands all over again.
|
| Some more expansion on this topic (story time):
|
| Generally when you are large enough as a team or business unit to
| have lots of collaboration, you need some way to exchange
| information and ideas, and work together using similar-ish
| principles. That can mean various things, from all using the same
| OS and IDE to having up-to-date API documentation and integration
| tests. This means that if you have to transport some idea,
| project or application across people (and teams) you need a
| method and format to do so.
|
| This nearly automatically also means you can't do solo yolo all
| day and you need to have rules and packaging standards so you
| don't end up figuring out what Pete did on his machine so it
| works on Jack's machine but not Jane's. Chroot-in-a-tarball
| works, virtual machine images, maybe autotools with a bunch of
| setup scripts. But most of the older methods all have the same
| problem: your systems all need to be rather similar to work with
| it, and you need to have systems knowledge to make use of it.
|
| With the expansion of the workforce, that becomes more and more
| scarce, to the point where most Junior and Medior engineers have
| no clue how their computer actually works, how to manage an
| operating system, how how to understand the influence of
| externalities (be it them influencing other teams, or the other
| way around). People with less experience are easier to 'create'
| (yes, I know, we're not _actuallt_ manufacturing people on-demand
| for work), as it requires less affinity, less time, and less
| education resources. So we can get more of them, and as long as
| they are put in an environment where they don 't need to be as
| capable as 'full fat' engineers, the business can keep running.
|
| So, what do we do? We package and standardise. First with
| environments, we have virtual machines, images, packer, and can
| see those local virtual machines with ansible and saltstack and
| if it works there, the project will work on other workstations
| and servers just the same, since it was all provisioned the same.
| No more guessing. But this is a really heavy method of doing
| this, and the greybeards will complain that just using some file
| protocol to directly edit something or a simple jail or chroot
| was much lighter (faster, less resources etc). At the same time,
| from a security perspective, sandboxing stuff gets more traction,
| and with namespaces and control groups we also get docker (pre-
| OCI), which gets a bunch of people excited because you can now
| make transportable environments that are essentially jails, but
| without having to know anything about jails or bsd and it works
| on Linux!
|
| Parallel to this, we get various tools for dependency management,
| mainly derived from the same concepts that drive dpkg/apt and
| rpm/yum, because it worked so well for system packages, why not
| use it for nearly every language under the sun? This gets into
| DLL-hell rather quickly, contaminates the operating system by
| installing packages needed for your projects globally for the
| entire system, so now whenever you switch to a different projects
| you basically have to reinstall. Boo! But luckily someone heard
| of this fancy new container thing and you can just do all of that
| stuff in there!
|
| Now we can simply create those project environments as container
| images (got some real traction once OCI was a thing), so an
| engineer working on some new feature has even less of a
| requirement regarding their skillset. Just hire someone who can
| run docker containers and work on framework XYZ! Tons of those
| available. So instead of having teams with 5 highly skilled
| workers with deep knowledge and a high cost, you just get 3
| Juniors for bulk work, 1 medior for checking their work and 1
| senior that's in that classic "know as much as possible" bucket
| do mitigate any complex issues that may arise.
|
| Fast forward to today, the new greybeards are the senior
| engineers of a decade ago, less and less new people with deep
| knowledge have been added to the workforce, but large masses of
| either highly specialised or shallowly trained people are being
| hired. They are not unskilled, but just skilled for a specific
| piece of the business, because that works for other departments
| so why not IT? And there is a shortage after all...
|
| The now rare and in high-demand deep knowledge engineers are
| tired of getting the same questions for the same architectural
| problems and same business complexities, so they come up with
| software frameworks that they can apply to the problem. It
| doesn't matter if the other team members have a varying gradient
| of understanding of the details of the solution, as long as the
| tickets get closed and added value is perceived by non-technical
| people. Those same people may see those framework names, and
| recognise them in various important places around the business.
| Hiring more people now focuses on making sure that they will be
| able to work with this stuff, because it's what the business is
| already using after all. And to be attractive, new engineers are
| trained to use those frameworks.. and now the cycle just repeats
| itself.
|
| Moral of the story: it's a mix of race to the bottom,
| commodification, shortage and standardisation. That last one is
| important, because using standards is preferred in a risk-averse
| environment, and most businesses are just that.
| solardev wrote:
| 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...!
| nickjj wrote:
| Using React with an API back-end is only 1 of many choices.
|
| There's tools like Hotwire[0] and htmx[1] (both are back-end
| agnostic) that will let you create good old boring web apps with
| any back-end language where you don't need to write a ton of JS.
| You can sprinkle in front-end quality of life enhancements as
| needed to make nice feeling web apps with reasonably minimal
| complexity.
|
| [0]: https://hotwired.dev/
|
| [1]: https://htmx.org/
| intricatedetail wrote:
| From my experience the more exotic frameworks are often pushed
| at smaller companies by developers hoping they'll be hard to
| replace whereas big companies use what s most popular to ensure
| they can find replacements easily.
| winternett wrote:
| Nothing involving React will resolve the complexity issue...
|
| The benefits react provides in functionality (page transitions
| and controls) could have been better addressed within web
| browsers, but the process of web design is constantly trying to
| resolve front end issues in code to suit a wide variety of OS
| versions and browsers, which is where a big problem lies...
|
| i don't have the answers myself, but this urge to use tons of
| different libraries, langs, services, and tools just to build
| web apps, and then the never ending cycle of updating things
| daily to maintain stability and security may make people money,
| but it's really not sustainable in the long run. This is why
| most sites are beginning to be run on platforms like WIX and
| sharepoint, while independent developers and small app
| companies go broke. There is just too much damn complexity
| gumming up everything.
| tobinfekkes wrote:
| Amen
| NotYourLawyer wrote:
| Everything since static HTML has been a mistake.
| jitl wrote:
| I worked in web development for about a year, then switched to
| general devtools and CI/CD, then to infrastructure orchestration
| work on deployment, Kubernetes, service proxies, deployment.
| After that I joined a startup and worked on backend, mobile apps
| (Android), and now I'm back to working on complicated frontend.
| dudul wrote:
| It happens on the backend too. For the infrastructure too.
| Honestly, maybe unpopular opinion but it's why I went into
| management. I was just tired of gluing together dozens of
| libraries to parse/format data around and deal with this crap.
| karaterobot wrote:
| > Has anyone either switched from doing web development type work
| to something else they enjoy more for similar reasons?
|
| Yes, I quit being a FE developer in 2019, after around 13 years.
| There were a few reasons, but one of them is just what you
| describe. Looking ahead to the rest of my career, I knew I wanted
| to make things and not be a manager, but I could not imagine
| myself living in the world that front end development had created
| for the next 20 years and also being happy.
|
| In my case, I had been a hybrid developer / designer for most of
| my career (as a contractor, I juggled roles based on what the
| client needed). So, my mid-career change was that I just switched
| to not doing contracting, and only doing design.
|
| It's not that I enjoy design more than programming, but I do
| think it's a more sustainable path. I never used to program in my
| spare time, but now I do it a lot because I miss the fun parts.
| I'm sure as hell not doing React on the weekends, though.
|
| The design world has its own frustrations, but so far I think it
| was a great choice.
| carom wrote:
| I just use Go for a self contained back end and server. For the
| front end I use the html templates, but for the most part it is
| traditional html, css, and js. No compiling js.
|
| That said, I primarily work in other areas. This is just for when
| I need a web app.
| kim0 wrote:
| I'm trying to do the same. How do I make a kinda pretty
| frontend without much effort though
| [deleted]
| hnuser847 wrote:
| I feel your pain. My career happiness peaked around 2014 or 2015,
| when I was writing Rails monoliths. I felt like I could focus
| 100% of my energy on business logic since the framework was so
| opinionated and the stack was simple. Things went rapidly
| downhill after that, once microservices, SPAs, node.js, NoSQL,
| and serverless computing started becoming popular. Everything
| just felt like a step backward. Microservices made simple things
| (like transactions) impossible. Express felt like a degraded
| version of Sinatra. NoSQL, frankly, is utterly pointless, and I
| have no clue why it ever caught on. Serverless computing is
| interesting in some respects but the places that I've worked that
| have gone all in on AWS were total disasters. SPAs are definitely
| useful for rich, interactive front-ends, but the trend to make
| everything a SPA and render everything in JS is totally nuts.
|
| I ended up switching to a PM role, where I can focus on the
| business problems without having to worry too much about the
| implementation. I do miss coding a bit, but it's not fun enough
| to do full time anymore.
| globular-toast wrote:
| I still work on a Django monolith and agree on being able to
| focus 100% on business logic. I've found Angular is excellent
| for "sprinkling" a little JS into the frontend where necessary
| rather than going the full SPA/React route.
| nakatu wrote:
| How is Angular adding just a sprinkle of js to your web app?
| Isn't the ouput of building an Angular app a full SPA?
| linux2647 wrote:
| And I think that's why some stacks like Hotwired and Phoenix
| have decided to let the server handle a bunch of common JS use
| cases so that you don't need some all of the frontend
| complexity like with React
| mhuffman wrote:
| >NoSQL, frankly, is utterly pointless, and I have no clue why
| it ever caught on.
|
| It caught on because "feature factory" startups used simple
| frameworks to make an MVP and didn't know shit about RDBMS
| administration, optimization, or schema planning so when it was
| schema migration time it was time for things to start breaking.
| With NoSQL (specifically the "document store" types) you could
| just keep throwing shit in there whenever you needed it --
| magic schema migration! And it was "Web Scale"(c)!
| erlich wrote:
| Spot on. Rails just let you get shit done. All we needed was a
| Rails for Node.js.
| mfontani wrote:
| https://mojojs.org/ might just do the trick?
| tasubotadas wrote:
| I think you should try out Angular. React ecosystem is a mess and
| needs extremely experienced developers to produce software that
| doesn't suck.
|
| Angular, on the other hand, it's quite simple and helps you to
| get the shit done.
| [deleted]
| joeblow21 wrote:
| pjmlp wrote:
| I focus on backend and native GUI development, when required to
| do Web GUI development vanilaJS + SSR are my tools for the last
| 20 years, I leave the deep knowledge of the FE framework of the
| day to the FE teams.
|
| To this day I have been lucky to always been able to find
| something, maybe because I've always embraced a polyglot toolbox
| and not being int a silo as XYZ Developer.
| throwaway0asd wrote:
| Then stop using these large frameworks. You don't need them. They
| aren't there to build your product for you. They are there to
| ease hiring.
|
| When you return to vanilla JS you have the freedom to
| dramatically reduce your code size and increase performance.
|
| See this comment upvoted 27 times:
| https://news.ycombinator.com/item?id=32914694
| butz wrote:
| Not that there might a a huge market for it, but I'm going to
| attempt provide "least complicated solution" service to potential
| clients. While results might not look very fancy or have many
| animations, client will get working website faster and cheaper,
| and their customers will actually get superior experience, as
| website loads fast and doesn't do annoying things. Wish me luck.
| jt2190 wrote:
| It sure looks like we're nearing the "peak Java Enterprise
| Edition" moment for frontend web development space.
|
| We got here honestly: Single Page Apps made "fat" clients
| possible in the browser, but that meant a lot of logic had to
| move to the front end, so they naturally became bigger and more
| complex. Meanwhile, we still want to have the "lazy installation"
| experience of browsing to a web page and having things load
| quickly, and this adds all sorts of complexity like bundle
| splitting, hydration, "edge" hosting, etc.
|
| I'm not sure where we go from here, complexity-wise, but here are
| some guesses:
|
| * no/low code will produce a new "ruby on rails" for the modern
| SPA space. (There are already contenders.) * increased
| environment complexity will move development into the cloud and
| off of our local machines. * there won't be a sudden
| disappearance of the older approaches, just like SPAs didn't kill
| RoR.
| stavros wrote:
| I think we'll just go back to the old approaches. I already
| build apps with thin frontends, and maybe use HTMX if desired.
| Fat frontends aren't worth the complexity unless you have an
| interactive app (e.g. Google Docs), which you very probably
| don't.
| andrejandre wrote:
| Yeah web development went from being a passion to just being a
| job where I now feel like I just play the complexity game with
| teammates, managers, and stakeholders.
|
| I don't care about this stuff anymore. I only care about the
| paycheck.
|
| Yeah, the technology is cool... we do Docker containers... so its
| a 'microservices' web app with a remote registry for our
| containers plus a bunch of disgusting npm packages and weird
| frontend react client bloat.
|
| I prefer my side-projects. They are succinct and concise. No
| bloat. Just DIY simplicity.
| hdufort wrote:
| I was active in web application development three times (1999,
| 2007 and circa 2010). Every time, I was horrified by the number
| of patches, workarounds and conditional code that were needed
| when doing "pure" web development. But at the same time, every
| application I developed was a little easier than the previous
| one, for four reasons.
|
| First, the evolution of the web was pushing away the technologies
| that were the heaviest, most marginal and least standardized. I'm
| talking about ActiveX, Applets, Netscape frames, etc. The gradual
| elimination of these technologies was made possible by evolution
| of HTML and CSS towards more functionalities.
|
| The second reason was the gradual standardization of key elements
| in web application rendering and execution. JavaScript behavior
| and functions, DOM structure and events, CSS element size
| calculation, etc. This standardization made it much easier to
| write code that "mostly" works cross browser.
|
| Third, the modern web development frameworks and libraries. These
| contain the convoluted conditional code that you really don't
| want to write every time you want to implement something. Plus,
| once you've written your code, you don't have to completely
| revisit it every time a new browser version is released. I once
| wrote a nice website with drop-down menus which worked fine on
| Firefox and IE6 and IE7. Yay. But then, it was broken in the new
| version of IE. And then, Flash contents became "first layer" and
| opaque, and so the menus were rendered behind the contents. The
| amount of work I had to spend every six months to keep it running
| was not worth it. If I had used a popular framework maintained by
| the community (which were a little less common back then), it
| would have been less frustrating.
|
| Fourth, mobile-friendly websites. The success of tablets and
| smartphones in the 2010s pushed web developers to have a
| simplified, more streamlined version of their websites available.
| Eventually, this had a major influence on the "PC" version of the
| same websites. Today, most websites have lots of functionality
| and interactions, but they're also simpler, the pages are
| shorter, there's less screen size conditional rendering, less
| overwhelming animations and extremely convoluted layouts.
|
| All that to say... Web development is not as crazy and
| frustrating as it was just 10 years ago. One of the problems I'm
| seeing is that many designers still think in terms of fixed
| screen size, and full screen animations, and try to cram
| everything on the same page. These are really bad design
| patterns. Sure you want to dazzle you client with your HTML5
| powess and ability to design gorgeous contents. But in the end,
| visitors and customers will be put off by imperfectly supported
| features, long load time, resource heavy rendering, clunky in-
| page scrolling, non-touchscreen-friendly buttons, and poor
| ergonomics in general.
|
| Most sites that are a nightmare for the developer are also a
| nightmare for the users. In some cases, just reminding the
| designers they a load time should be under 2 seconds on a 4G
| connection might be sufficient to calm down their hubris.
| hdufort74 wrote:
| I was active in web application development three times (1999,
| 2007 and circa 2010). Every time, I was horrified by the number
| of patches, workarounds and conditional code that were needed
| when doing "pure" web development. But at the same time, every
| application I developed was a little easier than the previous
| one, for four reasons.
|
| First, the evolution of the web was pushing away the technologies
| that were the heaviest, most marginal and least standardized. I'm
| talking about ActiveX, Applets, Netscape frames, etc. The gradual
| elimination of these technologies was made possible by evolution
| of HTML and CSS towards more functionalities.
|
| The second reason was the gradual standardization of key elements
| in web application rendering and execution. JavaScript behavior
| and functions, DOM structure and events, CSS element size
| calculation, etc. This standardization made it much easier to
| write code that "mostly" works cross browser.
|
| Third, the modern web development frameworks and libraries. These
| contain the convoluted conditional code that you really don't
| want to write every time you want to implement something. Plus,
| once you've written your code, you don't have to completely
| revisit it every time a new browser version is released. I once
| wrote a nice website with drop-down menus which worked fine on
| Firefox and IE6 and IE7. Yay. But then, it was broken in the new
| version of IE. And then, Flash contents became "first layer" and
| opaque, and so the menus were rendered behind the contents. The
| amount of work I had to spend every six months to keep it running
| was not worth it. If I had used a popular framework maintained by
| the community (which were a little less common back then), it
| would have been less frustrating.
|
| Fourth, mobile-friendly websites. The success of tablets and
| smartphones in the 2010s pushed web developers to have a
| simplified, more streamlined version of their websites available.
| Eventually, this had a major influence on the "PC" version of the
| same websites. Today, most websites have lots of functionality
| and interactions, but they're also simpler, the pages are
| shorter, there's less screen size conditional rendering, less
| overwhelming animations and extremely convoluted layouts.
|
| All that to say... Web development is not as crazy and
| frustrating as it was just 10 years ago. One of the problems I'm
| seeing is that many designers still think in terms of fixed
| screen size, and full screen animations, and try to cram
| everything on the same page. These are really bad design
| patterns. Sure you want to dazzle you client with your HTML5
| powess and ability to design gorgeous contents. But in the end,
| visitors and customers will be put off by imperfectly supported
| features, long load time, resource heavy rendering, clunky in-
| page scrolling, non-touchscreen-friendly buttons, and poor
| ergonomics in general.
|
| Most sites that are a nightmare for the developer are also a
| nightmare for the users. In some cases, just reminding the
| designers they a load time should be under 2 seconds on a 4G
| connection might be sufficient to calm down their hubris.
| erlich wrote:
| I was thinking the same thing recently. I've finally realized
| that React is painful and overly complex. I just followed the
| crowd and got too deep. Backbone was elegant and simple. I could
| step through all the code being executed with my debugger. React
| is impossible to step through and the error messages are still
| terrible. It's like an entirely new programming language and
| runtime. This "it's just javascript" bullshit is so far from the
| reality now.
|
| There is sooooo much you have to think about when writing a good
| React component with hooks and to ensure it remains performant
| and is bug free.
|
| I really want to go back to basics. Using as little framework as
| possible.
|
| I'd much rather something simple that I have full control over
| and that I can trace the entire execution with a debugger than
| all this magic crap.
|
| I don't even like JSX. I always pass an object in like: '<Foo
| {...fooProps} />'. Would much rather just use a literal js
| object.
|
| I feel like React is a lot like dependency injection frameworks.
| The initialization code you would have to write without using one
| is actually very simple and straightforward.
|
| Is it really that difficult to manually render components as
| needed? Do we actually need this huge runtime vdom overhead? Or
| any of these other compilers/transpilers.
| sebastianconcpt wrote:
| I feel you. I feel this since 2014 actually. Same exact DX -
| Developer Experience.
| threatofrain wrote:
| React tooling is only getting easier, esp. considering anyone
| coming from the age of Webpack. The recent wave of framework
| innovation has been about DX by bundling things together into one
| cohesive experience. Also, nobody is required to keep up with the
| bleeding edge unless you're a framework author trying to
| breakout. If you don't like the marginal benefits provided by
| some performance story in React, then don't do it.
|
| There are also more easier-than-Heroku competitors than ever.
| ruduhudi wrote:
| Web development is complex and has always been. 15 years ago
| you'd deal with complex hacks to work around the table based
| layout mess, the horrible browser APIs, javascript's prototype
| inheritance, Apache configuration and, god forbid, networks of
| .htaccess files.
|
| 10 years ago you'd deal with communicating stuff between language
| borders, what interaction to handle in javascript, what in
| ruby/php/perl/whatever and how to interact between the languages.
|
| Now you deal with build processes, transpilers, bundle size
| optimization, framework configuration and broken react state
| updates.
|
| It's intrinsically complex, deal with it.
| ackatz wrote:
| There is a huge shortage of developers on corporate information
| security teams. Many organizations' CorpSec teams spend an
| egregious amount of time toiling in manual processes. In infosec,
| that is why you constantly hear of burnout.
|
| If you wanted to switch into information security as a developer,
| many well-paying, well-known orgs would welcome you in with open
| arms in some kind of automation developer role. I have never felt
| better about my job prospects.
| register wrote:
| This is very interesting. Where can I start and learn more
| about it?
| ackatz wrote:
| This article is a really brief primer on this line of work. A
| lot of it is working with Python, JavaScript, APIs, and
| building custom solutions to get different COTS security
| tools and things like Jira to talk to each other. It may not
| be for everyone but I really enjoy it.
|
| https://www.cadosecurity.com/the-next-in-demand-job-title-
| se...
| jwmoz wrote:
| Server side rendering ftw
| jelan wrote:
| A couple people have asked what complexities I'm referring to and
| mainly what I mean is just how much bloat goes into making
| anything, and at a higher level the general course of action
| seems to be to just keep adding to the system until you get what
| you want out of it instead of trying to fix or improve underlying
| problems with the web.
|
| I know we can't just pause the internet while everyone comes to a
| consensus on how we want to make it more interactive and fix
| underlying problems, but at least to me it seems like all the
| effort that could be spent working towards that is instead being
| spent figuring out ways to just avoid as much of the underlying
| pieces as possible by jamming your own implementation on top of
| it.
|
| I agree that getting setup and using things like React or Node
| for a backend is easy, but the number of dependencies, size of
| the app, tooling needed, memory used are all going to grow
| exponentially as soon as you start trying to do something non
| trivial, and the solution to fix these problems is yet again to
| add more complexity, where you will need to learn a lot more
| about how all of those nice tools that just worked for you out of
| the box are actually working
|
| This isn't a React or a frontend specific example entirely, but
| I've seen many people jump into creating a simple app and right
| off the bat implementing a federated GraphQL design because of
| all the great things they heard about GraphQL from the community,
| which is fine but a very simple REST design would have worked
| just as well if not better and would be in my opinion much
| simpler to maintain and manage complex things like caching.
| xd wrote:
| I bumped into an old friend recently and he and his wife work at
| a real estate company. They were raving about this new system
| they are a couple of years into the development of and how it's
| built on this great "Kubernetes" system.. they asked what I
| develop my products with and I almost felt embarrassed to say PHP
| and a couple of servers in two locations for redundancy that run
| Archlinux with a LAMP (LNMP? I guess with NGINX/MariaDB these
| days) stack .. same thing I've used for 20 years now (I was one
| of the first AL volunteers). When I asked what language their
| system is developed in they said Kubernetes, of course.
|
| Anyway, it kind of reminds me of the days when everyone was
| developing a PHP Framework .. I've never used one and if I was to
| apply for a PHP job I'd be unlikely to succeed as I'm very
| specialised in getting shit done.
| yrgulation wrote:
| 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.
| xd wrote:
| 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).
| bottlepalm wrote:
| 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.
| xd wrote:
| It's just my opinion based on 20+ years of developing
| data management solutions across thousands of customers..
| any framework employs a set of beliefs and that creates a
| box you are constrained to think in, hell SQL is one of
| them boxes. You say "They're not a replacement for being
| knowledgeable in SQL whatsoever." .. so what are they
| then?
|
| Edit: I once spent/wasted almost 2 years of my life
| trying to develop the ultimate ORM. In the end I replaced
| it for a simple directory structure of API end points
| where every .php file does a specific job with good old
| SQL queries in there.
| stavros wrote:
| They're a convenience for 99.9% of use cases. For the
| other 0.1%, I write SQL, but to be honest, I've never had
| to yet.
|
| You can deliver business value with boring glue code.
| xd wrote:
| So you have 0.1% SQL skill .. work on it.
| stavros wrote:
| Actually a flat 0%.
| yrgulation wrote:
| Well, that the issue with php devs.
| stavros wrote:
| Oh I don't know any PHP, sadly. That's probably another
| issue with us.
| yrgulation wrote:
| You think you did a funny but you'd be surprised how many
| php devs dont know php.
| stavros wrote:
| Oh, all of them.
| yrgulation wrote:
| There is merit in this - once a php dev does get to know
| the language they move away to other languages. So you
| are indeed left with people that dont know the language.
| bottlepalm wrote:
| Not sure if you've used Entity Framework, but you can do
| compos (with logic) amazing complex queries with
| relatively little code in a way that is statically typed
| and super easy to maintain. I'm talking about pulling
| heavily structured data from the database without having
| to pull from flat tables and structure it yourself server
| side.
|
| Also working with databases with thousands of tables and
| relationships, hundreds of developers, weekly database
| schema updates, etc..
|
| We still use raw SQL, stored procedures, jobs, profiling
| to understand current db hotspots, etc.. ORMs have their
| time and place just as everything else.
| yrgulation wrote:
| But you can already write amazingly complex queries in
| sql, and structure them as objects directly using pdo. If
| there are hundreds of developers working against the same
| codebase then that codebase is too large. If you need to
| query hundreds of tables in one go you need to consider
| denormalisation or using a document storage.
| bottlepalm wrote:
| The ORM code will be 10x smaller than the generated SQL,
| especially for structured data and composing queries.
|
| Not to mention that static typing which is going to
| ensure your query is valid when the code compiles, no
| typos. Plus maintainability of finding all references of
| tables/fields. Plus the ability to quicky refactor all of
| that. Plus mapping to DTOs.
|
| I didn't even get into entity tracking which is a whole
| other heavily used huge use case for an ORM.
|
| I feel like someone debating the merits of Typescript 10
| years ago. Raw SQL is a mess to maintain for the same
| reasons.
| xd wrote:
| Can you show me an example of the 10x less code?
| bottlepalm wrote:
| You're going to get a huge reduction in code for all
| sorts of things, especially when navigating multiple
| relations, grouping, sub-selects, etc..
| var results = db.myTable .where(x => x.value > 6)
| .where(mySpecialConditionalLogicFunction)
| .select(x => { thing =
| x.relation.relation.relation.value, thingList2
| = x.relation.relations .groupby(y => y.value)
| .select(g => g.count) .orderby(y => y.value)
| .take(5), thing3 = x.relations
| .where(z => z.relation1.value < z.relation2.value)
| .select(z => z.relation.value) .max(),
| thing4 = myReusableSelectDTOfunction, etc..
|
| The sql for this would be very dense, hard to
| read/maintain. Especially when building structured
| objects, grouping, filtering etc.. Those composable sub-
| select functions often build common dtos which ensure the
| same structured data is sent regardless of the api. And
| if the dto is updated, all queries inherit it
| automatically.
| yrgulation wrote:
| This brings fond memories of my early stages where i
| became fond of the method chaining pattern. I became
| fascinated by it when using doctrine.
|
| However the code you pasted is horrible and easily
| replaced by sql. Not only does someone else need to learn
| your custom logic functions and dtos but they also need
| to read stuff like " x.relation.relation.relation.value".
| I see your point in regards to dtos "automagically"
| updating queries, but if you have queries laying around
| everywhere thats another code smell. Basically, this is
| solving artificial problems.
|
| The code you pasted can be replaced by a trivial query,
| which should table columns be renamed (i mean whats the
| frequency of that anyway, potentially another code
| smell), it would take less to update than updating all
| the dtos custom functions and the sausage code.
|
| Edit: i am not belittling you, my point is that the code
| above solves self inflicted issues that could be written
| in a basic sql query with bound params. Basically you
| spend twice as much to write and maintain code that is
| simply not necessary.
| bottlepalm wrote:
| Take a single line from my example
| 'x.relation.relation.relation.value'
|
| The SQL would be select w.value
| from x join y on y.relation=x.relation join z
| on z.relation=y.relation join w on
| w.relation=z.relation
|
| 1 line for the ORM, 5 lines of SQL. Please give an
| example where the SQL is less than what I typed in the
| previous comment.
|
| In addition compiling will validate the ORM code
| generates valid SQL. On the other hand compiling will not
| validate a SQL string.
|
| 'Custom functions' are just larger versions of the
| anonymous functions in my example. Very easy for other
| developers to go to the reference and understand.
| yrgulation wrote:
| Hold on, we are talking php here. There is no code
| compiling.
|
| Either way what you are describing sounds like instead of
| maintaining sql code you prefer maintaining orm code.
| DTOs are just overhead.
|
| I gave up on all these after 15 years of using them
| because the benefits are precisely zero (except for
| migrations). Similarly with typescript, if you are
| competent enough with js and as a programmer you dont
| need it. The web can overkill itself perfectly fine
| without a scripted language that transpiles to a scripted
| language.
|
| Perhaps its just me, i rarely make typos and when i do
| the linter or ide catches them early on. In highschool
| they made us keep track of variables and their types with
| pen and paper and as a result i always know what type my
| var is. I was also taught that just because you can it
| doesnt mean you should. So i dont write a dto for
| transferring an object to a different api. It's just a
| waste of time, specific to PHP devs.
|
| Edit: the type of code you pasted is horrible to
| maintain. You can achieve that with less sql.
| bottlepalm wrote:
| With hundreds of developers and millions of lines of code
| - yes Typescript and ORMs will completely eliminate
| entire classes of bugs, and be a force multiplier when it
| comes to productivity.
|
| You should never rule out a tool as 'unnecessary' even if
| you can't think of any possible reason for it. Try to
| keep an open mind here, you may not know everything.
| yrgulation wrote:
| Totally agreed re keeping an open mind. But after having
| used all the niceties you describe i understood that php
| itself is a fractal of poor design and practices. Gave up
| on using literally everything you described and ended up
| writing better code at a fraction of the time.
|
| I do recommend reflecting on things as not knowing
| everything goes both ways.
| bottlepalm wrote:
| I am concerned how much your posts center around you
| writing code and not a team. Are you concerned about
| maintainability? Have you written software with large
| teams before and have had to maintain that software over
| a number of years?
| yrgulation wrote:
| All good code starts with the individual. In the PHP
| world it starts with the collective, not much room for
| creativity on the assembly line, and any such attempts
| are met by endless debates over petty code reviews - many
| of which can be replaced by linters.
|
| Of course i wrote in large teams, thats why i know that a
| large codebase with hundreds of people working on it is
| usually a sign of either bad practice (the monolith that
| grew too much) or high turnover (php work places are
| often toxic and filled by mediocrity).
|
| Instead of ignoring my advice on maintainability,
| consider breaking your code into smaller chunks and write
| less code that doesnt solve self inflicted issues (ie
| your complex queries across hundreds of tables, dtos that
| dont solve much, custom functions for stuff that can
| already be done in sql). Once you do the above you wont
| need all of the overhead you describe and so specific to
| php.
|
| My code usually lasts a good number of years, often even
| after i'm no longer working on it. It's difficult to
| break and easy to maintain. At least thats the feedback i
| get from repeat clients. The teams i lead have easily
| delivered code that generates returns in the billions.
| All without the mess you describe.
| yrgulation wrote:
| But "what if we switch to a different database engine"? Yet
| i've never seen that happen!
|
| Edit: wait smarty still a thing!?
| xd wrote:
| I used Postgres when I first started out in ~2002 but it
| was slow, really slow, I switched to MySQL and it was
| fast and the customers happy. The MyISAM table engine was
| shit hot(fast) but it took me years to get my head around
| constraints and then indexes etc to actually get a basic
| level of competence and realise MyISAM was a bunch of
| trade off's for performance. Anyway I loved PG and still
| do romanise it.. what if I stayed.. what could have
| been.. but it didn't get the job done, for me.
|
| Edit: oh yeah Smarty is still a thing and so is
| PHPClasses.org whilst I think about it.. I've nothing
| against PHPClasses apart from it tries to pass itself off
| as something other than it is.. an amateur coders
| exchange.
| dimmke wrote:
| >I've hit a point where it just doesn't seem like the end
| justifies the means in the vast majority of cases anymore
|
| I agree, but the only path forward is to change the
| specifications for HTML/CSS/JavaScript.
|
| As an industry we need to accept that these technologies get used
| to build web pages as well as software and adjust. This will
| remove a ton of the tooling. I think there are 3 basic things we
| could do to solve this:
|
| 1. Add dynamic interpolation to the HTML spec. This stops every
| framework from having to invent it's own version of it. 2. Update
| the DOM api to allow data binding/state and improve the Web APIs
| around routing/history to make SPAs even easier. 3. Update the
| HTML spec to allow for semantically describing user interface
| elements of software applications.
|
| But it's going to be a hard sell. I am slowly writing a blog post
| about this, but I'm not sure I will be able to get anybody to
| listen. I feel like now, when we're in a browser monoculture
| where the browser vendor is actually competent is the perfect
| time to push this stuff through.
|
| BTW: You can put your email in at daniel.do to get emailed when I
| release my post.
| MrStonedOne wrote:
| akrymski wrote:
| I think what we need is a new spec that compiles down to
| whatever HTML/CSS/JS/WASM is supported by browsers over time.
| Waiting for browser vendors to agree on a new spec takes far
| too long.
|
| The same thing happens in all of comp-sci: we create a new
| programming language that compiles to an old language (C to
| Assembly) because changing the old one takes longer than
| inventing a new one.
| dimmke wrote:
| Ultimately, that's what all these different frameworks
| actually are though. Look at how many different languages
| over the years have compiled down to JS? CoffeeScript,
| TypeScript, Elm. And all the frameworks that have smoothed
| over the native DOM API: React, Angular, JQuery, too many to
| list.
|
| They all implement these concepts in Javascript. But if we
| don't standardize and allow browser vendors to implement at a
| lower level, we will always be taking a speed hit and on the
| framework treadmill. We need to take what we know works and
| do it.
| akrymski wrote:
| Sort of, but React is not a language. It's a runtime lib.
| JSX is not really helpful - still writing HTML and CSS.
|
| TypeScript has been very useful and successful but it
| hasn't touched the UI stuff.
|
| We need a better alternative to HTML and CSS. With WASM any
| language can now be compiled to run in the browser, and
| it's a matter of time until WASM integrates with the DOM as
| well.
|
| This isn't web specific. Desktop UI APIs change frequently
| too. UI is hard, and only higher level of abstractions can
| simplify things.
| dimmke wrote:
| >Sort of, but React is not a language. It's a runtime
| lib. JSX is not really helpful - still writing HTML and
| CSS. TypeScript has been very useful and successful but
| it hasn't touched the UI stuff.
|
| That's my point. The main thing that JSX does is address
| that you can't do conditional rendering or interpolation
| with HTML. It's the same with literally all of these
| other templating languages. Blade, Jade, Handlebars,
| Mustache, the list goes on and on. Typescript literally
| exists to address a deficiency in JS.
|
| I don't think reinventing the wheel is the answer - it
| should taking these clear improvements and adding them to
| the core product. A big part of why technologies become
| popular is because of how accessible they are to newer or
| less knowledgable developers. I don't think some new idea
| would work, we should work with what's already there. I
| don't think there's any fundamental flaw in HTML, CSS or
| JS that necessitates a complete replacement. Just
| adjustments.
|
| HTML's purpose is to semantically describe content. I
| don't see how that is at odds with describing the user
| interface for software vs. a web page.
|
| CSS can lay things out great. It used to be a pain, but
| flexbox/grids have made it easy now.
|
| JS is the most popular language in the world. If we added
| a "types" mode that just adds the typescript syntax and
| lets you set a flag for it, it'd be even better. We don't
| need a new programming language for people to learn.
|
| See, that's where we differ. I think HTML and CSS are
| great. They just need to be improved.
|
| >This isn't web specific. Desktop UI APIs change
| frequently too. UI is hard, and only higher level of
| abstractions can simplify things.
|
| Yeah, and if you look at the popularity of electron apps
| it's pretty clear that people prefer doing this stuff in
| HTML/CSS/JS, even with all the hacks than trying to learn
| platform specific stuff. I'm arguing with tweaks, we
| could do it AND have it be performant and not a pain in
| the ass.
| akrymski wrote:
| HTML and CSS were not designed for building software.
| There's a reason it's nearly impossible to implement a
| web browser from scratch these days. The spec is an
| ancient monster. Adding more layout options to CSS
| doesn't simplify things, but only complicates. How many
| ways are there to layout stuff these days? Try explaining
| flexbox to a newbie.
|
| HTML was meant for hyperlinked documents. It may be ok
| for that, but it's inappropriate for apps. Who cares
| about semantic meanings of DOM nodes in an app?
|
| I don't think people prefer web dev to desktop dev, but
| really there's no choice if you need to support multiple
| OSes. Swift UI is a much more consistent development
| experience for example. Visual Basic was that for
| Windows. But cross platform? The only real target there
| is Skia.
| robin_reala wrote:
| Number 3 is the ARIA spec right? You should be using that
| already if you're writing accessible applications.
|
| https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
| dimmke wrote:
| Here's what I don't understand about the ARIA spec - and
| maybe you can help clarify it for me. Why are we using
| attributes instead of element names?
|
| Like take this for example: https://developer.mozilla.org/en-
| US/docs/Web/Accessibility/A...
|
| Did we just give up on using semantic elements? People barely
| know how to write regular HTML anymore, and the ARIA spec is
| confusing. I'm glad it exists, but to me it fits into the
| same category as "Web components" - a bad idea that isn't
| widely adopted because it sucks.
| an1sotropy wrote:
| Can you say more about why "it sucks"? Are there some
| specific changes you can think of that would have made it a
| less bad idea?
| dimmke wrote:
| 1. It's confusing. The fact that there's a "role"
| attribute that is implicit sometimes and needs to be
| declared other times and a "aria-XYZ" set of attributes
| is stupid. The purist HTML take was always "Markup should
| describe content" - now we're describing content with
| attributes?
|
| 2. It's positioned specifically as being for
| accessibility. This is bad for several reasons. First,
| it's not necessary. The entire goal of semantic markup in
| the first place was to make it so that the content of
| documents can be read by machines (both screen readers
| and other systems) - tacking on a special system just for
| accessibility is basically them giving up on this
| entirely. Secondly, a lot of people don't care about
| accessibility. Like I said, in our current system people
| barely know how to write HTML. Or they write some
| bastardized version of it in JSX or w/e. You think
| they're going to learn the intricacies of ARIA? No.
|
| The goal should be for HTML to be a language that when
| written properly is accessible by default. Not just "hey
| everybody it's cool if you use divs for everything, just
| make sure screen readers know what it's supposed to be."
| tonightstoast wrote:
| Please write the blog post. It may be a hard sell but think of
| it more as a creative conversation with the future of web dev.
| While you may not get the final answer "correct", your post
| will help the community progress a much needed discussion.
| dimmke wrote:
| Thanks, and I will. It's at about 3000 words and I have been
| sitting on it, but I think I am going to just finish it up
| and release it and see what discussion it generates.
| jelan wrote:
| Please share it when you are done!
| naasking wrote:
| > Add dynamic interpolation to the HTML spec. This stops every
| framework from having to invent it's own version of it.
|
| Not sure what this means exactly
|
| > 2. Update the DOM api to allow data binding/state and improve
| the Web APIs around routing/history to make SPAs even easier.
|
| Something like AlpineJS built-in?
|
| > 3. Update the HTML spec to allow for semantically describing
| user interface elements of software applications.
|
| ARIA roles kind of already do this.
| dimmke wrote:
| My post will expand on all of this in detail, including
| addressing ARIA.
| dtx1 wrote:
| Finally someone is saying it openly. The Web is amazing, the
| softwarestack powering is horrible.
|
| Just imagine for a second we were to start from scratch.
| Imagine an HTML/CSS Spec thats easy enough to implement so that
| we have multiple independent vendors with competing, correct
| implementations. Imagine something like web assembly as the
| basis for scripting those HTML/CSS Engines. Imagine the amount
| of energy, developer time and bugs we could save with a sane,
| modern standard that implements all the lessons learned from
| what came before...
|
| One can dream...
| sundarurfriend wrote:
| In practice, any attempt to change these basic specs would be
| diverted to be to the benefit of Google and its ilk, with the
| power they have to steer conversations and decisions. It's an
| accident of history that we ended up with these fairly open and
| hackable systems as the basis for the Web, and it's at a
| delicate point where a lot of companies are annoyed that they
| can't silo and close down more of it.
|
| So the unfortunate reality is that any well-intentioned attempt
| to reform them would be used instead to _reshape_ them for
| corporate interests, with no guarantee that we even end up with
| better specs from a developer point of view. The incentives lay
| in the direction of guaranteeing corporate interests, with
| users losing more of their freedom to choose how they access
| and use the Web; the developer concerns will at best be used as
| a PR front for the press headlines.
| shtopointo wrote:
| IMO, maybe some technologies do make sense for certain team
| sizes.
|
| I haven't worked much with React, although every time I did, I
| felt like everything was overkill.
|
| Then again, I've worked with k8s and while other people may think
| k8s is overkill, for a team our size - hundreds of devs working
| on separate microservices, I think it makes sense.
|
| It doesn't make sense for a small startup, but once you get to a
| certain size, the pure human element forces you to look for
| alternatives. While complex, k8s is actually a great solution to
| a lot of the problems we were facing.
|
| It's possible that React fits that same need, and while it may
| seem like overkill to me, maybe I don't know enough about it.
| dpedu wrote:
| Yes, I did exactly this and for the same reasons. I left web
| development in 2015 when the tooling was starting to get a bit
| silly. I had an opportunity to move into devops and system
| administration at the same company and team so I took it. I'm
| still finding it enjoyable and I do like how much more powerful
| the point of simplicity is in this field.
| knackfuss wrote:
| Switched from web backend to unreal engine game programming dev.
| Havent started yet on the new gig but one of my main motivations
| to not do web stuff anymore was having to deal with people
| introducing unnecessary layers between you and what you want to
| do in code, all that time. It is just a thing because web
| companies can afford both the extra cost and extra performance
| hit that these "best practices" incurr (and cultural inertia,
| maybe), while in games, I believe, there isnt space for any of
| that, you must start simple to complex because of budgets. Not
| the other way around.
| engineerDave wrote:
| I don't know if this helps or hurts but I took up Elixir a few
| years ago and was liking it, the way the FP simplifies the scope
| you have to operate within and the general stability of the API
| that Jose has stated, i.e. it's feature complete for the
| foreseeable future, changes now are mostly optimizations such as
| pushing more into the erlang layer.
|
| Then they introduced releases which can package everything into a
| tar file that has all the CSS, JS, HTML, erlang VM, etc. in it
| and runs as a binary via systemd and proxied through your .
|
| Then they introduced LiveView and it was the first time I really
| had a "wow" moment since first learning Rails many many years
| ago. I can do nearly everything I want in real-time with it + JS
| hooks.
|
| I really do think this addresses a lot of the frustration I keep
| experiencing w/r/t complexity in web development. I can just
| write Elixir code and get about 90% of the features of a JS
| framework like React.
|
| The only real knock on it is it's strongly typed not static typed
| (they're working on a solution) but with code analysis tools like
| dialyzer and credo a lot of that worry is addressed. It's not for
| everyone but FWIW it has been a breath of fresh air to me a 10+
| year web developer.
| boxed wrote:
| I've looked at Elixir a bit, but I came away with the
| expression that it would be a bit like doing Django before 1.7
| where I had to do schema migrations manually. This is a huge
| deal to me.
|
| I didn't see any forms libraries either, so the forms situation
| seems even more primitive. I'm the author of iommi so I now
| have very high level abstractions for forms/tables/menus/etc,
| and a transparent way to compose these. I would hate to start
| over from scratch...
|
| Am I just missing some libraries?
| a_bored_husky wrote:
| Fwiw I was afraid of manual migrations too, coming from
| Django, but its not that terrible once you get used to it.
| There should be a few form libs out there but I havent needed
| one so far. Chris McCord said at ElixirConf that there are
| plans of reworking the forms api to make it work better with
| LiveView.
| cercatrova wrote:
| As someone who works in full stack development, what complexities
| are you talking about exactly? I just spin up a NextJS app with
| an express server if I need a backend as well. In a way, it's
| been easier than before where you'd have to set up Webpack and
| friends. I just write React code and it automatically shows up on
| the page.
|
| You can do more complex stuff, sure, but it's not necessarily
| required. So it depends on what you're doing, which if you can
| answer I can help give an answer to.
| tomg wrote:
| I've bounced around between frontend and backend and devops, plus
| some iOS and one Android project. I've hopped in and out of
| various languages/frameworks. For the past year or so I've been
| using elixir which is my first big functional language job, as an
| example.
|
| I would not worry about job opportunities. Here's why:
|
| General problem-solving abilities (eg. breaking down work into
| smaller chunks of work until you have something actionable)
| translate well to all kinds of software.
|
| Skills like being able to communicate well with other engineers,
| product folks, etc is also similar.
|
| Also, tech moves fast. Even if I were to have stuck with only
| frontend work, that landscape has changed so much in 14 years
| it's not like the way I built things in 2008 is the same as 2022.
| Which is to say that regardless of staying in one area or moving
| around, I've always had to keep learning new things. I think
| other areas are like this too, eg Apple coming out with new ways
| of doing things every few years; Android SDKs having major
| changes over time.
|
| Maybe I'm just feeling preachy at the moment but follow what
| excites you :)
___________________________________________________________________
(page generated 2022-10-08 23:01 UTC)