4 ms·
I like javascript, but I always think about the time when I was working as a front end developer, and a guy across the room suddenly stood up, walked over to th
by karaterobot 4y ago
I like javascript, but I always think about the time when I was working as a front end developer, and a guy across the room suddenly stood up, walked over to the white board, and wrote "F*CK JAVASCRIPT" in massive letters. I believe his concern was around the lack of type safety (this was before we used Typescript). And this was someone not prone to dramatic gestures.
At the time I laughed. Guy must be having a bad day. Javascript rules, look at this widget I made.
Cut to a few years later. I am fed up with React, and the entire javascript ecosystem in general. The trend-based, article-driven development, the new framework/pattern you have to learn/unlearn every six months, the SPAS that made a simple web app spool up the user's laptop fan with all the javascript it was processing just to do basic stuff we could do much more simply in the 90s.
I ultimately quit being a developer in 2019, switched to doing design full time. I still write javascript for personal projects, because it's the thing I'm most familiar with. But, only vanilla javascript.
Javascript rules, but also: f*ck javascript.
- leptons 4y ago> a guy across the room suddenly stood up, walked over to the white board, and wrote "F*CK JAVASCRIPT" in massive letters >Guy must be having a bad day. He was having a bad day because he was doing stupid things with the code he wrote that led to problems. I've never had a problem with Javascript's type system, or having the wrong type show up where it shouldn't. I accepted the dynamic nature of JS long ago when it first came out in Netscape, and I adjusted my coding style accordingly. And Javascript types are not a mystery, type coercion is fairly simple and doesn't produce unexpected results if you actually understand the language. If you don't understand the language (or any programming language), then writing things like "F*CK JAVASCRIPT" in massive letters on a whiteboard is something that might happen.
- tstrimple 4y ago> I've never had a problem with Javascript's type system, or having the wrong type show up where it shouldn't. I accepted the dynamic nature of JS long ago when it first came out in Netscape, and I adjusted my coding style accordingly Different languages have their own strengths and weaknesses as well as generally accepted coding practices and sometimes different paradigms. I find the folks who struggle the most are trying to write JS as if they are still a C# or Java developer so they constantly run into square peg round hole issues and blame it on the tool. I love JavaScript. I also love C#. But you've got to approach how you solve problems with them differently. How you write long term maintainable code in both is different.
- cxr 3y ago> I find the folks who struggle the most are trying to write JS as if they are still a C# or Java developer so they constantly run into square peg round hole issues and blame it on the tool. I love JavaScript. I also love C#. But you've got to approach how you solve problems with them differently. How you write long term maintainable code in both is different. Weird take. Because the best way to write maintainable JS by far, whether you're using TypeScript to enforce it or not, is to keep all the lessons that informed the design of Java in your heart. Go ahead and decompose your program into classes and interfaces, eschew with clever tricks and just focus on readable code instead, and make sure you or anyone else can without much difficulty work out at any given point what the "shape" (type) of a value is.
- krapp 4y agoYeah, Javascript isn't even the only dynamically typed language out there, but you don't see people compiling strictly typed supersets of Python or Lisp because they consider those languages unusable otherwise. With any other language people are willing to learn the idioms and accept and work with the quirks, but for some reason Javascript alone seems to be the exception.
- schwartzworld 4y agoDidn't python add static typing?
- giantrobot 3y agoOnly type hints. They help a linter/IDE bitch about types but they don't have any enforcement beyond that. They're great for self documenting methods but don't remove any dynamic typing from the language itself.
- jcparkyn 3y agoI'd argue that typescript is the same, just stricter by default if using TSC. Many people run type checking separately from building/running the code, just like in python.
- fulafel 3y agoThere are lots of well-liked dynamic languages. But JS deserves the bad rap, it has so many WTFs in it's dynamic behavior and as a rule doesn't raise errors when things go sideways. Just painting it as a dynamic vs static thing is misleading.
- selfishprick 4y ago[flagged]
- ggregoire 4y ago> I am fed up with React, and the entire javascript ecosystem in general. The trend-based, article-driven development, the new framework/pattern you have to learn/unlearn every six months, the SPAS that made a simple web app spool up the user's laptop fan with all the javascript it was processing just to do basic stuff we could do much more simply in the 90s. I must be living in a parallel world cause I write React & TypeScript code on a daily basis (among many other things, including writing Python and SQL too), I've done it for a few years now and I quite enjoy it. Last time I had to learn a new "pattern" was Hooks I guess, and it was like 3 years ago? I was hesitant at first, I didn't have any issues with class components... but Hooks actually increased my productivity and simplified my code. Otherwise I feel like coding in React hasn't changed much over the years. I would definitely not want to go back to the technologies I was using in the 2010s.
- SkyPuncher 4y agoI always find myself coming back to react. Its so delightfully simple at its core. Typically super easy to debug. Extremely composable and reusable.
- Kailhus 4y agoI’m the same here. React with TS just makes sense as it is. We have a mix of class and functional components which can easily be understood. State lives here, logic goes there, render, done! It does become tricky when you start adding things to its simplicity like Redux, useEffects, useContext, useReducer, locationState, params, props, classes, StorageProvider (and the list goes on) without a clear standardized code guide for each scenario/patterns.
- klabb3 4y agoYeah that’s right. I think a lot of JS devs are jumping on fads but it’s absolutely not a requirement. Just pick a couple of well supported projects for the stuff you really need and stick with it. I’d much rather have some dependency discipline and a vibrant fast-moving ecosystem than the opposite. Just pick the fruit of other people’s labor when it’s ready instead of dogfooding questionable and bloated deps. Oh yeah and do not read medium articles about JS.
- madeofpalk 4y ago> the entire javascript ecosystem in general. The trend-based, article-driven development, the new framework/pattern you have to learn/unlearn every six months Maybe it’s worth logging off Twitter for a while and understand that you can just not pay attention to these ‘trends’ and learn a new pattern every six months and you’ll be absolutely fine. Yes, ecosystems and communities can encourage this, but individuals also have got to take some responsibility for opting themselves out (or into) this hamster wheel. I’ve seen this React Server Components stuff on the periphery for a while now, but I don’t really understand it and I don’t intend to for a while. I’ll let the twitter us hype beasts sort out what they want to do with it and I’ll circle back and check out what it’s like in a few years.
- bigger_cheese 4y agoMy experience with javascript as a non-software developer/non web person has often involved frustration. A good example is an experience I had a few years ago (circa 2018) My work acquired some new software which published some results using a REST endpoint. I wanted to pass some parameters to the endpoint get a response and display the response on a webpage. I'm used to working with Python/R and SQL databases it is relatively easy to write code in these languages to execute a SQL query and publish the result. To do the same thing with endpoint I had to learn about ajax, asynchronous code, callbacks and then later deferred promises. What I thought would be relatively simple ended up being horrendously complicated to code. I think part of the problem is the javascript language changes and adds new features so rapidly it is very hard to search google for help in my case I found code examples using callbacks, I had massive issues trying to make it work only to later discover that was old way to do it and the new way was to use Promises instead. Most of google searches I made went to horrendously outdated stackoverflow posts and there was no obvious way to tell if answer was best practice or not. Doing the same google search again today in 2023 it looks like they have reinvented how to do it with something called "Await" now.
- jdlshore 3y agoAwait is just syntactic sugar for promises.
- solumunus 3y agoYou would find it even more difficult in almost every other language available.. What you're describing is simply the pain of learning a programming language with virtually no prior experience. Maybe it's more simple in Python but this really isn't that complicated, it's certainly not a valid criticism of JS.
- icedchai 3y agoSounds like a perfect use for jquery. You don't always need to use the newest framework.