This is a big problem that's addressed quite rarely. There's very few open JS codebases that cover the sorts of concerns most web developers face. There are open codebases for build tools, codebases for graphics editors and web frameworks, but few relevant to writing a typical frontend app and frankly few that are well written.
As a JavaScript developer myself I often wonder if there'd be demand for a 'boring webapp' open codebase, something that could showcase perhaps two or three different ways of writing garden-variety JS applications.
If you fight it, you are in a world of pain and that's even much worse if you don't the design choices they have made in Rails.
Having said that, if you jump into Rails the whole project structure will start to make sense after a while.
I completely agree on your impression of Ruby vs Rails.
I wasn’t familiar with ActionCable, Asset Pipeline or CoffeeScript but felt they were all easy enough. All the basics were still there, the MVC application structure, DB migrations, etc.
I share the sentiment that JavaScript and many other languages used for web development are great but seriously lack some of the essentials Rails provides.
The essentials haven’t really changed so jumping in at 0.14.5 or 5.0.1 shouldn’t really matter.
Come on...
I’ve experimented with most of the alternative frameworks and micro-frameworks. I have a real fondness for Sinatra. I’m happy most modern languages have their own Sinatra but I’m sad that most modern languages lack their own Rails.
Ha so on the name, I’m transparent at least. I’m no longer a programmer but am a business customer for teams building on JavaScript. I think they have much opportunity and suffer from lack of convention in their day to day work.
I think if you're new to most server side languages and javascript SPA's are your wheelhouse your experience will be very foreign and dogmatic feeling. I switch between the two worlds often and am still amazed at how productive I am in ruby/rails.
That was about a year ago, and these days my biggest challenge is identifying and filling knowledge gaps. For instance: the mere fact that ActiveJob exists isn't obvious.
It's such a non-issue.
In fact, what's impressive is how Sprockets (part of Rails asset compilation) can chain together arbitrary file transformations by looking at the extension. `file.coffee.erb.whatever` will get processed as with the tool configured for `.whatever` files, then it'll eval Erb's <%= ... %> tags, and then finally get processed as Coffeescript before being concat into the bundle.
I always thought that it was a really intuitive way to specify transformations.
But the thing is that you need Rails experience to appreciate a solution like that, and it's easier to write off Rails entirely because someone says that it depends on Coffeescript. In reality, Rails just shipped with the Coffeescript handler so that Sprockets could understand .coffee extensions if you chose to write .coffee files.
Technology-hate only serves to confuse beginners by making them think everything is black and white. And by making them think that they are making a mistake by learning one ecosystem over another when in reality everything has trade-offs and it's better to learn something over wallowing in the paralysis of indecision.
Half of these comments aren't even capable of comparing Javascript to Ruby without bringing up Webpack and the complexity of client-side bundling as if Ruby is a client-side language.
Erb / vanilla js is still the default stack for beginners. But they've started to move away from the asset pipeline and they've built in webpack.
Any framework seems "Crazy" and "Magical" at first. But once you get to know it, it becomes clear.
Rails is an opinionated, full featured framework with plenty of bells and whistles.
The core of rails is convention over configuration which means you will have a hard time going against the it.
Rails is like a culture. There are a lot of pre-baked things when you run "rails new blurb", but most of it is useful, and you'd create them anyways. But to a newcomer like me, that's a bit overwhelming. That's my lament about it. Wrt Node.js, that's just a product of lots of ignorance. All you actually need is a JS file, or a makefile with ".js.ps:\n\tpuppyscript -c $< > $@". But the wheel is reinvented with such pace and redundancy that it's a hell of a platform nowadays. Even its creator, which is a very smart guy, has said farewell.
Eg for "Hello World", you're not going to touch 99.9% of the auto-generated code. But you need to know where to look.
That said, could you perhaps elaborate on how studying the innards of PostgreSQL is relevant in relation to ActiveRecord?
Rails absolutely is a framework where you need to abandon some control and trust the framework though. If you need to know exactly how your abstractions work under the hood, it's a poor choice IMO. I doubt there a single person who has comprehensive knowledge of how every single part of Rails works.
SQL is really not going away anytime soon (it's demise has been falsely predicted many many times). It even fits the current language hype in that it's functional!
I love AR, but there are use cases where you just need to create or optimize your queries manually.
Ok, that could be the reason why you don't like Rails :)
Regarding postgres, its innards become relevant when you have partitioned tables with billions of rows and need to run queries on them for analytics purposes. In these cases you often need to manually create some complex queries from scratch; other times, you can use ActiveRecord "magic" up to a point, but then you either need to add special indexes (eg partial indexes, that saved my ass many times), or you need to replace the automatically-generated queries that ActiveRecord uses and which are good for small numbers, but become a bottleneck when scaling.
I agree that a lot of people don't make the distinction between rails and ruby. I had interns who where quite surprised you could use ruby without rails, and that "it's actually a complete language!". Ruby on its own is charming indeed. Rails gets the job done: few other tools enable you to finish a functional MVP in a day or two. But if you start to add gems for everything it just becomes a pain in the ass.
edit: I was f*cking mad when they added coffeescript. fortunately it's simple to disable (just removing the gem and changing a setting for the file generators)
Still quite easy to pull out.
Psyched to see Rails adding native webpack support though.
JavaScript is a beautiful platform and an atrocious language. I do not understand how anybody can tolerate it if they are coming from any other sanely designed language.
Transpilation is what makes JavaScript tolerable. Did I ever mention I love Dart? Because I love Dart.
>With JavaScript, once you move past the basic TodoMVC examples you are pretty much on your own
Yes! Those TodoMVC examples are great! Now write 100,000 lines of code and tell me you don't want to tear your hair out.
>I think there are now 7 different ways of just defining a module.
Thank you! I don't know what the hell is wrong with the community. There is no correct language enforced module system, so everyone rolls their own. It's a mess and nobody seems to care ... probably because if you'e doing that kind of development you simply transpile from a sane language and you side-step JavaScript ugliness.
>The stdlib of Ruby is pretty sensible. JavaScript has many inconsistencies
Yeah. Best not to dwell on it. It is the way it is because of legacy reasons.
>The JavaScript community seems to have the opposite of NIH syndrome
I would say that the JavaScript community is paradoxically suffering from NIH _and_ IH. You roll a lot things in-house and you also add dependencies on 'modules' with single-use functions. The community is really strange. I think its quirkiness is due to being dominated by young kids who have no experience with anything other than JavaScript, so they don't know what they don't know and they don't demand better. The rest of the people simply side-step JavaScript and use TypeScript (or Dart a criminally underrated language).
I find it also funny that JS is at the top of the discussion about of article about ruby.
Many readers will be web developers. The biggest and most lucrative alternative to Ruby in that space is JavaScript.
Therefore: lucaspiller decided to remind people that switching to JS is not a good solution to Ruby's problems.
I wonder about this. C#, Java, Python, PHP, hell, even Scala are all viable options.
If you're writing 1000 lines of throwaway code I agree with you. If you're writing a 100,000 lines of code that is meant to be supported for years - then I disagree wholeheartedly.
for at least 90% of the problems out there, its the the best approach. There are a lot of design patterns out there, but you can do a lot with MVC. From what i've seen, the reason developers tend to shy away from it is because it's TOO simple. They don't feel proud of it, because its so cut and dry. They want to create something unique and interesting and challenging, even if a simple solution would do just fine.
But it's not a balance, or a 50/50 sort of decision making. Really, MVC should be your first choice, and you better have a really good reason for it to not be, and a really viable alternative.
To extend the analogy to its breaking point, just because some people treat every problem as a nail too be fixed with a hammer doesn't mean that you can't use a hammer if you genuinely need to push in a nail.
If we were discussing untrammeled neophilia, though, I'd note that in a fast-moving field it merits the professional to keep up a lively familiarity with the new tools which will likely soon deprecate the old, and it likewise merits the organization invested in such a field to avoid letting that investment grow so stale that it becomes difficult to find good people to work with it. There's really nothing here that hasn't happened with almost any other software specialization over the last few decades. It's only that it happens faster now, because everything happens faster now. There can be a certain fatigue in that, and from the outside - or from the perspective of one who has suddenly noticed that the world has moved on while he has not - it can seem as though there's nothing to it but new shiny things for new shiny things' sake.
I have not found it so; instead I find that today's tools enable those who know how to use them to do more things, better, and faster, than yesterday's tools could support - and I confide that tomorrow's tools will improve the situation still further. But perhaps my own perspective is the one that's flawed.
Aren't you assuming a bit too much?
What normally happens is that those new tools are deprecated sooner than the old ones they are replacing.
I tend to like to hear about people switching languages that also cross paradigms, OO to Actor, Actor to FP, etc..
Why is that a number you care about? Is it causing you actual problems during development, or are you just offended that it's a big number?
Doing this bare minimum of due diligence is easy if you have 10 dependencies, but quite costly for a 1000.
The number is misleading anyway, because many "packaged" libraries that you would normally look at as a single module are split into individual modules for perf reasons.
Consider the destructiveness of someone malicious befriending the left-pad developer, taking the project over, and doing a malicious push.
I'd say the scale of the potential destruction in so many tiny, few-eyeballed modules is unique to the npm ecosystem for better or worse.
It's one of the security downsides of the ecosystem especially in the online casino space where I work. For example, getting an online casino's `npm ls` (full depth) would be a good place to start.
The scale of transitive deps we're talking about when compared to any other ecosystem is quite excessive, but also just how tiny many of those deps are.
Not different from someone befriending a corporate employee and asking them to insert some malicious code into the codebase. You still rely on a web of trust - in the company's case, the code reviewers, in the open source example, the maintainers of the libraries that use left-pad. I don't think this argument really holds, I don't know what you're comparing it against that's different.
Even the smallest transitive dependency in our largest dependency graph in the Java ecosystem isn't someone's 6-liner afternoon project.
I think the ease of publishing + ecosystem of small modules is a good thing, it just has what we consider an ecosystem-level security trade-off that matters for some applications.
(Dependency bloat can be a real thing, sure. But if I have to choose between adding a dependency on a solid, well-built module and spending the time to reinvent the same complex wheel all by myself, I'm going to pick the option that gets me more quickly to done, 100% of the time. I'm paid to bring business value, and while minimizing technical debt where it counts is a big part of that, spending unbounded time to satisfy my own peculiar notion of software perfectibility is most emphatically not.)
I personally ran out of reasons to prefer another dynamically-typed language over Javascript on the server. In fact, with ESLint, I'd say Javascript has some of the best static tooling among them before you even get to Typescript.
With async-everything, promises, and async/await, I think Javascript is one of the nicest dynamically-typed languages.
I don't like node.js, but I occasionally use Typescript like a more powerful C#.
C#'s type system is usually better except from the times that I feel creative. Works perfectly for large codebases with many changes. Not fun for side-projects.
Sadly, I'll probably never have a stretch of time to re-learn the C necessary to build one.
I also miss being able to eval code in my buffer while writing Clojure against the same process my server is running in.
Server-side Javascript has the perk of being able to use Chrome's debugger UI. I personally haven't used it much though.
It's interesting how much your core feedback loop / workflow can change between ecosystems. Pry is definitely a highlight of the Ruby ecosystem. The craftsmanship there alone is inspiring.
1) It requires another window to be open, which requires screen real estate. I don't always have an external monitor attached.
2) Navigating around requires clicking buttons with a mouse. These buttons are quite small, so Fitts' law dictates that it takes longer to navigate. It is much faster to be able type "next", "c", or "up 3" in the same text box that the output appears than to have to keep moving the mouse back and forth between buttons and the console.
3) Because of point #1, it is harder to get as much space for the output of running some javascript.
4) It takes longer to make the connection happen and (at least in the past) has been unreliable. This is a significant annoyance if starting and closing a debugger window frequently, as one might do if trying to navigate to a breakpoint in a particular test case.
Larger teams have different requirements.
Following a GET request through a web server usually just involves some middleware, a dozen lines of route handler, a dozen lines of database queries or service calls, maybe an html template, and you're done.
- There is exactly one way to define a module. Write a file. Done. Webpack takes care of it.
- You were using Webpack, right?
- The fact that Webpack either wasn't on your radar or already solving your problems says a lot.
Look, I know this sounds like bullshit, and in fact it's very difficult to distinguish this from actual bullshit. But there are a huge number of people here -- old fogies, stuck in the past, yearning for the old days that are never coming back -- who hate JS, and that hatred manifests itself in ten thousand subtle ways.
Inventing the idea out of thin air that "there are 7 different ways to define a module" is simply false. It does not resemble reality. Yes, it's true you can point at all the dead module systems that came and went, but nobody bothers even thinking about those systems because they're dead. They're zombies. Yeah maybe some people use them, but realistically if you're getting shit done in JS that means you have webpack and all of these concerns are not actually concerns.
JS stdlib seems like nonsense? Lodash.
Feels like you're importing too much bloat? Webpack tree shaking takes care of that. Closure compiler eliminates all the code you're not using. There's no reason not to use a first-class stdlib, whether it's Lodash or whatever else you prefer.
- The JavaScript community seems to have the opposite of NIH syndrome, so that even basic functionality is offloaded to a third-party modules (see leftpad). The project I'm working on has over 1000 modules in it's dependency tree.
This is the power of JS. It's the thing to force yourself to embrace. You need to join the cult of bullshit and just mentally force yourself to love this rather than hate it. It's why JS won. You can hate it all you want and revel in the insanity, but there is zero reason to do that other than as a way of making yourself feel good. Which is just another way of saying we're all acting very selfish when we lash out at JS like this.
Yes, you're correct. Every one of your points is absolutely true. Yet it's all so very wrong. I wish I could put it into words better than this.
Look dude. I've been around the block. I vividly remember what this shit was like in 2008. You want pain? Holy shit, I remember trying to make a little arrow rotate on my webapp. I wanted finder-style arrow rotations. You know how on a tree view, each folder has a little arrow, and it points to the right when it's collapsed? Click on it, it rotates 90 degrees and points down, and the tree expands. YEah, I tried to do that in 2007 right when Rails 1 was first coming out. Talk about horror. The solution -- the only solution -- was to make an entire animation frame by frame, of the arrow rotating 90 degrees. Like 16 different images, just for this stupid arrow to rotate 90 degrees on command. Because CSS literally wasn't a thing back then. Yeah we had "CSS", but for all intents and purposes we are living in the future right now. We have tools that 2007-me could only dream of.
JS works now. That is not the expected behavior. It's difficult to convey how fucking strange this is. Anyone who lived through that 2006-era transition knows what I mean.
Right now you can drop Semantic UI into your project, hook up React to it, and have first class testing (Enzyme) and state management (Redux).
Don't like all that bullshit? No problem. Use Vue. It sidesteps all the Redux insanity. And the tooling is catching up.
But the way you know these things is by being a JS dev. Living and breathing it every day. There's no way around that. You either throw yourself wholeheartedly into the pool or keep one toe in while complaining about how big the ocean is.
This rant came out quite a lot harsher than I intended; it's just a reaction to the very common trope that HN throws around of "JS is shit, the web is shit, this is shit." Yes, this is true. And yet -- simultaneously -- no. No no no. We can do magical things now. Hooking up Vue with hot reloading is literally magic. If 2007-era me had these tools, I would have launched a startup that could dominate everyone else solely due to the advanced tooling that we now enjoy. Our tooling now vs 2007 is like Lisp vs C++ back in 1999.
No, JS won because the web won. There's a web browser on almost every computer out there. If you write your software in JS, you can run it just by following a link to a URL. That doesn't have anything to do with JavaScript's absurd module ecosystem.
JS has un unfair monopoly.
Just give us a decent language on FF, Chrome et Edge, and everybody will stop using JS withing 5 years.
I do think however the current trend is OCaml / Haskell influenced languages like Elm, Purescript, Reason, etc. WASM is only going to make them better.
The king is dead, long live the king!
But even without that, then chances that you have exactly the same build than somebody else in cache is very weak unless it's very popular. And to get it popular means a lot of people has to download it, taking the several Mo hit download on first load. And most users will just quit the page before that, thinking it doesn't work.
The solution would be for browsers to stop the madness and decide by community to adopt a new standard with a decent language for the web. Be it Ruby, Lua, Python, at this point I don't care. I'm partial to Python, but I won't fight for it if it means I can get anything with a real stdlib, good builtins, namespaces and a readable syntax.
The same thing happens now with regular browser caching, it's not that big of a deal. People will design run-times targeting webassembly to be lightweight, but if they end up being too heavy, developers will use CDNs the same way they do now with other large front-end dependencies.
> The solution would be for browsers to stop the madness and decide by community to adopt a new standard with a decent language for the web
A subjective and impossible consensus to achieve. The community will never be able to agree, that much is obvious. The answer isn't "pick a language that works today and hope for the best", that is how we got where we are today, rather, we need a solution that gives the community the power to experiment with better solutions that aren't constrained to a single language.
Let's put it this way. Think of your favorite language. Favorite paradigm, whatever. All the shit you hate about JS, picture the exact opposite of that. Now imagine that the web was entirely built around that.
Surprise: now everyone would hate exactly whatever you love. It would've grown all that hair and all those warts you currently despise about JS. It's what the world does.
So when people knock on JS, it's getting much harder to take this stuff seriously. I've been a dev for over a decade and have been down a dozen rabbit holes, from C++ template metaprogramming to .NET nonsense to elisp verbosity to hardcore functional + immutable paradigms. Loved all of them, each in their own way. What we have now with JS is simply incredible from a raw "get shit done" perspective.
It includes special cases for dates, takes O(n log n) time in the number of keys, and has suspicious comments like, "I've managed to break Object.keys through screwy arguments passing. Converting to array solves the problem." There are 15 open issues and 15 open pull requests. A sane language would have this operation built-in.
A better example would be the extremely poor Date object, which has only a couple format functions and can't even be created from a specified format. There's also a bunch of holes when manipulating data, filled by libraries like lodash(although the standard lib has improved significantly in this regard).
>>> {"foo": [1, 2, set([True])]} == {"foo": [1, 2, set([False])]}
False
>>> {"foo": [1, 2, set([True])]} == {"foo": [int('1'), 2, set([bool(1)])]}
True
There are better examples of deficiencies in Javascript's standard library, especially when targeting browsers, but Javascript has made massive strides lately like its native Set and Map datastructures.
For example, Set doesn't come with the classic methods `.intersection()` / `.difference()` / `.union()` / etc. but it's just not a defining moment of my overall experience with Javascript.
We're long past the days where you had to bring your own `Array#map`, but I don't know if all of these commenters are.
irb(main):002:0> {'foo' => [1, 2, [true].to_set]} == {'foo'
=> [1, 2, [false].to_set]}
=> false
irb(main):003:0> {'foo' => [1, 2, [true].to_set]} == {'foo'
=> ['1'.to_i, 2, [true].to_set]}
=> trueOff the top of my head, Haskell has "deriving Eq", and Scheme has "equal?". I'm pretty sure Python uses deep equality for tuples as well. Anyway, it's just one example of something I wanted to do in JS recently and ended up disappointed in the quality of the code I saw to do it.
Sure, you can perhaps override some methods on an object, but given two arbitrary objects (like two dicts in Python), knowing if two are 'equal' is not easy and certainly not built in.
That being said, JS doesn't make implementing this easy or simple at all.
irb(main):001:0> require 'set'
=> true
irb(main):002:0> {'foo' => [1, 2, [true].to_set]} == {'foo'
=> [1, 2, [false].to_set]}
=> false
irb(main):003:0> {'foo' => [1, 2, [true].to_set]} == {'foo'
=> ['1'.to_i, 2, [true].to_set]}
=> trueSee my other comment.
Pick a project. Think of a website you want to make. At no point during that are you going to be stonewalled by "Man, if only I wasn't forced to spend the last 4 hours debugging this weird deep equality issue. I could've gotten so much more done!"
You can take that information and use it however you want. It's the truth. It's up to you to either reject the notion or integrate it into your mindset and abandon the tendency to cling to idealisms. Ivory tower development simply does not happen in reality, and I say this as someone who spent a couple years trying to build an ivory tower Lisp.
I know it's not coming across at all, but I really identify with your mindset and acutely feel your pain. This was a major mental hurdle that I had to force myself to overcome. I'm saying, it's possible, and the only thing you have to do is to choose to do it.
Let go. Realize that it doesn't matter. It's worth the benefits. You can do so much more.
I was afraid that "letting go" would translate into "now I'm part of the problem too." But it turns out the opposite is true. It's very powerful that you have a background that most JS devs lack. Because they often rabbithole themselves into complexity, and you can come along and do something simple that no one else thought to stop and do.
But you can do all of that while still embracing the wider ecosystem. It's not an either-or. You can help bring sanity to what would otherwise be a ball of hair. But the way to be in that position is to jump in and churn churn churn until you've used Vue and React+Redux and understand the concepts and tradeoffs.
I have faced this on the job. About three abstraction layers deep in a Backbone app. It took me two days to trace the exact cause and find a way to implement a better check, that wouldn't make things respond in unexpected ways.
> It's up to you to either reject the notion or integrate it into your mindset and abandon the tendency to cling to idealisms.
JavaScript is terrible. It is not the product of academic research like Smalltalk or Haskell. I can accept it is the only tool available for the job, and continually look at all the solutions for that particular issue, and I will keep doing that.
I can use JavaScript, and I can write it. Usually my code is simpler and faster, because it takes me much longer to write anything, because of how aware I am of the side-effects. My employers in the past have liked the results that has produced.
But I will never enjoy writing it.
It is a language that is difficult in ways that reveal it's sloppy roots, and spill it's implementation details. Much of the time JS feels like working with UB in C, except it is actually detailed to act that strangely, in the spec.
Just an example that has always stuck with me, this is valid JS:
[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()
It's a tool. It's sharp on both sides, which can lead to a lot of blood-letting if you aren't careful. But it is still the best carving tool we have on hand.
Any Turing tar-pit can do incredible things. And when it has a monopoly on its own niche, of course incredible things happen.
I remember what shit was like in 1998, which is why I get the same sort of aggressive reflex anytime someone is criticising Rails.
Back then, a web project could, and this is only slightly hyperbolic, include a file ```/project/htdocs/version-2.0-old/real/includes/templates/config.passwords.production.INC.php3~```
...and that file would start with ```<table>``` and, somewhere, include the SQL to delete a user.
That was the state of our industry when Rails was released. Which is why anybody who went through that transition weeps whenever people today regurgitate this bullshit about "magic" and "OOP considered harmful". Maybe functional programming is incrementally better. Maybe Rails is past its prime. But on a purely emotional basis, I feel defensive when some article doesn't start with a paragraph praising the genius of DHH before offering its criticism.
Yes, the state of the web in 1998 was as you describe, but by 2005-2006 there was an explosion of MVC web frameworks in many different languages, of which Rails was just one.
However, Rails is what really launched the "MVC renaissance." Because of it, soon Java, C# and many other languages moved to predominantly MVC cultures.
There's a Rails way, Python famously aims for one obvious way of doing things. That just isn't true of Javascript exactly because there is a history of developers writing several styles of JS, the "right way" to write JS being redefined by diligent people like Douglas Crockford & John Resig and things changing yet again and yet again.
And look at ES6, the JS ecosystem barely resembles what was considered good, idiomatic Javascript just a few years ago. There are a bunch of devs who have managed to stay on top of what's current and I'm sure are laying down examples of good practices & building tools in that style. But you are also talking about an ecosystem that includes people that started writing JS 4-10 years ago, have adopted some of the absolute newest flavor of the month practices but also have seen JS change so much over the years that they aren't throwing themselves into everything that is now considered a best practice because they know their code works and there could be another seismic change in 8 months.
Writing Javascript nearly every line of code is haunted with "is this still the way I should do this?" and no other language has that much hassle.
Again, this is a symptom of the "one toe in the pool" syndrome. You have to throw yourself in.
Yarn is a perfect example. It came out very recently, relatively speaking. And yet it's clearly the future. Like, the only reason not to use yarn is if you have a legacy app that explodes for some reason if you try to type "yarn" instead of "npm install". But the common case is that you do "git clone foo && cd foo && yarn" and everything works perfectly.
It's so much faster, and almost never causes problems.
So why embrace that? It sounds like horseshit yeah? I hate to use heavy handed metaphors like that, but that's exactly the feeling that you get when you hear "Oh, now we're supposed to use yarn? what? npm install isn't good enough now? Those fucking JS idiots have no idea what they're doing."
In reality, you're seeing evolution in action. This is what natural selection looks like. The good ideas triumph. And yes, it's subjective what constitutes a "good idea." But when yarn comes along and makes all my npm installs 3x faster, you bet I notice and you bet I embrace it right away.
That's what I mean about throwing yourself in, though. If you don't actually force yourself to love this stuff, then of course you end up hating it. It's insanity incarnate. Yet if you just embrace that fact, and take it as a given, you can actually find it quite fun. It's an adventure to get to learn these new systems, not a chore. If you run across something that doesn't seem to make sense or doesn't work for you, just ignore it.
It just seems like we as developers run the risk of having our heads stuck so far up our own rears regarding our favorite language paradigms or the lack of greenthreads in JS or whatever it is you hate about the ecosystem, that it's very easy to lose sight of the bigger picture. Right now you can build a team of 50 engineers, and if you choose React, that codebase probably won't devolve into utter chaos. React makes it possible to do large-scale coordination. Like, I can send you my React component and it'll probably work in your codebase.
Ditto for Vue. If you hate the complexity of React, and you're a small team (usually just you alone), then you can just use Vue and not have to care at all about React+Redux's monstrous complexity.
You see? You can pivot however you like. If you hate X then just avoid X1 It's really hard to take these concerns seriously when there are so many options.
Ah, yes, that's the crux of it. We'd love it if the world would just stop changing so we can relax and stop learning. Well, too bad! Here's the uncomfortable truth: the moment you let yourself get too comfortable, your career dries up. That fear is a powerful motivator, so I suggest internalizing it. If you can't force yourself to love learning, then become afraid that if you don't learn it you'll find yourself unemployable after 5 years.
This almost happened to me, so I'm speaking from direct experience. I came from gamedev, and low level skills like that really do not translate into "I'm getting paid $INSANE/yr in a hot new startup." In fact, you can barely pass webdev interviews because you have to go "Uhh... Yeah, I worked on Rails back in 2007 or so. I guess I have some learning to do. But just trust me, I can learn it as I go. Oh wait, you don't believe me? But... I've spent my whole life learning as I go... It's fine if I don't already know Rails even though you're hiring for a senior rails dev position."
That situation is exactly what happens when you stop being on top of all this stuff. Go to sleep and wake up 5 years later and suddenly getting a job is hard. It's easy to smirk ad feel like it won't happen to you, but FWIW the way you feel about JS now is exactly how I felt about Rails in 2007.
And there you are a few comments above telling us we have to use Webpack because other older module systems are zombies that came and went.
The truth is that we'll never have enough time learn everything we should learn and every minute I spend re-learning a different way to do something I already know how to do is a minute I'm not spending learning something actually new and useful.
If, for example, I'm writing a web app related to storing and processing geology related measurements (which I am) I should be spending most of my 'learning time' studying things related to geology and the processing of said measurements, not re-learning how web development is done this week.
Something about this smells.
What is it.
Is it the way "we would love it if it stopped changing" but it's us who is changing it?
Is it that the changes are reinventing the wheel? Churn because frothy churn is easier and more profitable than meticulous, solid, long-lasting foundations?
Or is it that we still haven't managed to orient the programming industry around 'finished' software such that if we ever 'finish' software we immediately stop being employed, so we have a pathological need for software to continually need to be rewritten, at the level the average programmer can rewrite?
How is this client side rewrite every few months fundamentally different from the broken window fallacy? as in, unsustainable because it adds no value overall?
Node threw themselves into Semver, and it was supposed to be great. Nobody needs a lockfile because everyone obeys semver, so every time you do 'npm install' your app is guaranteed to work because everything is semver'd!
Oh wait, no, that didn't work out. Better freeze every dependency and sub dependency because who knows what will break when we update!
This is why throwing yourself at whatever shiny new thing without thinking or looking at how other languages do it is not always a great idea.
Last I checked its issue tracker was a pile of "hey, you, uh, didn't implement this npm feature at all, so things break" and "you're missing yet another obvious sanity check here, so things break". No wonder it's faster. The last thing I need in my JS stack is another thing that can fail under ordinary use, for marginal benefit.
You do you, though.
So the JS ecosystem is a giant pool right? Everyone is swimming in all possible directions with all sorts of contraptions like rubber tires, inflatable dinghies, pieces of wood, plastic garden flamingos, etc. A lot of the swimmers naturally pee in the pool because it's more convenient than exiting (that was frowned upon at the beginning, but people kinda got used to it - and it keeps a steady development speed!).
This might look quite horrifying to those on the outside, but for the swimmers it's nice and warm, while stepping outside is cold and scary, because they would have to learn all sorts of complicated and frightening technologies.
For someone like me that got out when the pool was small around 2006, there is no incentive to jump back in. I mean yes, if I closed my eyes and jumped I would probably adjust after a while. But why jump in the JS pool when I can swim in the open sea? :)
And you think you have any idea what you're talking about when you talk about modern JS just came outdevelopment?
You know when AJAX first became possible? 2005. ES3, the latest version of JavaScript available at the time, was released all the way back in 1999, the next version (ES5) wouldn't come out until 2009. Strict mode didn't exist.
MSIE had an 80%+ market share, Firefox was hovering around 12%. 2006 was the year IE7 came out. Building a website meant you were targeting IE6 if you were lucky but had to worry about compatibility with IE5 (and also the completely different but identically named MacOS version of IE5) -- but in practice IE4 and Netscape 4 were still a concern.
You know the song "IE is being mean to me"[0]? That was first published in 2009.
Your comment is the equivalent of showing pride about "getting out of" automobiles in 1903, when Ford started working on the first mass-produced car.
JavaScript was used mostly for decorative purposes and AJAX where it improved experience.
As far as benefits to the users are concerned, why is today's web better? It's just a souped up Model T with bilboards on all sides, a 360 degree camera on top and more cameras on the inside.
But I get why it's awesome for front-end developers, they get to rewrite everything in the framework of the day every couple of years and they are handsomely paid. They get to invent new contraptions to keep up in the eternal race with native apps.
It does get a little annoying when someone points out that the emperor is naked, but otherwise life is good.
There's nostalgia and then there's outright denial. The reason you think the web was glorious in 2006 is that you forgot everything that was shit about it.
Want to know what made those shitty parts go away?
Modern JavaScript.
Absolutely there's a class of applications that wouldn't be possible with this approach, and I'm glad they exist. But it seems the "correct" answer to any problem to be solved on the web, no matter how straightforward, is to reach for React or a similar framework.
Flash was not shitty, it was quite good for writing apps, but it was proprietary and like a lot of contemporary tech it was (becoming) a security liability.
You're giving waaay too much credit to JS. Apple almost single-handedly buried Flash.
It used to be possible to escape; now it no longer is.
> Want to know what made those shitty parts go away?
> Modern JavaScript.
Modern JavaScript didn't make the shitty parts go away; modern JavaScript made the shitty parts universal.
It does more. Significantly more than "back in the day".
JS is nicer because it's a standard and it's supported everywhere.
"Besides this major technical difference, there is basically no major technical difference" :)
I think that's actually worrying. While I'm not in the 'JS sucks; avoid at all cost' camp, I do find it a bit worrying that as I'm getting better as a developer, and as I'm getting more experience with non-JS ecosystems, I find myself avoiding it whenever possible. Even to the point of going for old-fashioned server-side apps just so I can use saner language ecosystem <x>.
I'm sure the loss of me will not affect the JS ecosystem much. But I'd be surprised if the same is not the case for many other, better developers. TJ Holowaychuck left for Go? Jose Valim moved on from Rails to Elixir (even to the point of creating it to solve problems he encountered with Rails).
I'm confident JS is important enough to keep a hold on many good devs, but I do hope we keep improving the ecosystem so that the really good developers stay on board to help improving it.
I was right there with you.
If you can find a way to retain your career and not have to worry, maybe it's not worth it.
But for me, I came precipitously close to having no marketable dev skills, by accident. I loved gamedev, and I spent my life learning it. It's what got me into programming.
Most cities don't have gamedev shops. And if you're not at a gamedev shop, you're not really a gamedev. Yeah you can try your hand at indie stuff, but that's roulette. Wanna be forced to move to whichever city has a studio? Be a gamedev.
So... Backing out of that career trajectory led to an uncomfortable realization: I'd amassed a bunch of low-level skills, had a deep understanding of Unix/C, and could implement https://lmax-exchange.github.io/disruptor/ without breaking a sweat. (Not merely use it; implement it.)
None of that translates into dollars. If you show up to a recruiter, they don't know what to do with you. There are literally hundreds of Rails gigs.
One interview went like this: They sat me down, opened up postgres, and said "Accomplish these goals." The goals were simple things like write SQL statements to query for certain types of users, or join data together.
I never had any reason to learn any of that. I knew that I could learn it if I needed to. I understood conceptually what joins are, why to use them, and what to avoid and why. The "why" is the crucial ingredient, and I naively thought that would protect me.
No... It's not fun when you have to sheepishly admit in front of three engineers that you have no idea how to write those SQL queries.
It was the same deal with Rails. Ditto for JS. Eventually I went through 5 interviews and struck out on all 5, in a row.
That's deep shit. When you start worrying about paying the rent, you're not in a happy position.
The way out of this mess, and not to end up in it, is to own it. Embrace all the shit. Become Elvis of code. Literally throw in the kitchen sink just because you haven't tried it out yet and this new kitchen sink might help you.
This story might not seem too relatable, and you might feel like your career is impervious. But a wise person once said that we overestimate the impact of years, and underestimate the impact of decades. "One decade" is so powerful that it's hard to overstate how much the world changes during that time frame. Are you absolutely certain you can get by without swimming in that pool that gives you the heebie jeebies?
Let go. Once you start swimming a few laps, it's not so bad. And in my case, I discovered I kinda like it. You're not supposed to like it, but it really is kinda fun. What other career would get to play with an endless box of legos?
I mean I think I understand why you chose JS, but we each make decisions that can take us on different paths.
I also do systems programming and have been doing C++ for most of my career. Instead of choosing JS I chose to invest in mobile and developed for iOS, Android and Nokia. Then I got back to system programming and will probably transition to software architecture.
I'm currently very interested in safety, security and reliability, which is basically the opposite of JS development culture. It seems to me that it's a big world development world out there.
But there are indeed still several module systems in use:
* globals (i.e. none)
* CommonJS
* AMD (just kidding, nobody uses this for new code)
* UMD (which mixes AMD, CommonJS and globals)
* SystemJS
* ES modules (via Webpack, browserify, whatever)
* ES modules in the browser (which behaves slightly differently)
That's 7 so I'll stop there. Yes, it's cheating a bit but of those I'd say AMD and UMD are the only ones that are dead as a doornail (for new code anyway -- plenty of libraries still use UMD for nostalgia). You'll only end up using one of them (or maybe two if you mix ES imports and CommonJS requires for some reason) but which one depends on which part of the ecosystem you end up with.
It seems that most of the community has adopted Webpack as the one true bundler for apps. Rollup is generally seen as better for libraries though.
Angular I think still promotes SystemJS, React is half-way between CommonJS and ES modules (via Webpack/Babel). I have no idea what Ember is doing.
If you want to add type safety, Angular strongly favors TypeScript while React is slanted towards Flow for obvious reasons.
The JS ecosystem is complex. Even if you cut out all the nostalgic stacks (MVC with Backbone and jQuery is still cool, right kids?) there are still many paths to pick from.
But I agree with your final conclusion: the reason the JS ecosystem is so complex is that it has changed a lot over the years and has seen massive improvement while still maintaining backwards compatibility at a language level with tons of legacy code that's still out there and still running in production.
Lulz, our Oracle-owned ERP system chose AMD for its module system less than two years ago. All new code will use AMD here for, I expect, the next decade.
I agree 100%. If you're not infected you don't get it. Just like a healthy person may not understand the babbling of a delirious patient.
>I've been around the block. I vividly remember what this shit was like in 2008.
All the way back to 2008? Quite the block.
>JS works now.
JS doesn't 'work'. The language is still a mess. But the platform is beautiful. The runtime and compiler and the JIT are great. In the same way that NAT gave a ipv4 a lease on life, transpilation is what makes JS development tolerable.
When built-ins remain missing from the language, HN complains about JS being useless and "inverse NIH".
> All the way back to 2008? Quite the block.
I've used JavaScript in the 90s. Compared to today, 2008 was firmly in the stone ages.
No. Just no. There is a difference between 'bloat' and a sane syntax.
>I've used JavaScript in the 90s. Compared to today, 2008 was firmly in the stone ages.
I agree. It's not saying much but I agree. In the 90s JavaScript was useless.
And why I pretty much ignored JavaScript for the first 8-10 years of my career, now with much regret. I'm catching up though.
The benefit of hindsight...
Before I get into the details, as a general comment I find that while you're not wrong, I've found that I need much less 'diving into a pool' when I enter other language ecosystems. I understand why this is the case with JS, and personally I have a soft spot for the language, but even if it's not JS 'fault', I find that it is not a good thing that it takes such a 'deep dive'. They're valid concerns.
> - There is exactly one way to define a module. Write a file. Done. Webpack takes care of it.
it's a lot better now, but this has not been true even until recently. I've probably lost weeks of time over the years figuring out how to load module <x> using import statements where require() worked instantly, and from what I understand it can be a serious headache for module developers to support both 'ESNext' imports and CommonJS requires.
I can't tell how often I still need to search whether it is import x from 'x', import {x} from 'x', or import * as x from 'x', or in some cases the only thing that works is require(x).
> - The fact that Webpack either wasn't on your radar or already solving your problems says a lot.
Not really. I've used Webpack since the early days, and I've tried switching to Rollup, Brunch, and Gulp because Webpack just didn't make any sense to me. Then came Webpack 2 and half the tutorials and documentation stopped working.
FWIW I generally go for Webpack 2 these days, and it's an improvement. But it's a solution that causes quite a bunch of problems of its own. Plus, it's a solution that isn't even needed in anything but front-end JS. For good reasons, and I don't think JS is the cause of the problem (rather, it's bandwidth and general front-end concerns). Nonetheless, it's not even remotely simple.
> JS stdlib seems like nonsense? Lodash.
Why yes. I love lodash. But it's a huge library that I'd rather not load in its entirety if I'm not using most of it. Have you actually tried loading parts of lodash using import statements? Last I checked, a few months ago at most, this was not possible. I had to do require('lodash/blah'). That's not obvious until you've figured it out.
> Feels like you're importing too much bloat? Webpack tree shaking takes care of that. Closure compiler eliminates all the code you're not using. There's no reason not to use a first-class stdlib, whether it's Lodash or whatever else you prefer.
Webpack tree shaking is relatively new. Much of the online help (tutorials, etc.) still refers to Webpack 1.
> - The JavaScript community seems to have the opposite of NIH syndrome, so that even basic functionality is offloaded to a third-party modules (see leftpad). The project I'm working on has over 1000 modules in it's dependency tree.
> This is the power of JS. It's the thing to force yourself to embrace. You need to join the cult of bullshit and just mentally force yourself to love this rather than hate it.
I don't see how defending JS by telling someone to embrace the suck is any kind of valid argument in favor of the JS ecosystem. Could you elaborate?
> It's why JS won. You can hate it all you want and revel in the insanity, but there is zero reason to do that other than as a way of making yourself feel good. Which is just another way of saying we're all acting very selfish when we lash out at JS like this.
First of, JS won despite its quirks and the insane ecosystem. And second, selfish in relation to who? Brendan Eich? I think complaining about the things that do suck about JS and its ecosystem are important toward improving things. As a fan of JS, I don't feel offended when people say it sucks. It sucks, and while I think that's not primarily the language's fault, I also don't get my self-worth from being (predominantly) a JS programmer.
> Yes, you're correct. Every one of your points is absolutely true. Yet it's all so very wrong. I wish I could put it into words better than this.
Without meaning to be snarky, I'd love for you to elaborate. In the grand scheme of things I'm not a great programmer, and I got started with JS, so it's quite possible that I'm overestimating how much better the non-JS ecosystems are.
> Look dude. I've been around the block. [rant that I fully agree with]
> JS works now. That is not the expected behavior. It's difficult to convey how fucking strange this is. Anyone who lived through that 2006-era transition knows what I mean.
> But the way you know these things is by being a JS dev. Living and breathing it every day. There's no way around that. You either throw yourself wholeheartedly into the pool or keep one toe in while complaining about how big the ocean is.
> This rant came out quite a lot harsher than I intended; it's just a reaction to the very common trope that HN throws around of "JS is shit, the web is shit, this is shit." Yes, this is true. And yet -- simultaneously -- no. No no no. We can do magical things now. Hooking up Vue with hot reloading is literally magic. If 2007-era me had these tools, I would have launched a startup that could dominate everyone else solely due to the advanced tooling that we now enjoy. Our tooling now vs 2007 is like Lisp vs C++ back in 1999.
This I do agree with. I'm incredibly happy that front-end development has made massive steps in being saner than it used to be. And it does often frustrate me to read low-effort criticisms that don't really add to the conversation.
But in the past year I've ventured further and further out of my JS world, and I'm starting to understand why so many people are so negative about JS. If I were an experienced dev with little JS experience, the ecosystem would strike me as insane, to the point of just giving up and doing everything with 'server-side' languages. And honestly in the past few months I've been wondering if perhaps I've underestimated how much the JS ecosystem sucks. How much perhaps I've been Stockholm Syndrome'd into thinking this is normal in any way.
All that said, the constant criticism is grating. It doesn't solve anything, and it often carries a whiff of 'if only sane people were working in this area things would be different'. Which is utter bullshit. The JS ecosystem sucks, but it's the best we have, it's not because 'JS devs r dum', and in the end it often offers enough advantages to be worth the trouble. But that doesn't mean it isn't insane. It's batshit insane even now, but for the first time in years it's at least less frustratingly insane. We're moving in a good direction.
EDIT: let me add that I do agree that comparing JS to Ruby/Rails is not perhaps the best way to argue that JS isn't good. I'v encountered plenty of batshit in the Ruby ecosystem.
Regarding "embrace the suck," the best I can say while being brief is...
Ah man, this is such an interesting topic, and it's worthy of a blog post in its own right. You have to trust me when I say "there's something here; it's worth tugging at this thread to find out whether it might be true."
It is counterintuitive. But the fact that it's counterintuitive is a hint that it might be worth checking whether it might be true. Relativity was counterintuitive too.
If you embrace the suck, you can pull the simplicity out of the chaos. But only after you've mastered the chaos.
That sounds like some combination of naive or impractical. Who could possibly master chaos?
You can. And that's all I'm saying. Step one is to force yourself to choose to try.
I do think it's a great situation where one single programming language allows one to not only create complete applications that run on every computer under the sun (without installing Java), but allow you to fucking debug it in a pleasant way on pretty much each of those computers.
But all that said, I wish I hadn't started out with JS and blindly followed the 'chaos'. I've wasted so much time using React and Redux when simply React, or in some cases even good old Backbone of jQuery would have sufficed. I wish I'd learned good programming practices from more overtly functional or perhaps more overtly OO languages, before learning JS. I wish I hadn't spent many hours dealing with Grunt, no, Gulp, no Webpack, no Webpack 2, only to become a 'master' at something that is entirely irrelevant outside the JS ecosystem.
Sure, I learned the intricacies of the 'chaos' and I find myself going more and more for simpler solutions within the ecosystem. I'm comfortable using Baobab.js or MobX instead of Redux. I'm comfortable using only lodash instead of a whole bunch of modules that do part of what lodash does.
But I don't feel any of that made me better as a programming. In fact, as the JS ecosystem is improving, I find that a lot of my arcane knowledge of how to, say, enable hot code reloading in Webpack 1 is entirely useless now that Webpack 2 sort of does it out of the box.
More and more I'm inclined to let the JS ecosystem do its crazy shit and wait for something semi-standard to shake out before I even bother. Because everything I learn about the specifics of this chaos will not be worth knowing in <x> months.
You're right, in a particular way that I hadn't thought of:
Most people don't have a background in programming. They weren't doing it when they were teens, and many people probably started writing code within the last year or so.
In that context, I completely agree. It's absolutely true that at the end of all that chaos, you won't end up a better programmer.
I was speaking as someone who was in the inverse situation: I'd amassed a lot of theoretical knowledge, and spent a lot of time chasing the phantom of "being a good programmer." I researched memory models, read whitepapers, explored how Google implemented bigtable, went through rtm's 6.824 Distributed Systems course just for fun (it's freely available online)... You know, a bunch of hardcore stuff that it seems like "real programmers ought to know."
Yeah... Turns out that doesn't always translate into dollars. It came really close to being a bad situation (explained here https://news.ycombinator.com/item?id=15642428).
Let's put it this way. If I had to do it all over again, it's very possible I would swap skillsets with you. Because you know all of the stuff you rattled off. You are now prepared to avoid it. So yes, it's easy to feel like you've wasted your time. But when it comes to employability, you are far better positioned from a career standpoint.
Stuff like this may feel "out of bounds" of traditional conversation. Normally we're supposed to make up arguments that support our points purely through reason alone, right? Like it would be much more persuasive for me to say "Well, this matters because X" where X is something related to programming. Talking about career stuff and employability may seem like punting. It might also seem like it's something you don't really need to worry too much about.
But when you relax and let yourself stop learning, and stop going through the motions of all that stuff you hated, it's merely 3-5 years before you end up in a similar position. Maybe. Or maybe you'll get lucky.
But that doesn't make it less shit. I'm actively re-schooling myself as a more backend-ish, or perhaps full-stack-ish developer that allows me to use more of Elixir, Clojure, or even Ruby/Python, and less of JavaScript.
I'd say there are basically three perspectives on this:
1. development ease/quality, where JavaScript is not the worst, but far from the best. 2. ecosystem health and best practices, where I find that JS is not doing a great job. A lot of churn, a lot of reinventing the wheel, and a lot of stockholm syndrome defending the mess. 3. money, where being a good front-ender is worth most of the effort and frustration.
I'd say 3 is the most contentious. Most people seem to agree on 1 that JS and its ecosystem are not a paragon of good development. It takes work to even just get a good initial setup, which is not a problem in many other ecosystems. Transpiling, to name one example, is just not necessary. I think a sizable portion of multi-lingual devs would agree on 2 as well.
But 3 is difficult to quantify. Is it a good thing that I can me a good chunk of money building React/Redux apps when I could've built a saner, more stable version in Django/Rails/Elixir in a fraction of the time if the only downside is that it requires a full page reload? I'm not so sure anymore. But it's worth a discussion.
Point 1 and 2 strike me as obvious enough that bringing them up ad nauseum on HN is just pointless and frustrating.
I find myself often frustrated at criticism of JS that really is a criticism of the need to know the ins and outs of the ecosystem as a whole to be productive.
It's frustrating because blaming, well, anyone for that situation just seems a bit utopian and unrealistic. It implies that JS devs are not aware of the problems, when in my experience most non-fanatical ones are aware, but pragmatic.
I'm at least old enough to have been working within various ecosystems where arcane knowledge was pretty much a prerequisite to being productive in said ecosystem. One of the most common frustrations I had was people criticizing this need for arcane knowledge, where my thoughts were "sure, but that doesn't change the reality of day-to-day programming in ecosystem X, and the advantages of doing so perhaps maybe offset the shittiness".
I've experienced this with obscure Delphi-related issues concerning the app's 'chrome' (title/task bar coloring). I've experienced this doing PHP development and being told I'm a shitty dev for even touching PHP. I've experienced this with jQuery, being told that I should use Backbone (which FWIW was a good choice moving forward, but it never really solved my fundamental issues in my previous jQuery work. If anything functional approaches did).
There's a point where it just gets exhausting to hear people bring up the same tired old argument, again and again, for karma or whatnot, against a particular ecosystem, when the arguments are theoretically sound, but where they disregard the pragmatism of 'participating' in said ecosystem.
It's really not that different from a libertarian getting uppity about capitalism when you're busy volunteering for some non-profit civil society-related endeavor to improve things. It's not technically wrong, but it's a hell of a lot more pointless than pragmatically working within said system (and yet, confusingly, still worth pointing out).
And of course then there's a bunch of people who build something that vastly improves a possibly shitty ecosystem, using lessons they probably learned from other ecosystems. I'd say Redux as well as React are great examples of that. I'd love to go into how these are fundamentally very much about functional programming principles, and how I think all these tired discussions about languages hide the more important discussions, but that's unfortunately probably seen as tangential to this discussion.
- Thanks to the proliferation of Rails and similar frameworks, most Ruby apps at least have something that resembles an MVC structure. With JavaScript, once you move past the basic TodoMVC examples you are pretty much on your own. It gives you enough rope to hang yourself, all you colleagues, and everyone in the building next door.
- The expect vs should change in RSpec is nothing compared to how fast things are changing in JavaScript. I think there are now 7 different ways of just defining a module.
- The stdlib of Ruby is pretty sensible. JavaScript has many inconsistencies (take Array.slice vs Array.splice - one modifies the original array, and the other does not), and you usually need to rely on third party libraries, or write the code yourself, to do pretty basic operations.
- The JavaScript community seems to have the opposite of NIH syndrome, so that even basic functionality is offloaded to a third-party modules (see leftpad). The project I'm working on has over 1000 modules in it's dependency tree.