6 ms·
> This sounds like the sort of thing I hear from folks who have only passively dealt with the Javascript ecosystem but somehow still seem to think they have a r
by kerkeslager 6y ago
> This sounds like the sort of thing I hear from folks who have only passively dealt with the Javascript ecosystem but somehow still seem to think they have a really great handle on the entire situation, how it got there, what exactly the root of the problems are, and (sometimes) how it can be fixed.
Never in the last 11 years have I not been professionally developing JavaScript to some degree, and I fully stand by what was said in the post above.
> It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are.
Then why are things getting worse?
> Patterns, best practices, and standards often take quite a while to surface and become established.
The best practice for JavaScript at this point is to use the few good libraries (in most cases, that's literally only React) and beyond that, do as little in JavaScript as you can to minimize its impact on your system. User experience comes before everything, so that means you still have to do a lot of JavaScript.
- tashoecraft 6y agoIt's very limited to think that the user experience comes before everything. If I focus purely on the user and not my business I don't have a business. If I do something good for the user experience but in fact breaks the law, then I am no longer in business. The user is incredibly important, but it's all a balancing act of resources and where to dedicate them.
- kerkeslager 6y agoIf your business doesn't serve its users, I am not particularly concerned that you don't have a business. Its my impression that most relevant laws are geared toward protecting users from businesses, but I'd be open to hearing if you know of any exceptions (GDPR isn't one--secretly collecting data on users without their consent isn't serving users, it's harming users).
- tashoecraft 6y agoUser experience is a broad term. People here generally think of speed, but in fact that can actually result in a worse user experience. I believe users react better to a loader that takes longer for certain tasks like calculating tax returns because they like to think the computer worked hard to get the best result. It’s not always black and white. I have had to implement features that are awful for the users, but are required by law to have. Others to protect the business from liability. I’m not saying doesn’t serve users as the original comment was “user experience” and was specifically mentioning JavaScript in terms of a presumably slow site. User experience is many things and all of them need to be considered. I totally agree that sites have gotten way to bloated, but the js community is recognizing that and trying to work on it, lazy loading and improvements to module bundling are going to help. I think the craze of tiny packages is coming to an end. Libraries post proudly when they have zero dependencies. As the community evolves it’ll improve, though some sites will probably continue to get worse as higher ups demand more features.
- marvy 6y ago> awful for the users, but are required by law I am really curious what sort of law does this. (Though maybe I'm better off not knowing...?)
- kerkeslager 6y ago> I believe users react better to a loader that takes longer for certain tasks like calculating tax returns because they like to think the computer worked hard to get the best result. It’s not always black and white. This is a concern with creating the impression that you're serving the user, rather than actually serving the user. > I have had to implement features that are awful for the users, but are required by law to have. Others to protect the business from liability. This is basically what you said in the previous post, and remains lacking in concrete examples.
- no_wizard 6y agoHow’s it getting worse, exactly? I must admit I am intrigued by this contrarian view Than the average, but this feels light in specifics so I don’t have any way to address it on a point by point basis. Could you elaborate your positions here?
- kerkeslager 6y agoClasses: JavaScript developers couldn't be arsed to learn prototypical inheritance, so they added class-based inheritance. Except they didn't really--classes in JavaScript are just an abstraction built around prototypical inheritance. So now you have to understand prototypical inheritance to understand how the class abstraction leaks. It's fewer lines of code, but it brings in a bunch of implicit complexity. Promises: this is just syntactic sugar around callbacks, and does nothing to address the underlying problems of why callbacks were painful. It does introduce two ways of doing the same thing though, so now if you want to write any sort of abstractions you have to handle both ways. Leaning hard into global frameworks that actively resist reusability and composition: Angular, Ember, etc. just start from the assumption you're writing an SPA. React is a rare gem of an exception, and is an awesome project, but there you have Flux/Redux/etc. trying to turn every React App into an SPA. This is probably the clearest example of JS projects being unsustainable: if you sacrifice reuse and composability in order to have a framework that does a lot for you, that lets you spin up projects quickly, but the project will slowly grind to a halt. React projects are great as long as you can fight the fight to keep Redux et al out, but eventually Redux fanboy gets it in and it quickly consumes your project. Global state is bad, folks. And don't tell me about reducers: I know, and if you think that means there isn't global state, that's only because you don't understand what global state and/or reducers are. I also am not interested in hearing about the other library you use to clean up your Redux code--instead of piling on more libraries to fix the problems you introduced, don't introduce the problems in the first place.
- no_wizard 6y agoSo, I see small bits here, that all boil down to developers not understanding enough about their language of choice. The web being the vast platform that it is and JavaScript eating so many domains may very well be a situation where not having full mastery of a language will still get you very far perhaps - which says a ton of positive about the platforms imo- but that’s the heart of what I’m seeing here. So, perhaps the issue Heyer is lack of education, not that the ecosystem itself is unquestionably broken? Also, curious, how do you handle state full actions without some kind of global? Genuinely curious
- orange8 6y ago> Never in the last 11 years have I not been professionally developing JavaScript to some degree I know a designer who has also been professionally developing JS to some degree for over 15 years. Still very much a JS novice. The terms "passively dealt with the Javascript" and "to some degree" sound like the same thing to me.