1. 30

Hi Frontend Lobsters!

I want to ask what are the parts of these languages that you are putting up with, instead of liking it? Since the frontend applications are getting quite complex nowadays, with tons of frameworks and the prevalence of Javascript, I believe this is a good question to ask and reflect on what we are using at the moment (and maybe improve on them)

I hope this is not a wrong thing to add here, and if so please remove the story and my apologies.

    1. 50

      I think most of the problems are ecosystem/people issues–in turn driving the language/framework problems.

      Selected short gripes on people (any one of which I could write volumes on):

      • Conflating standard library problems with language problems. ES5 was actually a pretty reasonable language–the problem came from having a standard lib so anemic (to this day!) that people feel the need to keep adding stuff. If TC39/W3C spent less time getting high on their own supply and more time fixing the standard library then so much of what I hate goes away.
      • Permanent neophilia and just an overwhelming lack of restraint and good taste. Nobody seems to acknowledge the costs to chasing new shiny.
      • Everybody uses solutions backed by Big Players without regard for whether it’s a good idea or not. Your blog doesn’t need React. Your E-commerce site probably doesn’t need Cognito. Staaaaaahp.
      • Everything has so many dependencies and this nests. Left-pad should’ve been a wake-up call, and yet apparently nobody is actually serious about fixing that.
      • Tooling is too complicated and takes too long to run. Why is setting up Webpack annoying? What is it hard to just run off a config off the top of one’s head?
      • Testing culture seems to have gone super far into unit testing and just really sucks for actual can-the-user-do-the-thing-that-makes-us-money testing. It should be easier to script UAT than to do the DI and other stuff around unit testing, but for some reason that’s not where we evolved.
      • Too much popularity-driven development. We could be forgiven for assuming that most technical decisions being made in Webland are the result of conference talks and Big Personalities posting online.

      Selected language gripes:

      • ES6+ is getting past what comfortably fits in a person’s head.
      • CSS really needs to just have nested scoping already.

      Select framework gripes:

      • React has made dumb decisions and devs won’t back down on them. className, full stop.
      • ThreeJS keeps carving out key stuff–say, orbit cameras–into the examples instead of core, keeps adding other shit into core, and somehow bungles packaging the ‘extras’ into friendly NPM modules. At least this was the case last winter when I ran into it, again.
      • D3 is super easy to make slow and awful, and just always looks like spaghetti code to me.
      • There is no good framework to do some of the Java computational geometry stuff we did two decades ago. This is likely because making a holey concave polygon from other smaller holey concave polygons and triangulating it is Real People Hard but making another vdom knockoff is Frontend Engineer Hard.

      I could go on, but why close the year on a negative note?

      1. 11

        lack of restraint and good taste.

        This sounds like the root cause of everything else here.

      2. 3

        ES6+ is getting past what comfortably fits in a person’s head.

        I agree. If you took generators out of ES6 I think you’d have a reasonably comprehensible version of JS. I can get behind optional chaining to kill _.get(myObject, 'some.path.where.any.of.these.could.be.undefined.or.null)… but the trend of just adding more things to the language is a bit concerning.

      3. 3
        1. Incredibly poor library quality.

        Basically, a JavaScript library consists of

        • gnarly spaghetti code
        • without comments
        • inside a single file
        • with some constructor that takes a config object
        • where roughly 80% of the properties are undocumented
        • and 90% of the config options are not tested with each other
        • and break hilariously when used together
        • with no existing tests, and no actual testing being done between releases,
        • which means things randomly breaking in minor releases,
        • and the project is “active”, but the authors aren’t really acknowledging any bugs.
        2. Really bad build times.

        At my work a project has somewhat above 1.5m lines of Java code, and probably less than 50.000 lines of JavaScript.

        The 1.5 million lines of Java build faster than the 50.000 lines of JavaScript.

        3. Don’t even bother using libraries. They simply won’t last for the life-time of a commercial project.
      4. 3

        Implying frontend engineers aren’t “real people” seems really unpleasant and stupid and seeing it upvoted a lot makes me less inclined to visit and recommend this website

        1. 7

          I read this in the way of “this stuff is hard because it’s genuinely hard for people in general, versus this other stuff is made hard for frontend developers because of random yak shaving reasons in JavaScript that don’t exist in Java”

          1. 3

            It really reads more like “real engineers work on actually challenging problems involving polygons whereas dumb frontend people just mess around with stupid vdom knockoffs.”

            1. 1

              Well tbf, one of my pet peeves is arbitrary job titles. When did we all become engineers?

        2. 4

          Where in the comment can you point to @friendlysock stating the frontend engineers aren’t “real people”?

          I’m genuinely curious. I don’t read it like that at all. I read his comment as stating that a lot of the ecosystem issues around frontend development are driven by short-term fads and ideas churn. This isn’t a reflection on people as individuals, rather on the group as a whole.

          1. 2

            it’s probably this part

            This is likely because making a holey concave polygon from other smaller holey concave polygons and triangulating it is Real People Hard but making another vdom knockoff is Frontend Engineer Hard.

            though I interpreted it differently. I understood the message as both things being hard, though the vdom knockoff would get more credit from frontend developers than the computational geometry stuff.

            edit: didn’t see @mbrock’s comment:)

          2. 1

            making a holey concave polygon from other smaller holey concave polygons and triangulating it is Real People Hard but making another vdom knockoff is Frontend Engineer Hard.

            Maybe I’m misreading or just grumpy but it’s pretty common for Smart People Online to imply some kind of subhuman status for programmers who work on frontend…

            1. 6

              Last job I had was at least half frontend engineering, job before that 3/4. There was some genuinely tricky frontend work–98% of it though was not. I’m not some Real People engineer shitting on FE work without any idea what it’s like. Honestly, I’m unsure the work I do mostly qualifies as Real People technical work at all anymore. That said…

              In my experience the types of problems solved and praised in frontend circles–frequently in the web in general–tend to be either:

              • dealing with self-inflicted complications (“grunt was too old so we used gulp but I didn’t like it so we switched to we webpack but now we’re trying parcel!”)
              • reinventing the wheel yet again (“kachow folks here’s your boy friendlysock coming at you with yet another grid system that uses the same class names as bootstrap but handles floats slightly differently”)
              • fighting problems in the wrong part of the stack (“we have to use an SPA because our Rails backend is SO SLOW serving just normal pages”)
              • dealing with stupid browser behavior (“that webworker messaging worked great until IE11 decided to fuck up transferable objects and just spew memory everywhere”)
              • dealing with org dysfunction (“look I know you want it pixel for pixel to match the cut up but like you never explained the animation states of this button”)
              • dealing with stupid business constraints (“our customers want our app to load faster but you need to pull in 15 megabytes of 3rd party analytics scripts via GTM, one of which is apparently hosted on a Raspberry Pi with a 2G connection in Antarctica”)

              And look, I’ve made my money solving all of those problems. And it can be a thousand times more frustrating to deal with any of those things than a Real People algorithm.

              But, like, let’s be real here: the things people go to conferences about and get Github stars on and tweet about are different orders of technical difficulty compared to what many people do in undergrad CS.

              (And no, before you get annoyed at that, I don’t have a CS degree either.)

              1. 2

                I dunno, couldn’t you make such a list about backend programmers, game developers, like everyone except actual researchers and probably most of those too? “Wow, I’m a backend developer, I’ll spend two years switching back and forth between Postgres and some weird novel big data thing and fuck around with different message queues that never seem to work reliably and then rewrite all our Go micro services into Rust”, etc.

                1. 1

                  I’ll spend two years switching back and forth between Postgres and some weird novel big data thing and fuck around with different message queues that never seem to work reliably and then rewrite all our Go micro services into Rust

                  That seems more like what a frontend-dev-tasked-with-backend-work would do, not what a real backend programmer would do.

                  1. 1


                2. 1

                  I certainly could, and I believe the same about backend devs in most cases. OP specifically asked about frontend stuff.

                  (Also, game devs get a little bit of a pass from me since they deal with a much more varied problem domain–provided they aren’t just reselling Unity assets.)

        3. 1

          I think he meant “real software developers”.

    2. 17

      For me, it’s the “bundling” situation. I’ve never worked on a production project where “the webpack” wasn’t the most hated part of the stack. Webpack’s source code is a rat’s nest, so I feel very unmotivated to understand the situation or improve it from within. There’s tons of projects in this space that seek to simplify, but they never seem low-risk enough to migrate to: what if I actually do need to customize?

      So, I’ve been stuck with webpack pains for far too long. Maybe Airbnb or Facebook will open-source their Metro (FB bundler used for React Native) configs one day and we can escape…

      1. 7

        at $WORK we have swapped to Rollup for most of the browserland stuff I work with because it’s so much less headache, the entire codebase is grokable, and you can trivially extend it to do custom stuff if needed.

        I do agree bundling is problematic, but for me the worst part is Babel. I’d rather write ES5 than work with Babel and their constant breaking changes everytime I upgrade something.

      2. 3

        I seldom do front-end work, but bundling is my biggest frustration. Yeah, how come I do what I think is the exact same set up for a new project, and webpack fails me. Sometimes I yarn a particular version, it works, sometimes it doesn’t. Sometimes install –dev sometimes not. Eventually get the new project working, but never know how. Repeatability seems illusive.

        1. 1

          Babel could be all or some of my problems as well…

      3. 2

        Parcel has been nice to work with wrt packaging

      4. 1

        very astute observation. The whole build pipeline for non-trivial webapps is just slightly better than the world of no-packages (eg like C++).

        FB’s metro perhaps is also not a panacea, it does not let me, for example, have source files in directory folders I want (instead it is tied to node’s source file search algorithm).

      5. 1

        From the outside, I have a bit of trouble even understanding what bundling is all about. What does Webpack to that Grunt doesn’t? And then, what does Grunt do that make doesn’t?

        1. 6

          While you can bundle with both Grunt and Webpack, they are entirely different approaches to the problem, and unless you are working on something with only trivial Clientside JS, Webpack’s approach is superior.

          In short, Webpack (and other modern bundlers) understands require and import statements, so once it is given the location of your entrypoint JS, it walks the dependency tree to convert all needed dependencies into an optimized bundle for the browser. With Grunt, you can provide a list of files, but you need to manually manage the order of any cross-file dependencies, because it will fundamentally only concatenate the files together.

          1. 1

            I’ll just add that this even a non-“trivial Clientside JS” project can pull this off well enough with grunt, but when you get to a big project with many people most of which have no idea what is all this about, it becomes a problem.

    3. 5

      I want ipython in every language.

      1. 2

        I’m always sad I can’t find a pry or ipython REPL for my node programs, but I’ve realized why these don’t exist for JavaScript:

        In JS land, there’s no air for a console REPL to develop because Chrome devtools are so good, and can connect to your CLI app to debug and inspect.

        1. 1

          I would’ve argued that the new async features were woefully hard to debug in console, but I believe they’ve recently added the ability to natively await to the REPL without being inside an async function.

    4. 5

      friendlysock said a bunch of stuff that I agree with, so I won’t rehash that. I’ve been doing webapps since my boss (claimed to, and he is incredibly smart so maybe it’s true) come up AJAX independently by reading Microsoft’s docs…. it drives me crazy how complicated it is to get started now, and to do project configuration. Babel, webpack, CSS compilers, code splitters, linters, npm vs yarn, plugins… module syntax!! not being able to fucking import { } from package in node (depending on the version and config!!) like you can in your browser code! I mostly like Typescript the language, but oh-my-god there are even more config options with that! How the actual fuck is anyone new to programming supposed to leap all the hurdles required to just start programming [0]?! No wonder they give up on things that matter and choose Mongo instead of learning a relational database: they’ve driven themselves mad just trying to get the frontend off the ground! They don’t have the mental bandwidth for databases or data structures - they’re exhausted already! They’ve made a hundred configuration choices they don’t really understand, based on whatever they’ve cobbled together from thousands of Medium posts that were inaccurate to start with, or out of date 3 months after being published, but which still come up 1-through-10 in Google.


      Rant over.

      [0] I realize there are other languages and not everyone starts with JS. But a lot of people do.

    5. 5

      My biggest pet peeve is how many people want JavaScript to be the language they know best. Some come from Ruby and want it to be Ruby. Some from Java who want it to be Java. Some from Python.. you get the idea. I do like the amount of attention JS gets, but all of the various proposals that are not quite there yet that keep being used as if they are (like decorators/annotations) drive me a little bit nuts. I’ve been using JS for a really long time and I don’t feel like it’s missing that much stuff. It really just needed some things cleaned up (which has generally happened over time).

      Also the insistence that JS needed “class” syntax (though it still isn’t classical inheritance), which was implemented, and now many people are trying to move back to functions/functional-based programming, throwing out the whole class baby with the bathwater. There’s too much flux there and not necessarily for the best reasons.

      I am with the other guy who was talking about bundling and packaging things. If I can avoid it and use modern browsers, I do. But the reality is that those bundlers are still very useful particularly on applications that work on older browsers.

      1. 2

        It’s not just Javascript. I can make the same argument with Lua—the Pythonists that come to Lua want it to be Python; the Rubyists want Lua to look like Ruby, etc. It takes time to learn the lingo of a new language, and it’s darn it, it would be easier if it was just like <old language I know>.

      2. 1

        ES5 for life!

    6. 4

      I use Fable Elmish. I think my pet peeve is how sometimes the event system can be confusing due to how things are more fully described.

    7. 4

      You said frontend, so I’ll take this as an opportunity to talk about iOS :D

      In general, the move away from dynamic dispatch. I mean, I understand it’s for performance, but it makes things less fun :( I’m also incredibly skeptical of SwiftUI, and am not looking forward to doing jobs/contracts using that framework.

      I have a gut feeling Apple’s making these changes purely for “developer PR” reasons, and not because they’re actually good changes. e.g. Objective-C brackets are too ugly -> make Swift, UIKit is too hard -> copy React.js. FWIW I have nothing against Swift but the reasoning behind making it doesn’t make much sense to me, from a technical perspective.

      If changes like these continue I will probably switch to backend or embedded or something. At least there, I won’t be subjected to the whims of post Steve Jobs Apple.

      1. 1

        I am a mobile developer as well, so of course!

        I’ve never been able to spend much time on native iOS development however the SwiftUI idea seems good from the perspective of “declarative vs imperative programming”. I can imagine that is the main source of skepticism. Recently the whole FE worlds started to shift towards declarative programming hence the boom.

        Why would you prefer imperative programming by the way I would love to have an opinion on that as well.

        1. 2

          I like the flexibility. The UIKit APIs are pretty well designed so I never really had much issue banging out a bunch of boilerplate, so the “less code” thing is kind of moot to me, especially since you can just abstract that yourself.

    8. 3

      UI work in general → extremely asynchronous. It hurts to track.

      But most of all, as others have said: packaging/bundling story. It’s a shit show. Interoperating with 3+ module standards kills you.

      Other than that, JS as a language has massively improved. I use TypeScript when I can, but otherwise, JS is just fine no matter what people are saying. It’s objectively as good as any other dynamic, weakly typed language. It has great ergonomics now.

      These days for “frameworks”, I just use React and sometimes Redux. Really depends what the needs are. Otherwise I use nothing but HTML and CSS. Recently I’ve found a great urge to push CSS hard, so that JS can be minimized to purely data fetching.

      Some UI genius needs to come around to show everyone how to deal with these asynchronous spaghetti monsters. The only way I know of, so far, is to use something like Redux and “travel” through all the states. But I’m not talking just web, but all UI across all platforms. There must be a sane, composable, maintainable, easy way to create UI. I feel we are super close to this reality.

      1. 5

        It’s objectively as good as any other dynamic, weakly typed language.

        Sorry, but what other weakly-typed languages are there out there in widespread use to compare with? I mean, it’s just PHP, right? Visual Basic maybe? This seems like pretty faint praise.

        1. 1

          PHP is exactly what I was thinking. And praise? Do you praise a hammer? I don’t. I see languages as tools, not things to praise.

          1. 2

            Here “praise” is a reference to the term “damning with faint praise” where you say something that’s ostensibly positive but it’s actually such a low bar that it acts as a dunk instead.

      2. 1

        Some UI genius needs to come around to show everyone how to deal with these asynchronous spaghetti monsters.

        Oh, I hope so. It all comes down to, essentially, CPU interrupts, and those are a real fragile special case to code for already. So if we come up with a truly better model of async, it could change a lot.

        So far the nicest model I’ve seen is Erlang-y actor systems, but that has some performance overhead that seems to make it unacceptable to those who really need that last 10% of performance. It is also still pretty easy to turn onto spaghetti if you’re not careful.

    9. 3

      I hate elixir so much.

      • diabetes-inducing levels of syntactic sugar
      • two different, incompatible string types (charlist & binary)
      • slow compiler, but not much in the way of compile-time checks–since the language isn’t explicitly typed
      • too many options for error handling (catch vs rescue vs tuple return)

      I could go on and on.

      Big part of making good software is keeping combinatorics under control. Elixir clearly disagrees with that.

    10. 3

      I use Erlang for funzies and love it, but a few of its age spots are still noticeable:

      • Default latin8 encoding (today everyone likes utf8).
      • <<"Bitstring syntax">> is way less convenient than "most languages string syntax".
      • Hanging commas, periods, and semicolons still feels strange lol.
      • Language doesn’t have a native pipe operator, and the stdlib makes it hard to imagine a consistent one (lists puts the list argument as the last param, queue puts it as the first).

      But I love it, on the whole! And Elixir fixes many of these.

      My professional work is mostly in Python, which I largely abhor due to how it gets used. It’s great for codebases you can fit into your head and/or with a few responsibilities (or even small teams that don’t churn much, and are consistent), but I’m on my fifth high-growth company that’s used it for as much as possible, touched by many hands over many years, so it’s an incomprehensible mess of bad patterns. Hard to blame the language for this, it can’t help that companies decided to optimize for the first 4 months of development at the expense of the next 7 years 🤷‍♂️ and there’s a decent argument that it’s flexible enough for the company to have hit PMF, whereas a language with more invariants wouldn’t have let them get even that far.

    11. 2

      I guess what peeves me the most is that my favourite tech choices are not all used at $income_provider, and the concrete has set there, so changing tech is looking increasingly unlikely. Hum.

    12. 2

      Redux Sagas, and generators in general. I don’t understand why generators were added to ES6; I’m convinced they’re hardly ever useful to solve a real problem anyone has (and this is also true in Python). When you throw Sagas on top, and then try to step through that code in a debugger [0], well: good luck following what’s going on there.

      1. 2

        I use generators to write cancel-able data structure traversals and (async) transformations. Much easier than implementing a Iterable directly.

        I’ve never used this “saga” thing though.

        1. 1

          The saga concept (and the implementation) is actually pretty cool. My real gripe is not the project itself, but that it was one of those hype-train things that Redux people leaped onto immediately after they had leaped onto the thunk hype train. And then they use it for nothing more than displaying a loading spinner while waiting for an async data fetch (that’s, like, every Redux Sagas tutorial / example).