71–80 of 245 posts
Only 4.5% of respondents said that they are unhappy with the state of front end frameworks. That satisfaction level is "official approval of a president in a dictatorship" high.
As someone new to front-end and who will probably only be building small hobbyist stuff by myself, is the mountain climb that is mastering React worth it? From my initial look into it, it seems incredibly complex.
The other one with an even more explicit in its commercial support for the framework is Ionic, you know the firework will always be supported as they use it themselves for their own consulting business. I see that as a massive plus.
Not familiar with much front-end work - can anyone give insight to what's gone on with Ember?
I just got a new job, mostly backend but with a bit of Ember thrown in, and I despise the framework. It's slow to work with, massive, and incredibly over-engineered and makes it so that creating the simplest of features is an absolute mess. Maintaining a sizeable Ember project is pure hell of traversing through 800 folders and files to find the one place the thing you're looking for is, since you can have a controller inherit from another, which inherits from another, which inherits from another ad infinitum, so good luck guessing where exactly that one attribute is coming from, or even what the hell it even is. The base controller might have a variable called `foo`, but then somewhere down along the chain that variable has been aliased/transformed into a completely different variable name with 0 bearing on what it originally maps to.
Handlebars templating is also *awful*, I cannot describe with words how much I despise Handlebars and everything surrounding it. To create a simple `if (foo && bar)` in a template, you have to do `{{#if (and foo bar)`. Okay, the `and` DSL is a bit weird, but not that bad. But then `if (foo && !bar)` becomes `{{#if (and foo (not bar))}}`. God forbid you want to do any kind of comparison though, because `if (foo 1)` becomes `{{#if (or (gt foo 0) (lt bar 1))}}`. You get the point, it quickly dissolves into an unreadable soup of brackets and DSL for very simple logical operands.
I could go on for a while about why I hate Ember, but I'll leave it at that.
As someone new to front-end and who will probably only be building small hobbyist stuff by myself, is the mountain climb that is mastering React worth it? From my initial look into it, it seems incredibly complex.
React is the hotness of the moment. If you want to maximize career mobility, salary, and immaturity all at the same time React is for you.
Earlier quoted context omitted.
People inheriting old react codebases now have to deal with way more complexity. For example, everyone was using styled components 2-3 years ago and now they are moving away. The complexity styled components introduced has to be managed alongside the current trend (tailwind?). Old styled components codebase looks horrible. They end up with Java inheritance hell. You create a button, then create another button inherit…
I'm working on a codebase that evolved at the same pace as React, but without any thought for idiomatic principals. As a result, you have class-based components, purely functional components, hook based components, HOCs, Redux state passed in through the older functional way, Redux state passed in through an HOC, styled components, traditional CSS styled components, and anything else you can think of that was in vogu…
> I'm not sure if this effects other frontend frameworks as much, but it does seem like React was always pushing for a "new way to do things" every year.
In my experience, it purely depends on how you regulate the code internally. You can always find developers using something shiny every week when you already solved the problem the shiny thing solves like 100 times in your codebase. I had the same problem with some random integration of Blazor recently in a .NET codebase. Some had the same problem (apparently, I came later) integrating Primefaces to a JSF codebase.
It may be amazing tech, but do you really need it if you can KISS without it?
Gulp build tool not receiving much love lately with a very strong "Would not use again". Why so? https://2021.stateofjs.com/en-US/libraries/build-tools/#buil...
I might be getting that question totally wrong, but faced with the question of "would you use gulp for a new project" my answer would also be "no", altough I think that gulp is a nice and totally workable tool. The thing is that gulp doesn't really have all that much to offer these days. If you need lots of complex build logic webpack is the way to go. If simple & fast is the desired goal then something like esbuild…
I mean that is a weird thing to say it seems to me because whenever I have any sort of complex build logic that is when webpack becomes completely impenetrable or just does not support what I need - what do you mean by a complex logic that webpack supports that gulp doesn't?
Earlier quoted context omitted.
65 year olds don't do javascript. which is explainable since javascript itself is ~28 years old and node.js is like 15?
People aren't born knowledge of the programming languages at their time of birth, 65 year olds can do JavaScript just fine, it isn't even anything weird as a language :-P. I think it is more likely that, largely, there are way more 25-34 programmers than 65+ programmers out there.
Earlier quoted context omitted.
People inheriting old react codebases now have to deal with way more complexity. For example, everyone was using styled components 2-3 years ago and now they are moving away. The complexity styled components introduced has to be managed alongside the current trend (tailwind?). Old styled components codebase looks horrible. They end up with Java inheritance hell. You create a button, then create another button inherit…
I'm working on a codebase that evolved at the same pace as React, but without any thought for idiomatic principals. As a result, you have class-based components, purely functional components, hook based components, HOCs, Redux state passed in through the older functional way, Redux state passed in through an HOC, styled components, traditional CSS styled components, and anything else you can think of that was in vogu…
The whole idea of React performing a bunch of tasks in the background and updating everything when it feels like is just all a bunch of silly magic. In fact, my state of JavaScript 2021 would be pretty damning, but because of the libraries used instead of JavaScript (like React and TypeScript), not because of JavaScript.
React presents a simple view of the world, but in doing so, you now have no idea what is actually happening, and you need to know that. This isn't like an array in JavaScript that is abstraction of an array in c that needs memory allocated and new arrays created and so on. You don't need to know how that works other than that the JavaScript version is a bit slower and you accept that. You need to know how all of the stuff React hides actually works to create your program.
In terms of hooks, there are so many "rules". Instead of seeing an API, the API is moved into the documentation and not visible in the code until run-time when you get one of the many errors like not adding a dependency to a hook, using a hook outside of some specific area, etc, etc. It isn't JavaScript at all, so you no longer have the tools of the language to freely use to make your life easier.
As someone new to front-end and who will probably only be building small hobbyist stuff by myself, is the mountain climb that is mastering React worth it? From my initial look into it, it seems incredibly complex.