There seems to be an ever-present high-level of defensiveness from the Ruby community over JS/React. Rails has had a profound impact on web development, promoting fast starts and shipping quickly. Companies like Shopify and Twitter benefited greatly from this. But the framework is 18 years old. The web that it was created for has changed significantly.
2. For people who had to ship a Rails API + JS SPA, their workflow felt slow, brittle, and cumbersome. It wasn’t their imagination either—testing the stack required integration tests, which are always slow. Maintaining an HTTP API to talk to the SPA is additional effort that’s not needed, which Hotwired has demonstrated clearly.
I still think Rails has a lot of fuel left in its tank, thanks to Hotwired and the big companies behind it, but I agree the “Rails is the most productive framework” gets way overplayed. It was def “most productive” 18 years ago, but most other modern frameworks took notice, caught up, and have even surpassed Rails in a lot of ways.
The Ruby runtime leaves a lot to desire when you compare it to runtimes like Elixir/BEAM, Go, etc. I also think Rails has a terrible view layer, but most folks don’t quite understand that that means yet. This is something I’m working on at the moment.
The Rails view layer used to be quite nice at its peak. Way better than many of the alternatives. That you could execute actual code inside a view was just magical.
The framework was first conceived 18 years ago, but continues to evolve. The framework has also changed significantly to deal with functionality that modern web applications need, in much the same way the Javascript community has evolved to better suit the needs of the modern web application.
Matz is nice but that culture's definitely not coming back, anymore than the kind of fun and curiosity that _why brought to us. Maybe it's inevitable as communities grow and people taste success?
Regardless, it's probably better if we leave room for little jokes with each other.
As someone who quite likes js & our wild teaming ecosystem a lot, I can also say: we definitely deserve some/mamy jokes too. No one's wrong on that. (jokes are good!)
I wish they felt like they had some punchlines though. No one ever bothers to make the JS world laugh along. We know it's wild here (Come play! So much fun freedom!). It comes off more like a beat down.
Context also matters. Conversationally Mike's words could be an amusing wink & grin quip. I can see that. On paper, & seeing it repeated with the same reckless unnuanced antipathy, it lacks the personal connection & feels indicative of a general attitude situation that is quite prevalent.
Again I think there's plenty of valid negativities in js, but looking at the distribution of where folks fall on the alignment chart when they talk about JS issues, it concerns me how lopsidedly & with what casual acceptance folks tend towards the scariest boxes of the chart. To me we are all in the challenge of making computing better together, & we can help ourselves by helping others.
See like, this isn't constructive maligning at all, it's more undirected blanket unniceness.
It costs nothing to actually put down a reason for being upset, versus having totally generic downputs. Very few things are truly rotten to the core, most bad things have some bad aspects but could be much better if ___. If something is rotten to the core the central articles of faith for why that's so should be declared.
Plenty of Ruby folks have gone on to do great friendly Rails ish JS works. Ember.js is very batteries included, tries to show that yes all the potential is there to pave a nice well integrated happy-path system. To assume misery seems unreasonable; many have done fine.
I think we have a real obligation to do better to ourselves & one another than to foster shallow prejudices. Trump in his April 11th Tucker Carlson interview was asked why he thought Dems weren't worried about nuclear weapons. "That's because they don't understand life. That's because they don't understand what it is that you have to understand." This is an irrefutable claim. There's no point to start discussing here, no possibility that the other side might change or have some nuances. Let's not do this. Let's rise to higher places where we take real appraising concerned looks at things, rather than just dismiss stuff out of hand. We don't even have to be nice, but let's at least strive to be somewhat useful.
Both agree in this case with Mike's right to fun, but also, I feel like the idea of lighthearted jabs has become a steady stream of blows. I said elsewhere:
> Context also matters. Conversationally Mike's words could be an amusing wink & grin quip. I can see that. On paper, & seeing it repeated with the same reckless unnuanced antipathy, it lacks the personal connection & feels indicative of a general attitude situation that is quite prevalent.
"Don't get so upset it's just a joke" is sometimes indeed a legit statement, sometimes we do take things too seriously & need to be reminded. But when the light jabs keep coming, when there's so rarely an attempt to ever bring both parties into the laughing, when it's always jokes at expense, the action whatever it's intent becomes part of a larger behavior that is more than a lighthearted jab.
How many folks would stand up and say, no, there is no pattern of behavior about JS receiving short shift put downs? Do folks think there is no issue? How above board Vs how trashy do we think we've gotten with how programmer culture especially those parts that don't like it treats JS? What other parts of programmer culture endure repeated joke making at their expense today?
> How many folks would stand up and say, no, there is no pattern of behavior about JS receiving short shift put downs? Do folks think there is no issue?
If you identify with JavaScript so strongly that you'll go over to message boards and rend your garments when you see people making fun of it, and you consider it a big problem that you have to do this so often... maybe consider whether there are some faults in JavaScript that lead it to attract a steady stream of mockery?
> What other parts of programmer culture endure repeated joke making at their expense today?
This is a callous take that refuses to pause for even the briefest millisecond of reflection. Personal attacks like this & shaming me may make you feel good & smart but as far as I can tell there's still a real topic here & it still deserves some discussion.
I don't go out of my way to start this discussion every time. But sometimes I do. Because it's super notable to me how asymmetric it is. If there was more evidence of programmers dropping little nasty grams about any old topic, I could see it as cultural. That's why I tried to survey the room. It's remarkable to how persistently nasty people are to the most popular language on the planet. It feels decidedly unhacker like to bully me into silence over this search for meaning & inquiry.
I'd like an example of programmers persistently being mean & denigrating to other programmer spaces or languages. That was the context of the rest of my line of questioning, and implied by this question too. The popular/mainstream perception of programmers is unimportant & distracting, disinformation that misleads the discussion; why do some programmers enjoy dropping little vacuous nasty gram jabs at JS, and is this pattern repeated broadly against any other targets?
Are we concluding that JS is the only bad programming thing, thus no one else gets mocked? Maybe JS is a magnet given how popular it is? Or do we think the casual barbs really do go every way & I'm just missing it?
> It costs nothing to actually put down a reason for being upset, versus having totally generic downputs
Actually, it does cost something- time and effort- but thanks to the latest AI, I can cut some of that out right now:
As an Elixir enthusiast, I'd like to point out some technical criticisms of JavaScript and its ecosystem, particularly in comparison to Elixir's approach to dependency management and community.
A) Dependency bloat: The JavaScript ecosystem, especially when working with Node.js, often suffers from excessive dependencies. Even when you require just a few dependencies for your project, you may end up pulling in a large number of indirect dependencies. This can lead to increased complexity, slower build times, a larger attack surface for potential security vulnerabilities, and an ever-growing workload spent applying security fixes that have nothing to directly do with the purpose of the web app.
In contrast, Elixir's dependency management system, powered by Mix and Hex, encourages a more conservative approach. Elixir libraries are often designed with minimal dependencies, and the community values self-contained, focused libraries.
B) Security concerns: The extensive use of third-party packages in JavaScript projects can expose your application to security risks. When you pull in a large number of packages, you become responsible for ensuring that all of those dependencies are up-to-date and secure.
Elixir's ecosystem tends to have fewer dependencies, reducing the potential attack surface. Additionally, Elixir's focus on immutability and the actor model can help minimize the impact of security vulnerabilities.
C) Lack of native concurrency and parallelism: JavaScript is single-threaded by design, which can limit its ability to take full advantage of multi-core systems. While Node.js introduced asynchronous I/O to help mitigate this issue, it can still be challenging to build highly concurrent applications in JavaScript.
Elixir, built on the Erlang VM (BEAM), provides excellent support for concurrency and parallelism through lightweight processes, message-passing, and the actor model. This allows Elixir applications to scale across multiple cores and handle a large number of simultaneous connections more efficiently than most JavaScript applications.
D) Callback hell and async/await complexity: JavaScript has traditionally relied on callbacks for asynchronous programming, which can lead to a phenomenon known as "callback hell" when dealing with nested callbacks. While the introduction of async/await has improved this situation, it can still be cumbersome and confusing for developers.
Elixir offers a cleaner approach to concurrency with its process-based model and message-passing mechanism, enabling easier-to-read and maintainable code.
E) Mutable data- One of the key differences between Elixir and JavaScript is the way they handle data. Elixir enforces immutability, meaning that once a data structure is created, it cannot be modified. Instead, operations on data structures in Elixir return new versions of the data, leaving the original untouched. This approach offers several advantages compared to JavaScript's mutable data structures:
1) Predictability and easier reasoning: Immutability in Elixir makes it easier to reason about and understand your code. Since data structures cannot be changed once created, you don't have to worry about unintended side effects or data being altered in unexpected ways. This results in more predictable and maintainable code.
2) Concurrency safety: Elixir's immutable data structures simplify concurrent programming by eliminating the need for locks, mutexes, or other synchronization primitives. This is because multiple processes can safely read and share the same data without the risk of data corruption due to concurrent modifications. In JavaScript, managing shared mutable data in concurrent scenarios can be error-prone and challenging.
3) Functional programming: Immutability is a core principle of functional programming, and Elixir is heavily influenced by this paradigm. Functional programming promotes the use of pure functions that do not produce side effects, which can make code more modular, reusable, and easier to test. While JavaScript supports functional programming concepts, its mutable data structures can make it more challenging to adhere to functional programming principles.
4) Reduced cognitive load: Immutable data in Elixir means that developers don't have to keep as much track of changing state as they read or write code. This can make it easier to understand the flow of data and logic in your application, leading to a more pleasant and efficient development experience and ultimately, fewer bugs generated per LOC.
F) Community values: The JavaScript community is known for its rapid pace of change and the constant introduction of new libraries, frameworks, and tools. While this can drive innovation, it can also lead to fragmentation and inconsistency across projects.
The Elixir community tends to be more focused on stability, long-term support, and collaboration. This can result in a more consistent and cohesive ecosystem, where tools and libraries are more likely to work together seamlessly.
In conclusion, while JavaScript has its strengths and has undoubtedly played a vital role in the growth of web development, its dependency management and ecosystem can be seen as less than ideal from an Elixir enthusiast's perspective. Elixir's dependency management system, focus on concurrency, and community values offer a more robust, sane and secure alternative.
(How's that for "actually putting down a reason" as to why Javascript is terrible? Hey, you asked!)
Works for me! Very much matches the MO I've been using as "JS is wild, ain't it great!," so I tend to agree with the shown perspective.
I also think a huge amount of these tend to be pretty typical conservative-developer overconcern (see Yegge's Notes From The Mystery Machine Bus https://gist.github.com/cornchz/3313150), governing yourself on fear, that is probably not really as fully warranted or deserved.
But I'm also a huge fan of wild & fun & diversity. I also love that we try & do other things, that programming languages are not a Last Man Standing situation, & that we have great technical ecosystems with caring trying folks finding new ways to move forward & progress like Elixer. I look forward to seeing what lessons there prove really valuable (and perhaps aping them)! It's a choice in JS world but I do use immutable.js, for example, and it's great & as described as an advantage above. Ditto for some fp tools, but often I will mutate & use effectual/imperative styles, I often find there are significant performance or understandabity wins.
I would say, yes, the cost of talking vs snarking may be real, but it doesn't have to be this large & well examined a list as you've madd. I don't like JS, the amount of dependencies terrifies me. I don't like JS, it's too fragmented. I'd rather use Elixer, I like having a good actor model underpinning my ecosystem. Sharing some sort of tidbit can help calibrate where a person is & turn destructive contagious negativity into healthy discourse.
I forgot to reply to this comment but I did like it.
I don't actually hate JS. It's possible to write great JS. (And honestly, things like Elm do exist, and Svelte looks pretty amazing, but these also have their cost.) The failing for me is that there's nothing stopping anyone, especially a library I might decide to depend on, from writing bad JS. This was the same problem I had with Ruby. We spent all this time aiming for thread safety in our app (a whole team spent a lot of time on it) and it turns out the 2 culprits were 2 libs we depended on, because Ruby simply makes no guarantees about thread safety (and cannot, because it's mutable, thus making forking either expensive or dangerous). That and probably a few other things burned me enough to make me say "no more" and I suddenly loved the idea of a language where "thread safety" is completely a given and impossible to violate and you don't have to mutex-lock everything.
I don't think FP will ever get popular, unfortunately, unless we NEVER teach ANYONE ANYTHING but FP, because the people that pay the cost of learning the FP way are paying it because of all the ways they got burned by the non-FP (OOP, imperative, mutable) ways...
If you ever get there yourself, you have my hat-tip. And truly, it is worth the journey.
It doesn't have to be like this. Your community tried to be better once. Have you forgotten?
https://jasonfleetwoodboldt.com/courses/stepping-up-rails/ma...