No JavaScript frameworks were created during the writing of this article
October 6, 2016 6:59 PM   Subscribe

 
This is literally my life right now. I'm supposed to have at least a basic understanding of how to do stuff with React by the 17th, for my new job. When I learned JavaScript initially, it was with jQuery. I feel incredibly lost. Excited, but lost.
posted by Sequence at 7:06 PM on October 6, 2016 [2 favorites]


Bear in mind, it's only gonna be 2016 for a couple more months. Now is a good time to start practicing saying, "You're not STILL using React, are you?" so it'll roll naturally off your tongue in January...
posted by Sing Or Swim at 7:11 PM on October 6, 2016 [24 favorites]


As a counter, I also enjoyed this: “should websites work without JavaScript?”
posted by Bora Horza Gobuchul at 7:12 PM on October 6, 2016 [16 favorites]


This is too real.

I've tried to vaguely maintain my web dev Front End Engineering skills over the years because they occasionally come in handy. The last time web development was actually my job was when CSS was still new and Netscape Navigator was the best browser around. But I've tried to keep up. This inevitably means being pretty incompetent at doing stuff that was cool about 18 months ago. I put a lot of effort into learning Meteor, and was feeling quite comfortable with it until everyone started laughing at me.
posted by Jimbob at 7:15 PM on October 6, 2016 [6 favorites]


These days, I'm mostly doing backend work creating an Elixir framework, living in purely functional land and rolling our own type system.

That's not germane to the article; I just wanted to taunt people affected by it.
posted by The Gaffer at 7:17 PM on October 6, 2016 [13 favorites]


Right now, my money's on Vue.

It combines a lot of the nice things about "modern" frameworks with a really simple conceptual model. It could become the new jQuery.
posted by schmod at 7:18 PM on October 6, 2016 [2 favorites]


rolling our own type system

[runs away screaming]
posted by schmod at 7:19 PM on October 6, 2016 [20 favorites]


As a counter, I also enjoyed this: “should websites work without JavaScript?”

Is it supposed to be blank?
posted by zamboni at 7:19 PM on October 6, 2016 [23 favorites]


k i'm halfway through this and feel my blood pressure rising to dangerous levels, aborting
posted by indubitable at 7:22 PM on October 6, 2016 [5 favorites]


I stay a happier person by staying the fuck away from nearly all JavaScript frameworks. I just don't code enough to keep up. Instead, the rare times that I do get to write code, I focus on making semantic HTML5 markup that the real devs can wrap into something pretty. Its a nice, probably doomed niche, but it works for my brain and the reality of my very part-time dev role.
posted by rockindata at 7:28 PM on October 6, 2016 [8 favorites]




Yeah this is my life too - the problem with being largely a back-end developer is that it's easier to hand the JS work to the person next to you, but the downside is you then don't keep up with the tech.
posted by xiw at 7:30 PM on October 6, 2016 [1 favorite]


JSX? What is JSX?
-JSX is just a JavaScript syntax extension that looks pretty much like XML. It’s kind of another way to describe the DOM, think of it as a better HTML.


I get away from web development for what seems like five minutes (ok more like a year and change) and stuff like this and AMP HTML start popping up... I don't wanna go back to the Baskin Robbins 31 flavors of markup like the bad old days!
posted by jason_steakums at 7:30 PM on October 6, 2016 [2 favorites]


This was my life.

I am not-even-kidding ditching front-end engineering unless absolutely forced to go back because of the utter madness highlighted here.

I need to display data on a page, not perform Sub Zero’s original MK fatality.

*toasty*
posted by wildblueyonder at 7:33 PM on October 6, 2016 [8 favorites]


This is my life now too and I'm pushing the team towards pure jQuery (combined with tasty plugins like DataTables, select2, twitter typehead) with the scripting in TypeScript, back end asp.net WebAPI -> EF -> SQL Server.

C# and TypeScript should get together and have a baby already.
posted by Heywood Mogroot III at 7:35 PM on October 6, 2016 [4 favorites]


This is literally my life right now. I'm supposed to have at least a basic understanding of how to do stuff with React by the 17th, for my new job. When I learned JavaScript initially, it was with jQuery. I feel incredibly lost. Excited, but lost.

When I learned javascript jQuery didn't exist and it was a toy language you used to make the status bar scroll in netscape and make little stars follow the mouse cursor, so imagine how I feel.

That being said, MVC frameworks like Ember, Angular, React, really do make building large web apps much more feasible and less headache inducing than rolling your own in pure js/jquery.

I hate frontend so much though, and wish I could get a job doing systems programming or embedded work or some such. But every job out there is just web web web.
posted by dis_integration at 7:38 PM on October 6, 2016 [4 favorites]


Thank god I'm not a Front End Engineer, C++ still feels too heavyweight for me.
posted by Dr. Twist at 7:38 PM on October 6, 2016 [2 favorites]


This kind of thing is actually exactly why I just don't really understand how practical coding works at all despite syntax coming pretty easily to me. It's like if you were learning Spanish but you weren't able to make basic phrases come out of your mouth until you also learned how to write a cookbook and read braille and compile environmental impact statements and speak Malagasy and understand the primary themes of Elizabethan drama and build a table and
posted by zokni at 7:40 PM on October 6, 2016 [47 favorites]


My job is mostly back-end "big data" stuff these days, and it's hard enough to keep up there with all the new projects that are gaining traction in the "cloud" space, but this flavor of the week aspect of dynamic web frontend crap brings to mind that junkie that's totally going to quit after they get just one last hit. "Surely this will be the library/stack/platform/framework that lets me finally stop running on the endless treadmill of self-improvement and actually do useful work!" One out of every few hundred of these things actually moves the ball forward in a significant way, but usually with some loss of an important capability or six that the Old Shit That Nobody Uses Anymore had, and always wasting more devlopers' time as they come up to speed on the New Shit That Everyone Needs to Have on Their Resume Because Their Old Company is Out of Business Because They Spent Too Much Time Dicking With New Web Frameworks.
posted by tonycpsu at 7:43 PM on October 6, 2016 [17 favorites]


I am continually disappointed that programming is far more inelegant and difficult than every other aspect of digital content creation. Especially front-end web programming.

Are you seriously trying to tell me that formatting and presenting text and animated graphics in a web browser is a more formidable challenge than removing Lt. Dan's legs in Forrest Gump, so much so that it requires a long, convoluted Unix-derived toolchain and a deep understanding of not just Javascript, but other meta-languages based on javascript to accomplish even modest results?

Something is wrong and broken.

The first company to come up with a modern Dreamweaver that will allow designers to abstract website front-end logic into a predictable and extensible and standards-driven GUI-centric tool, similar to the other design tools they already use, will win the internet forever. That company will not be Adobe, as good god, their current stuff is easier to learn than Quark ever was, but that's not saying much.

Also, I maintain a fuckload of WordPress sites. The setup is awful and convoluted, but once you get past that, shit just works... if you need to scale, it sucks in a hurry, but most of these sites don't. WordPress isn't as flexible or expressive as it needs to be, and is about as secure as Linus without his blanket, so it's not ideal.

So! The Modern Dreamweaver should handle the back-end setup for you as well, using well understood industry standards, a few checkboxes and text fields at most. Let their team of firebreathing CISSP certified securifreaks come up with acceptable and programmatically reproducible standards. Then you design your site with cool GUI tools, and IF you're a power-user, then maybe some custom Javascript. It will set up the git repos for your team automatically, but your team will know this feature as "unlimited undo" and "collaborative save".

Never gonna happen. There's too many industries to disrupt with Framework du Jour and a crapton of VC.
posted by Slap*Happy at 7:44 PM on October 6, 2016 [13 favorites]


> Is it supposed to be blank?
Yes. That's the joke. (The JS file linked in the page's source, should-websites-work-without-javascript.js, never loads… meaning that the page, utterly dependent on JavaScript, will render nothing at all).
posted by Bora Horza Gobuchul at 7:48 PM on October 6, 2016 [5 favorites]


Something is wrong and broken.

Something is broken. Because people are trying to develop GUI-style apps in a document rendering engine, using a programming language so bad that the entire thing has to be abstracted away, and then abstracted away again, before the task even becomes tractable.
posted by Jimbob at 7:51 PM on October 6, 2016 [49 favorites]


Slap*Happy would you be surprised to learn that Microsoft is probably closest to offering the Dreamweaver replacement you describe? It's easy to do just about everything you're asking in Visual Studio. What they make hard is producing an application with any visual appeal whatsoever. You've got to really get down in the plumbing if you don't want the look and feel of 1996.
posted by putzface_dickman at 7:58 PM on October 6, 2016 [3 favorites]


I spend a lot of time writing ClojureScript these days, and frankly I couldn't be happier about the JavaScript community's acceptance of JavaScript as more of a platform that you can compile code into than a language in and of itself (and its concomitant acceptance of large, complex toolchains). It's had the effect of freeing programmers from actually needing to write in the JavaScript language. I would be loathe to suffer through all the webpack / babel / npm / grunt madness just to write code in ES2016+, but using a language that wasn't designed in a weekend to write code for the browser is pretty awesome, and I can use literally the same code to validate user input on the front-end and incoming data requests on the (JVM Clojure) back-end.
posted by whir at 7:58 PM on October 6, 2016 [3 favorites]


I have been doing a lot of little embedded controller apps that put data out for web browsers, almost all using HTML 1.0 circa 1995 technology and you know that shit just works every single time on everything. You can write an elaborate web app to port the data to a database, which will fail once in awhile for untroubleshootable reasons and be obsolete three years from now, or you can just drop the data into .CSV files which have been a standard since roughly 1964 and I have customers who have been pasting that .CSV data into their databases for eight years and more now and they just love it for the reliability. You don't even need a PC, much less a server. It's kind of like the IOT stuff except it's actually useful.
posted by Bringer Tom at 7:58 PM on October 6, 2016 [14 favorites]


I was reading through some React documentation this week, and realized they had gone and recreated JSPs, the very thing the modern web people sneered at. I turns out I had even less respect available for them...
posted by combinatorial explosion at 8:00 PM on October 6, 2016 [5 favorites]


Something is broken. Because people are trying to develop GUI-style apps in a document rendering engine, using a programming language so bad that the entire thing has to be abstracted away, and then abstracted away again, before the task even becomes tractable.

All for the prize of a website that chokes a decent desktop browser and is basically unusable in a mobile browser. We did it!
posted by jason_steakums at 8:01 PM on October 6, 2016 [17 favorites]


Or to put it another way, I can't wait for the browser-based UI people to collectively pull their heads out of their assets. I'm not holding my breath on that one - what with the monstrosity that is node and npm.
posted by combinatorial explosion at 8:01 PM on October 6, 2016 [1 favorite]


I'm also a big fan of the CircleCI article that inspired this, having recently decided to move away from Docker for deployment:
So I just need to split my simple CRUD app into 12 microservices, each with their own APIs which call each others’ APIs but handle failure resiliently, put them into Docker containers, launch a fleet of 8 machines which are Docker hosts running CoreOS, “orchestrate” them using a small Kubernetes cluster running etcd, figure out the “open questions” of networking and storage, and then I continuously deliver multiple redundant copies of each microservice to my fleet. Is that it?

-Yes! Isn’t it glorious?
posted by whir at 8:02 PM on October 6, 2016 [6 favorites]


Was discussing this with my co-worker today and how we wanted to leave front-end frameworks altogether in order to go back to making sites that work without javascript. Our next project will probably involve turbolinks or something similar. We'd much rather have the server serving stuff with python or ruby and the front end just front-ending rather than a giant one page angular or react app.

Also, I must confess to a certain amount of levity when I sneak in some jQuery in a template somewhere without anyone noticing
posted by localhuman at 8:04 PM on October 6, 2016


Said it before, will say it again. If there's a web developer Olympics, one of the events will be trying to get a client's website and toolchain up and running in under two hours.

What do you mean this requires two different repositories, Tomcat, Maven, bower, npm, grunt, Apache, and a little rock I found on the beach that promised it will be my friend? I just wanted to change a comma!
posted by fifteen schnitzengruben is my limit at 8:06 PM on October 6, 2016 [12 favorites]


What they make hard is producing an application with any visual appeal whatsoever. You've got to really get down in the plumbing if you don't want the look and feel of 1996.

Ahhh, Visual Studio - giving you ~65% of what you need to do a good job. Redmond is nothing if not consistent.
posted by Slap*Happy at 8:06 PM on October 6, 2016 [4 favorites]


Most days I don't get much above C and the past few days I've been writing some real-mode 16-bit x86 assembly to bring up Linux and Xen on a new platform since the CPUs still boot up like its 1979. Once in a while it is necessary to learn a different architecture, although I haven't had to program an Alpha or MIPS machine in years and should probably garbage-collect those neurons eventually. For the most part the tooling has been consistent for years.

I don't know how the front-end engineers handle the churn. It seems very hard to develop proficiency with a tool set that undergoes such radical reinvention every few months.

Tried to post this via lynx, but the submit button didn't work. :unhappy face:
posted by autopilot at 8:10 PM on October 6, 2016 [16 favorites]


Wait, how many people use lynx here?
posted by The Gaffer at 8:14 PM on October 6, 2016 [6 favorites]


I don't know how the front-end engineers handle the churn. It seems very hard to develop proficiency with a tool set that undergoes such radical reinvention every few months.

You don't develop proficiency so much as get skilled at figuring out how much duct tape you need to get the thing you're working on at the moment to work with the framework version you're given. That's part of why so many frameworks and tools exist, because it seemed smarted to build it oneself, since then at least you'd have a very good understanding of all the ins and outs, instead of constantly having to play catchup with the whims of the adderall-addled minds powering the latest startup.
posted by dis_integration at 8:17 PM on October 6, 2016 [6 favorites]


Wait, how many people use lynx here?

It's 2016. Everyone's using elinks.
posted by tonycpsu at 8:17 PM on October 6, 2016 [23 favorites]


personally, given that it's 2016 and I live on an ipad, I read the election threads via a python script i pythonista that calls requests and parses with BeautifulSoup to get favorite information, calls functions from numpy to normalize the data points and spits out my own 'favorites' stream for the page complete with matplotlib charts of the favorites distribution and some stats on the standard deviations threshold needed to trim the number of comments to something reasonable.

Simple.
posted by mce at 8:23 PM on October 6, 2016 [4 favorites]


I started down the angular2/npm road a few months ago and ended up backing out of the room slowly without making eye contact. Now I just do simple JQuery/Knockout/Bootstrap front-ends, and call it a day.
posted by blue_beetle at 8:30 PM on October 6, 2016 [8 favorites]


Shit like this is why I thank god I do back-end work. It just feels like at some point, something went horribly wrong on the front-end.
posted by tocts at 8:34 PM on October 6, 2016 [5 favorites]


I have a friend who has been making shitty Excel templates for medium size businesses to do accounting tasks for years. She lives in a very nice house in a very expensive neighborhood.
posted by benzenedream at 8:42 PM on October 6, 2016 [25 favorites]




I manage a backend team...we work alongside and occasionally with the web kiddos...sometimes the schadenfreude is just too tasty to resist, but they're still our colleagues and honestly working on large modern websites these days is pretty insane. I feel bad for them.
posted by Doleful Creature at 8:49 PM on October 6, 2016 [2 favorites]


This is why I switched to services/APIs a few years ago. And then to program and product management. I wanted to not have to learn new flavors every 6 months.
posted by matildaben at 9:00 PM on October 6, 2016 [4 favorites]


Egads.

Used to be the sysadmins who would say "down, not across."
Seems the motto belongs with the front end people now.
posted by ocschwar at 9:12 PM on October 6, 2016 [3 favorites]


Heywood, good news. SQL server 2016 can now emit json directly. It can also store and interest json as well.
posted by boo_radley at 9:23 PM on October 6, 2016


This became a big hit in my Twitter circles the other day, and it made me really angry. Because I am a front-end developer, and more importantly I taught front-end web development at a community college for about four years. If someone spoke to one of my students the way that the "experienced dev" in this post speaks, I honestly would have considered disciplinary action against them.

I understand that it's supposed to be satire. But the funny thing is, a lot of beginner-level coders I know started freaking out, because they thought it was serious. They thought they would really have to do learn all this stuff, just to build a simple web page. When of course, it's just fine to use jQuery. Nobody has a gun to your head, forcing you to learn ALL THE TOOLS. Nobody cares--and if anyone does, kick that person to the curb: they're part of a toxic, macho, Hacker News culture that you don't need.

But here's the flipside: I work as a data journalist for a metro paper. I build cool pages that help people read and understand stories on the web. I can only do this stuff because (as people have "mourned," including upthread) it's possible to take a document-based browser and turn it into a real application platform via JS. It would not be possible for me to tell these stories in the same way anywhere else, certainly not in native code. And people like what I build (at least, I'm pretty sure they do, since it's been posted here a few times).

We code most of our stuff in vanilla JS. We frequently use jQuery. But you'd better believe, if we need to do anything complex with data, even just sorting a really big or complicated table, that we turn to toolkits like Angular, or Mithril, or Vue. Because I work on deadline, and in the end, these tools make it possible to create very complicated things in a very short amount of time, and the only trade-off is complexity that my readers will never see and will not care about. We use what's appropriate, when we need to, and I personally would not exchange that for a "simpler" ecosystem under any circumstances.

So it's fine to bemoan what people see as some sort of front-end web insanity (although I've worked in the game industry and elsewhere, and I'm pretty sure this is not limited to the browser). But for me, this piece crosses a line. It's so belabored, and so unfunny, that the point is overwhelmed and it becomes part of the problem instead. Yes, coding is hard. Yes, JS has a lot of trends that you can chase, if you want. I don't care. Stop freaking out my students, unless you're going to offer them some sort of productive way forward (other than "quit").
posted by Four String Riot at 9:24 PM on October 6, 2016 [46 favorites]


Seconding Four String Riot. Tools are a means to an end and not an end in and of themselves. I've done web development on some pretty large scale projects and I've spent enough time in the trenches to grok why things like React and Typescript exist and are useful for large apps with large teams. Would I ever use it for a site that just needs a touch of interactivity? No. If the tool doesn't make your life easier as a dev and as a dev team, then good lord, don't use it. And especially don't think that frameworks and tools will in any way make up for poor fundamental programming skills and a good fundamental understanding of the web as a platform (e.g. plain HTML, CSS and Javascript) in the first place.
posted by Aleyn at 10:07 PM on October 6, 2016 [4 favorites]


I understand that it's supposed to be satire. But the funny thing is, a lot of beginner-level coders I know started freaking out, because they thought it was serious.

It's 2016. Satire is obsolete.

Put another way, this *is* serious. The satire is only the thinnest layer of arch suggestion. The arguments satirized here are out wandering in the wild in complete earnestness.

But you'd better believe, if we need to do anything complex with data, even just sorting a really big or complicated table, that we turn to toolkits like Angular

I guess I believe you might turn to Angular for a complicated table; the industry has, after all, held up Angular as a solution to a problem that as far as I can tell very few people can even define.

But... for my part, if you tell me that it's actually helping you create something very complicated in a short amount of time. Nope. I don't believe you; I strongly suspect that you're deluded or straight-up lying about that. In all of the Angular apps I've built out, Angular hasn't made anything easier or covered up any kind of complexity, it's added it -- it leaks its own conceptual and implementation complexities like hell all over the development process, and it does it for a set of abstractions that in the end aren't that helpful and have better competitors. Having to understand digest cycle details and adopt to its style of scope chains is not a reasonable trade off for buggy two-way data binding, and that's before we get into astronaut architecture land with Factories/Services/Providers.

Yes, JS has a lot of trends that you can chase, if you want. I don't care. Stop freaking out my students, unless you're going to offer them some sort of productive way forward (other than "quit").

Your students should be freaked out. The industry has a problem where a lot of mere churn is sold as progress. If what you're trying to do is prepare them for the industry -- or, better yet, send people out into the industry better prepared to improve it -- then you should be a little freaked out too. But if you don't care, by all means, feel free to not care in a manner that doesn't call out people who do.
posted by wildblueyonder at 10:34 PM on October 6, 2016 [30 favorites]


I've been a professional front-end developer for 12 years and, before that, a hobbyist developer for decades. I totally get the writer's frustration. Web development is a messy moving target.

That said, in my opinion (and I'm not alone), React is lovely. It's useful, elegant, and simple. I've been using it for a year, (along with redux ... sorry, another buzzword ... which is also lovely), and it's made my job easier and more fun.

In almost all cases, if react gets complicated, you're doing it wrong. And, in my experience, anyone who knows HTML can pick it up in a day or two. Again, if there's all kinds of complex JavaScript in a react component, you're doing it wrong. I'm generalizing. Sometimes, complexity is necessary. But those are rare cases. Complicated business logic doesn't usually belong in react components.

React is much closer to vanilla JavaScript than jQuery, though it's silly to compare them, because they mostly do different things. One of my favorite aspects of react is that it's close to transparent to me when I'm coding. When I write react, I mostly just write JavaScript.

And, though it's popular to diss JavaScript, I love it--especially ES6/7 (the newest versions of the language). I won't argue with the folks who say it's flawed. Parts of it are a mess. But the functional stuff, the closures and whatnot, are really expressive and fun (once you learn them).

Most of the people I know who hate JavaScript and React are non-programmers who figured web development would be easy and are frustrated that it's not. I would be frustrated, too, in their shoes. I get it. But those folks would be equally frustrated if someone forced them to learn C or Java. It's not JavaScript they hate; it's programming.

Or they're professional developers--experts in PHP, Python, C# or whatever--and they're mad because they figured JavaScript was a simple domain-specific language they could pick up in a day or two. They discovered it was quirky and different from what they're used to. They didn't expect to have to put as much effort into learning it as they do into their main language.

I am not trying to brush it's bad parts under the rug. They exist. They're for-real bad. If I could wave a magic wand, I would make browsers speak other languages. But JavaScript is far from all bad, and parts of it are lovely.

JavaScript-programming is a real skill. It's not something you can learn over a weekend--not if you want to do the things many folks want to do on the web these days: create rich, dynamic applications.

Some of the criticism is valid. At other times, it sounds to me like people saying, "Fuck these surgical instruments! They're so hard to use. All I want to do is remove a tumor from my friend's brain. Why does it have to be so difficult. You're telling me I need years of med school and I have to constantly read medial journals? No thanks!"
posted by grumblebee at 10:38 PM on October 6, 2016 [15 favorites]


I guess I believe you might turn to Angular for a complicated table; the industry has, after all, held up Angular as a solution to a problem that as far as I can tell very few people can even define.

But... for my part, if you tell me that it's actually helping you create something very complicated in a short amount of time. Nope. I don't believe you; I strongly suspect that you're deluded or straight-up lying about that.


You're welcome to look through the Seattle Times GitHub repos if you like. We're very open about our development, and some of it's crap, and some of it is (in my opinion) very cool. I'm not going to pretend that we're only building massive, beautifully-architected works of genius here, but if I need to create a data visualization (table or otherwise) where readers can sort/filter/manipulate the information and see those changes reflected in the DOM, Angular's a really fast, easy way to get that done. It's also really good at prototyping interactions, so we can try out a few storytelling approaches before settling on one. It is, at least for our case, the right tool for the job.

It's so funny that my comment was basically, "this industry is scary enough as it is, let's not create a toxic learning environment," and the reaction was to tell me that I'm lying or deluded about my technical skills. This is exactly what I don't think is productive, and what I don't appreciate in a classroom. Contrast that with what I've always tried to teach, which is that these tools exist for a reason, and if someone learns the fundamentals of the platform and the language, it's possible to use them (or not) in a calm and rational way.
posted by Four String Riot at 11:38 PM on October 6, 2016 [10 favorites]


The best way to describe my problems learning front-end stuff over the past year or two was there was no problem-solution ordering. That is, as someone without much experience, I don't have a very good understanding for when to trade simplicity for power. Instead I just jump at whatever gets lots of favorable comments on hacker news or whatever accompanying tools a tutorial is recommending.
posted by ropeladder at 12:05 AM on October 7, 2016 [9 favorites]


I wonder what the overlap is between the group of people who loves this type of article, and the group that JUST. CAN'T. BELIEVE. how expensive housing has gotten in the Bay Area.

While people like to go a overboard with their JS tooling, they aren't paying all those boys and girls $250k a year to write some HTML tags.
posted by sideshow at 12:22 AM on October 7, 2016 [1 favorite]


At other times, it sounds to me like people saying, "Fuck these surgical instruments! They're so hard to use. All I want to do is remove a tumor from my friend's brain. Why does it have to be so difficult. You're telling me I need years of med school and I have to constantly read medial journals? No thanks!"

The infuriating thing about JS isn't the difficulty of becoming AND staying fluent and up to date, but the stupid reasons for why it's so difficult. The shortcomings of the language itself and its nonexistent standard library aside, rather than working together to standardize on almost anything and to let almost anything stabilize and improve gradually over time, the community is hell-bent on reinventing all the wheels all the time, at enormous cognitive cost and very little non-subjective, non-taste-dependent benefit. I've never seen NIH syndrome this bad, at this scale. The surgery profession, or other similarly very difficult professions, don't suffer from this.

To contrast: the worst Python ever got was with the mess that was package management, but lo and behold, people came together, worked hard for a long time, and now it's a solved problem for all intents and purposes. The Python 2 to 3 move is taking a long time, but the patience involved and the controlled manner in which it is being done is downright admirable.

Here's the complete list of non-trivial JS frameworks and libraries that I've actually appreciated for making my life as an occasional frontend developer easier, in chronological order of my introduction to them: jQuery, lodash, Moment.js, React (though its recent dependence on Babel is a fucking pain), DataTables and React-Boostrap. That's it. Everything else is either too insignificant to mention, useless noise or an unnecessary complication. npm, Babel, ES2016, AMD/CommonJS, the god damn module managers and task runners etc. can all go fuck themselves.

Whenever I have the choice to do so, I have one script tag for the minimized version of each of the aforementioned libs/FWs (well, two for React), and use vanilla HTML5 and CSS for everything else. There is nothing I couldn't accomplish with these tools, and I'm in a privileged position of not having cult-of-the-new-JS-hipster-assholes snickering at my choice of tools, because I don't engage with the community and I work with actual adults.
posted by jklaiho at 12:32 AM on October 7, 2016 [18 favorites]


But... for my part, if you tell me that it's actually helping you create something very complicated in a short amount of time. Nope. I don't believe you; I strongly suspect that you're deluded or straight-up lying about that. In all of the Angular apps I've built out, Angular hasn't made anything easier or covered up any kind of complexity, it's added it -- it leaks its own conceptual and implementation complexities like hell all over the development process, and it does it for a set of abstractions that in the end aren't that helpful and have better competitors.

Angular is maybe not the best example here because while it may make it easier to create certain kinds of complicated things in a short period of time if you know it well it also has (in my own experience with v1) a pretty serious learning curve and significant amount of overhead - making it potentially a painful choice to pick up for a small project (assuming it has to get done). But I mean - I think there are friendlier choices than that.

This seems like an expression of a real feeling you get working in JS, exaggerated for effect.
posted by atoxyl at 12:39 AM on October 7, 2016 [1 favorite]


The last few projects I worked on, I was the front end lead so we used 0 JavaScript libraries. No jQuery, no React, none of the metalanguages back end developers wrote to prevent them from learning how to write JavaScript (e.g. Coffeescript). In 3 years or so when the site needs a major update, anyone who knows how to write JavaScript won't need to do anything other than look at the code and read the comments to understand how to edit the site.
posted by eustacescrubb at 12:46 AM on October 7, 2016 [5 favorites]


The shortcomings of the language itself and its nonexistent standard library aside, rather than working together to standardize on almost anything and to let almost anything stabilize and improve gradually over time

That's one of the catches though - Javascript the language is getting better, but in order to actually use the stuff from the latest spec without jettisoning old browsers you have to set up all this infrastructure.
posted by atoxyl at 12:48 AM on October 7, 2016 [1 favorite]


That's one of the catches though - Javascript the language is getting better, but in order to actually use the stuff from the latest spec without jettisoning old browsers you have to set up all this infrastructure.

This Medium post by Thomas Fuchs has a list of upcoming changes to the language. I'm actually looking forward to some of them, but he makes it clear that the real issue with the core of JavaScript is the lack of a standard library. I really only mentioned either for completeness' sake; no doubt they influence the dismal current state of affairs that the OP link is about and that I spent most of my comment on, but they don't make it an inevitability.
posted by jklaiho at 1:01 AM on October 7, 2016 [1 favorite]


Are people still using D3 for data visualisations and interactives, or has that gone the way of jQuery, YUI and MochiKit?
posted by acb at 1:08 AM on October 7, 2016


Are people still using D3 for data visualisations

Well a whole pile of other software, eg. a bunch of cool R and Python interactive data vis libraries, are still outputting it. What has it been replaced with this week, pray tell?
posted by Jimbob at 1:13 AM on October 7, 2016 [1 favorite]


he makes it clear that the real issue with the core of JavaScript is the lack of a standard library

Yeah I think I agree with that.

(Also jQuery is not even close to gone in reality it's just probably finally passed its peak.)
posted by atoxyl at 1:19 AM on October 7, 2016 [2 favorites]


It's so funny that my comment was basically, "this industry is scary enough as it is, let's not create a toxic learning environment,"

Yeah, that leaves out the part where you essentially dismissed the concerns the article represents as hyperbole and went for blaming the messenger instead.


and the reaction was to tell me that I'm lying or deluded about my technical skills.

To be precise, my charge was that you're lying or deluded about your specific assessment that Angular helped you build things faster. Neither broadening that charge nor coming back with "Angular made it easy for us to do interactive visualizations because it gave us data binding and some degree of separation of presentation from content" is going to help your case.
posted by wildblueyonder at 1:31 AM on October 7, 2016 [4 favorites]


My main problem with most of these frameworks is that they feel like they're from and for people who don't really care for the web very much. It is either impossible or takes real wrangling to use them in a way that the web app still works if the browser for some reason can't download or use the JavaScript code.
posted by dominik at 1:42 AM on October 7, 2016 [5 favorites]




When it came to deciding what third-party code we wanted to use to handwave over some of the ugly syntax of just-use-pure-javascript, we asked one question of each of the options first: is this a library, or is this a framework? If it was a framework, we immediately took it out of consideration. Because we wanted something we could pick and choose from, something we could use when we felt like it, something we could - potentially - move away from at some point in the future. An application is married to its framework; divorces are messy and complicated and nobody survives them unhurt. But you can get away with just dating your libraries.
posted by Fraxas at 2:45 AM on October 7, 2016 [12 favorites]


Those of you lucky enough to be a back-end or a front-end developer: good for you!

I'm the IT department for my company. I write every line of code (back end and front) on some pretty hefty web apps, I'm the DBA, I'm the project manager, I'm tech support, I support and maintain email, I'm IT support for the office (150 miles away), I'm the person who has to ensure that our infrastructure is resilient, secure and free of vulnerabilities. I write the company's documentation and policies and deal with external pen tests and security audits from some of the world's biggest companies - those people ask a LOT of questions, and I have to respond to a detailed security questionnaire at least once a week, and work on remediation plans every time they find a hole in a policy or implementation. About the only thing I don't do is maintain the hosting environment.

The rate at which I can learn new tools is basically zero. I made the switch from straight Javascript to JQuery a couple of years ago, and I'm glad I did. And I think I'll stick with JQuery/JQueryUI for the immediate future. I'm not sure it's saving me time; it's more about what I can achieve in terms of making things easy and pleasant for the end user. Not having to reload the entire interface and recreate the state of everything is wonderful; JQueryUI's dialogs, now that I have a decent understanding of them, have opened up the scope of what I can enable end-users to do. The tools are only part of it, of course - you can make things unusable with any language or framework. Did I say I'm the designer as well, by the way?

I'm not sure I even want the luxury of being able to be a toolset dilettante. Now that I'm in my 40s I've come to feel that getting the job done with the least amount of pain is more important than being up-to-date. Time spent learning or configuring a complex chain of tools is time lost. Nobody looks at a piece of bespoke furniture and asks what brand of clamps they used, or what technique they used to sharpen the chisels. When you look at the bigger picture (developers building things for a much larger group of non-developers) it becomes clear that developing for the web is much the same - nobody cares as long as it works.
posted by pipeski at 3:10 AM on October 7, 2016 [19 favorites]


Web development - a pain in the balls and getting worse, not better.
posted by GallonOfAlan at 3:45 AM on October 7, 2016 [8 favorites]


The problem is that some people think that everyone is developing a website that needs to scale like Facebook or Twitter. And yeah, if that's your goal, then perhaps you should be planning a scalable, clustered, automated approach to everything from the get-go.

But I seriously doubt that most developers even need to consider that. So I find the whole "automate the fuck out of your bespoke JS meta-variant" bullshit tedious.

Don't get me started on CSS frameworks! Fuuuuuuuuu...
posted by sutt at 3:56 AM on October 7, 2016


Now that I'm in my 40s I've come to feel that getting the job done with the least amount of pain is more important than being up-to-date.
QFT. And you don't even have to be in your 40s to apply this lesson.
posted by the painkiller at 5:10 AM on October 7, 2016 [6 favorites]


And here's an almost completely unsubstantiated opinion from someone who is literally learning about the JS ecosystem in 2016: it seems to me that these frameworks are designed for use by teams and not individuals. It's been hard to put my finger on, but sometimes even within frameworks it seems as if the designer(s) have gone out of their way to firewall off certain functional domains from each other, and at times I think I can tell the differences in approach between the teams that developed each subdomain of the framework. I'm willing to concede I'm imagining things, but the whole affair feels so...Balkanized somehow. It does not seem tailor-made for the small development group 1-5 people in size.

Also JAVASCRIPT WHY U NO STANDARD LIBRARY you miserable fucks
posted by the painkiller at 5:22 AM on October 7, 2016 [3 favorites]


I don't really care about complexity. I just want the web to be accessible. But a lot of it is walled off -- not through government censorship, but through the bloat that accompanies increasing complexity. The slow, developing world internet that I use can't load it. It's too data-intensive. Then there is also the issue that many people here can only access the web through their mobiles.

Facebook manages to work reliably despite its complexity. Even when I can't log in to my email, I can log into Facebook. I suspect that's because it's chasing global market share, and has prioritized loading times. But meanwhile, I often can't load news pages.

Like, if you were going to ask some glassy-eyed idealist why the internet is good, they would probably mention the ability to stay informed.

Here, there is a lot of government corruption, and political instability, and the main source of news is the nationally-run television station. If you want another view, you either have to pay for an expensive satellite package (out of reach of most) or turn to the internet. What good is all this fancy data visualization and presentation if I can't load the page, though?
posted by Kutsuwamushi at 5:35 AM on October 7, 2016 [6 favorites]


Pure JavaScript is fun, 2016 TrendyJavaScript makes me feel like I don't attend the right kind of SoMa parties.
posted by RobotVoodooPower at 5:46 AM on October 7, 2016


But you'd better believe, if we need to do anything complex with data, even just sorting a really big or complicated table, that we turn to toolkits like Angular

Some people, faced with the problem of displaying large amounts of data, think "I will use Angular!"

Now they have two problems.

</smug former frontend developer who now writes APIs>

WHY ARE YOU SORTING CLIENT-SIDE?
posted by Mayor West at 6:03 AM on October 7, 2016 [8 favorites]


You realize React is from Facebook, right? And it can have kind of a slow load unless you prerender on the server but after that it should be fast because it is diffing the DOM and the Virtual DOM and only changing what needs to be changed — so much lighter than even jQuery.

I dunno, you all just sound like cranky people who want to write C or Python their whole lives, which is cool and all, but you don't need to shit all over the front end. NPM, for instance, is just package management. And frankly it is a lot more robust and pleasant than pip or gems. Node just runs JS on the server. After that, Babel and a lot of tooling are to let devs access new functionality without waiting for browsers to catch up or abandon old users. (Which is a big thing in front end! You have a lot less control over forcing updates but you and your designers still want to make cool stuff!) Ember and React now have CLIs that will autogenerate you projects so you don't have to write all the task running yourself anyways.

CSS frameworks let you write less code and cause fewer collisions that traditional declarative CSS (which also is cool and I will fight all you front-enders who think you're too good for it).

And yes, we still use d3 — it is a pretty great tool. The v4 release modularized everything so you don't have to load the whole library if you don't want to. Of course, then you need something to compile all your modules — like rollup or webpack — but either you are doing that anyways or you load the whole library old-style and not worry!

JS is growing up and it is pretty cool. And sure, there are a bunch of frameworks competing for mindshare because frameworks are fun to write and writing a popular one is a great way to lift yourself out of everyday dev-land, so lots of people like to throw their hands in. If you aren't trying to get a JS job at a big fancy place, feel free to chill and see what shakes out on top. If you want to make websites that would work in 2006 and you aren't selling anything where modernity matters, hang out in jQuery town forever. (Many devs who want to stay up-to-date will go somewhere more dynamic, but that's just a tradeoff.) If you're a student, don't worry. Make basic stuff and learn more complexity as you need to.

But these are dev wars, so let's all get bent out of shape that the world has changed.

Anyways, I gotta get back to my React Native app, which let's me make a phone app without having to learn (tons of) Obj-C, Swift or Java. Thanks Javascript!
posted by dame at 6:24 AM on October 7, 2016 [5 favorites]


WHY ARE YOU SORTING CLIENT-SIDE?

Most users of an application that presents tabular data expect to be able to sort it by column on demand. You really want to ask the server to resend all the same data, but sorted differently, every time they click a column header?

My users would shit a brick if they had to wait 5 seconds to sort their data.
posted by thelonius at 6:26 AM on October 7, 2016 [9 favorites]


Fuck these surgical instruments! They're so hard to use. All I want to do is remove a tumor from my friend's brain. Why does it have to be so difficult. You're telling me I need years of med school and I have to constantly read medical journals? No thanks!

Frozen Anna brain surgery
posted by flabdablet at 6:40 AM on October 7, 2016 [2 favorites]


WHY ARE YOU SORTING CLIENT-SIDE?

Like a lot of newsroom data teams, we don't have a "server" for interactives. We publish pre-baked content to S3, because it's cheap and reliable. But that means I can't perform dynamic sorting anywhere but the client, because there's nowhere else to do it.
posted by Four String Riot at 6:46 AM on October 7, 2016 [5 favorites]


WHY ARE YOU SORTING CLIENT-SIDE?

"Business Logic" is above my pay-grade, and we don't have access to the backend, but our clients ( financial industry ).

They want the works,
They want the whole works!
Presents and prizes and sweets and surprises in all shapes and sizes,
And now!
They don't care how
They want it now!
They don't care how
They want it now!
posted by mikelieman at 6:54 AM on October 7, 2016 [2 favorites]


If your dataset is too big to reasonably transmit to every user, you still need to sort server-side.

I can appreciate the framework/library overload that the JS community is now experiencing (and I place the blame for that squarely at the feet of the Facebook ecosystem, but I digress).

So, recently, I decided to write a small bit of form-validation code using nothing but ES5 and the DOM.

It was an unmitigated nightmare. The DOM has come a long way, but it still suuuuuuuuuuucks. Even only targeting modern browsers, my code was full of browser-specific hacks, homegrown (ie. untested) helper methods to add "modern" conveniences like .map() and.reduce() to a NodeList, and ridiculously clumsy event-handling code.

In the end, I wrote about 100 lines of code that probably would have reduced down to 20 lines of jQuery, or 5 lines of Angular. In the end, there is NO WAY that my version was more maintainable than the same code would have been if I'd used a library.

There is literally zero chance that a JS developer in 3 years won't be able to comprehend code written with jQuery and Lodash. However, they very likely won't be able to understand the hacks that you put in to ensure browser compatibility or try to determine if the odd behaviors in your helper methods were intentional or not.
posted by schmod at 7:00 AM on October 7, 2016


Embedded developer here.

On one hand I can sit back and read this with a crazy-high smug level and think "wow, look at all the shit you guys have to put up with to get a button on the screen to do something".

Then I see people prototyping shit on Raspberry Pis (1Ghz ARM devices) crowing "Wow! I can make an LED turn on using node.js and only 3 megabytes of code space!"

And then I realize we're all fucked. Javascript is a virus.
posted by JoeZydeco at 7:11 AM on October 7, 2016 [8 favorites]


My main problem with most of these frameworks is that they feel like they're from and for people who don't really care for the web very much. It is either impossible or takes real wrangling to use them in a way that the web app still works if the browser for some reason can't download or use the JavaScript code.

Out of curiosity, what is your notion of what "the web" is? The idea of "the web" without JavaScript is like a computer that can't be programmed. If you just want to display a static page from the server, no one's stopping you, but the web is capable of a lot more than that. It strikes me that much of the disagreement in this thread comes from people who are trying to solve different problems using the web, who have different requirements from their customers, etc.
posted by hyperbolic at 7:11 AM on October 7, 2016


this flavor of the week aspect of dynamic web frontend crap brings to mind that junkie that's totally going to quit after they get just one last hit. "Surely this will be the library/stack/platform/framework that lets me finally stop running on the endless treadmill of self-improvement and actually do useful work!"

I just yesterday read a Stroustroup essay from 2010 where he pointed out that the industry fantasy is the magical framework or development methodology in which robust code is produced by marginally talented programmers who you can swap in and out of projects like factory workers without even having to learn if they're talented.

Do frameworks proliferate because they are so easy to sell as an idea to managers? Or is this the sly revenge of the workers, guaranteeing endless future work contracts for themselves to keep things on decent technology?
posted by mark k at 7:19 AM on October 7, 2016 [5 favorites]


If your dataset is too big to reasonably transmit to every user, you still need to sort server-side.

This is an example of what I'm talking about with different use cases. Presumably their data is NOT too big to reasonably transmit to every user, so they are making a perfectly valid choice to sort client-side. Not to mention that in many cases, as was pointed out, there is no server to begin with. I've in the past had to write interactive reports that could be viewed without needing network access. All the data is static, it's the view (tables, charts, calculations) that changes.

Mind you, I wouldn't have selected Angular to render a big interactive table, because with the way it binds data, it's so tricky to make sure you're not rerendering more than you have to. React is much better for that sort of thing because it gives you so much more precise (and comprehensible, at least to my primitive mind) control over when things are rendered. In fact this is the precise use case (giant interactive client-side tables) that got me interested in React in the first place.
posted by hyperbolic at 7:22 AM on October 7, 2016


"Node just runs JS on the server."

This made me snort!
posted by sutt at 7:23 AM on October 7, 2016 [2 favorites]


You realize React is from Facebook, right?

Why should we care where it comes from? Are you saying that if it's good enough for Facebook, then it must be good enough for everyone?

I dunno, you all just sound like cranky people who want to write C or Python their whole lives, which is cool and all, but you don't need to shit all over the front end.

People who just want to write C or Python their whole lives probably aren't shitting on the front end. Why would they care? At the same time, it turns out that a lot of us who work primarily with other back-end / mid-tier technologies by day also have to be at least replacement-level front-end coders, whether it's to prototype a UI for something that management wouldn't bother dedicating an entire UI team to do, or just to understand what the UI folks are doing so that the integration between the tiers is scalable and maintainable. And what a lot of us are seeing, and where I think this piece was coming from, is that the JS framework landscape is so balkanized that it impedes progress for the development community as a whole.

You disagree, and that's fine, but it's possible to make these points without characterizing anyone who disagrees with you as a Luddite. It's not "dev wars" unless two sides are being snippy towards each other personally, and I think we can be better than that here.
posted by tonycpsu at 7:23 AM on October 7, 2016 [4 favorites]


I'm in the thick of a web-app whose front-end is a ball-of-mud rolled with jQuery.

Let me say that no matter how arcane and esoteric JS solutions (like react) are, they pale in comparison to the morass of side-effects that is a 'traditional' front-end jquery app.
posted by kuatto at 7:42 AM on October 7, 2016 [1 favorite]


Are people still using D3 for data visualisations and interactives, or has that gone the way of jQuery, YUI and MochiKit?

I love D3 but I find the jQuery-style selectors to be a problem. It makes it too easy to build brittle spaghetti code, which is 90% of what I see on the web with D3. The other issue I have with it is that many of its functions render to the DOM under the hood, which makes it tricky to integrate into an application where you want to control when and how rendering happens. Its lifecycle hooks (enter, exit, update) are also not as granular as they could be. I've had good luck simply using React's lifecycle hooks instead for rendering charts/graphs, and using D3 exclusively as a utility library for manipulating data in preparation for rendering. D3 scales are still super useful.
posted by hyperbolic at 7:45 AM on October 7, 2016 [1 favorite]


Out of curiosity, what is your notion of what "the web" is? The idea of "the web" without JavaScript is like a computer that can't be programmed. If you just want to display a static page from the server, no one's stopping you, but the web is capable of a lot more than that.
Oh, yes, I agree with you - JavaScript is great and a well-made web app is the best. It's just super frustrating to see the very idea that JavaScript, which is extremely fragile, is often required to work perfectly for a page/app to offer the basic functionality at all. JS breaks all the time: weird browser issues, half-baked browser extensions, slow internet connections, CDN outages, a typo in the deploy script, ad-blockers…
While I see how advanced features of a web app might be gone, the basic tasks should still be possible. And if the "web app" is nothing more than a content site, then that is even more true. And don't get me started on all the previews of content pages that only have
{{header.description}}
because they are now Angular apps and therefore hidden to the OpenGraph parser.
posted by dominik at 7:57 AM on October 7, 2016 [1 favorite]


This made me snort!

Oh, okay, Node is a runtime that lets you run JS not in the browser or "server-side" as people might call it. It has a nice API to interface with the file system and other parts of the OS. Is that okay with you?

Why should we care where it comes from? Are you saying that if it's good enough for Facebook, then it must be good enough for everyone?

No, it was a response to the comment about how the web takes forever to load except Facebook, who care about global access.

At the same time, it turns out that a lot of us who work primarily with other back-end / mid-tier technologies by day also have to be at least replacement-level front-end coders, whether it's to prototype a UI for something that management wouldn't bother dedicating an entire UI team to do, or just to understand what the UI folks are doing so that the integration between the tiers is scalable and maintainable. And what a lot of us are seeing, and where I think this piece was coming from, is that the JS framework landscape is so balkanized that it impedes progress for the development community as a whole.

So you are basically mad that other people's full time jobs aren't something you can just pick up in your spare time because "management" want you to? You are right, we are better than snippiness, but I will note my comment came after ~60 whining about how JS has changed.

And the thing is, there are tons of things to criticize. People are condescending jerks sometimes about the new hotness and a lot of that is, I think, rooted in the ways devs are treated as disposable and interchangeable and fear of being left behind. That is real and interesting and far more worth talking about. Likewise, there are interesting discussions to be had about standardization of tooling vs. flexibility and the scourge of the one person who chooses a complex chain for, again, some feeling of security. But the way to have that conversation is not to lament all the interesting capabilities available.

And I reiterate: making stuff with vanilla JS and CSS is not bad. When I do code art projects, I do that a lot because I am lazy and not always excited to mess around with tooling either. I just want an interesting discussion that starts with an understanding of the ecosystem and respect for the front-end.
posted by dame at 8:08 AM on October 7, 2016 [3 favorites]


PS: The Luddites were cool and had some interesting points.
posted by dame at 8:12 AM on October 7, 2016 [3 favorites]


No, it was a response to the comment about how the web takes forever to load except Facebook, who care about global access.

OK, but there are many other variables that go into load times than the specific set of JS libraries and frameworks being used, which makes your response about React seem like a bit of a non-sequitur, especially when you didn't quote the thing you were responding to.

So you are basically mad that other people's full time jobs aren't something you can just pick up in your spare time because "management" want you to?

No. In case you're not familiar, the term "replacement level" comes from sabermetric analysis of sports, and as I was using it, means roughly the skill level of someone who isn't already working full-time in front-end development. Presumably, the good front-end developers mostly have jobs already. I can't be one of them, because I don't do it full-time. I do, however, have to be able to fake it enough to build UIs for things now and then, and to be able to have productive interactions with UI specialists when working with them. That's what I was talking about.

You are right, we are better than snippiness, but I will note my comment came after ~60 whining about how JS has changed.

Zero of which, by my count, were directed at other commenters here. Criticizing the state of the JS ecosystem is not a personal attack.
posted by tonycpsu at 9:00 AM on October 7, 2016 [7 favorites]


The latest round of JS frameworks (not jQuery-era) really do remind me of the bad old Java J2EE/Spring/Struts/design_patterns days. J2EE frameworks promised to destroy your soul up front and usually succeeded. JS frameworks promise to buy you beer and play hackeysack with you, but end up talking for an hour about how you can do your first 21k if you start training tomorrow.

The DIY module system is one of those things. It sounds theoretically cool, but then you're knee-deep in RequireJS boilerplate, or searching GitHub issue trackers to get Atom's TypeScript compiler to use a different config for web workers. You just want some benevolent module manager to come and set everything right, even if you lose some freedom. ES6, too... Babel is kind of a mess internally.

Certainly the lone developer is much more grumpy with this stuff than medium-large teams where devs can easily train each other. And the core concepts are mainly solid. I didn't find it, er, "delightful".
posted by RobotVoodooPower at 1:36 PM on October 7, 2016 [3 favorites]


As I said, I don't care about complexity; I care about accessibility. I pointed out Facebook as an example of a site that is both complex and accessible.

You're reading more into my comment than is there if you think I have anything to say about React. My point is simply that when accessibility is not prioritized, increasing complexity means that people get left behind. There are real consequences.
posted by Kutsuwamushi at 6:13 AM on October 8, 2016


As someone who spent way too many years deep down in the minutiae of front-end web engineering, I really appreciate the older days, when websites worked.

(Can you show me any of your work from that decade? No? Oh, I see. It doesn't work anymore, or it now looks embarrassingly dated? So it's basically nothing now. Shame. You should have maybe written a novel instead.)
posted by rokusan at 9:03 AM on October 8, 2016


I hate frontend so much though, and wish I could get a job doing systems programming or embedded work or some such. But every job out there is just web web web.

Have you considered iOS? I do 80% of my work in a language that's over thirty years old and I'm fighting off recruiters with a stick.
posted by Itaxpica at 3:16 PM on October 8, 2016 [2 favorites]


The entire careening, tottering mess that is the JS ecosystem is about constantly overcoming hobbling limitations. Beyond the fact that the language was designed quickly to work well in a shockingly limited scope, the entirety of async programming in Javascript has to do with the fact that the event loop is a hack to offer concurrency without actual parallelism. The single threaded browser environment gave us the event loop; the event loop gave us callbacks; callbacks gave us a cascade of approaches like promises and futures to make them look like they weren't callbacks; all those contortions resulted in a variety of UI libraries that made a virtue of state management via race conditions while pretending that their conventions were ontologically superior.

I'm deep in the muck of this now as I transition a non-trivial Meteor app from Blaze to React while overhauling the internal architecture. React is relatively nice, but only insofar as the experienced approach to a mess like this is to be brutal about simplifying and making everything explicit. Once you internalize "state management via race conditions", you can start appreciating how functional programming really does help because immutability and functional purity are tremendous simplifiers. Once you start to actively distrust every bit of code that arrives via "npm install" you can start being the kind of rule-by-fear-and-fire tyrant you should be, who codes without favouritism or mercy. You become a dark prince of results. You care about nothing but Jenkins ok'ing the latest build so you can deploy and start drinking and reading HN posts about a new stack.

I do feel a bit jaded, but I actually also feel pretty good about the work I'm doing now because it's good, interesting work, but also because JavaScript has beaten every bit of sentimentality out of me. I have zero emotional investment in my tools. It's a good place to be.
posted by fatbird at 3:55 PM on October 8, 2016 [9 favorites]


There's another aspect of the high churn JS world that I feel doesn't get called out enough, which is that a big portion of this is jockeying for position within the community: by being recognized as the person behind tool X or framework Y that gets invited to conferences and user groups to speak and enables a bunch of downstream projects. This is how you win in the reputation economy that, like tipping in restaurants, is supposed to be the second part of your compensation package while working in tech sweatshops like Silicon Valley. Your equity might never vest or pay out if it does, but if you're remembered for that toolchain... then you're first in line for another startup gig.

When you make the amount of activity of your github account the measure of your self-worth, you're necessarily going to see a ton of froth at the bleeding edge.
posted by fatbird at 4:03 PM on October 8, 2016 [7 favorites]


Back in my day I spent like 20 minutes writing a stored procedure to get the exact data I wanted and another 10 writing some C# code to grab the data and bind it directly to some nice looking third party grid control that already supported sorting paging and filtering. The end. Not very elegant but it worked ...
posted by freecellwizard at 4:18 PM on October 8, 2016 [1 favorite]


« Older no more tofu   |   What to read while waiting for the end of the... Newer »


This thread has been archived and is closed to new comments