15 ms·

I switched from Ruby (after ~8 years) to JavaScript at the beginning of this year, and Ruby is a dream in comparison: - Thanks to the proliferation of Rails an

I switched from Ruby (after ~8 years) to JavaScript at the beginning of this year, and Ruby is a dream in comparison: - 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.

bryanrasmussen 9y ago
I guess I have to agree with everything else, but maybe MVC isn't the best model for a JavaScript application.
dfischer 9y ago
MVC is a simple concept. You don’t need a framework to organize your modules. You can easily do MVC in Js from a vanilla setup. As another commentor suggested, maybe MVC isn’t the right abstraction for the need. That’s the balance in my experience. Sometimes it makes sense, sometimes not. In the end make the compromise that allows you to develop with high reasoning ability and iterate from there.
- meesterdude 9y ago
  > Sometimes it makes sense, sometimes not. 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.
  - throwanem 9y ago
    This sounds a bit like having a hammer, and seeing at least 90% of everything as a nail. Not that I don't find the MVC architecture useful - but really, it is hardly the only valid or reasonable approach, and your speculations on why people choose other approaches strike me as rather ill thought out besides.
    - ryanbrunner 9y ago
      On the other hand, if you find you need new complex told for every job you work on, you might be choosing those tools out of self interest rather than what's most effective. 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.
      - throwanem 9y ago
        Sure, untrammeled neophilia is a problem too, but that's not what we're discussing here, either. No one is saying that MV* is never useful, only that it's not the be-all end-all that the comment I chose to interrogate presented it as being. 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.
- macspoofing 9y ago
  >MVC is a simple concept. You don’t need a framework to organize your modules. 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.
  - beaconstudios 9y ago
    I think the move away from MVC frameworks and the move towards microservices go hand in hand. MVC frameworks are usually better suited to monolithic apps and that's just not the way things are done at the moment, for better or worse.
  - dfischer 9y ago
    Maybe we're not aligned in what I'm trying to communicate. You can create a simple MVC abstraction without a framework. It's just separation of modules and their appropriate concern.
- acjohnson55 9y ago
  Gotta disagree with you there, given the number of frameworks that interpret MVC dramatically differently. I actually don't think it makes sense as a paradigm for server programming to begin with, and we've been trying to shoehorn the M, V, and C on to constructs that are a different thing entirely.
sillysaurus3 9y ago
All of these concerns are not actually concerns. They're a symptom you haven't yet become a JS dev. You have to throw yourself mentally into the ecosystem, wholeheartedly, as if you were diving into a pool. At that point every one of your concerns vanish: - 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.
gkya 9y ago
Rails is crazy. If you know it well maybe it's useful but it's very unapproachable. A new project, empty, involves tens of directories and files and at least two languages (coffeescript). That's been off-putting for me. But Ruby the language is quite pleasant IMO. I guess people confound their experiences of Rails and some other Ruby tooling with the language itself.
- pawelkomarnicki 9y ago
  That's not true (regarding coffeescript), you could always used JavaScript for the front-end, they just installed coffeescript compiler as a default at some point. And there are not SO MANY directories, you actually care about like 3, maybe 4 ;-) (app, db, config, lib)
  - gkya 9y ago
    Well I'm sorry if I was wrong about that, but it being there kind of implies that I should use it, at when I don't know better as a newbie.
- bhaak 9y ago
  Rails was one if not the first opinionated framework. If you follow its design philosophy, it is much easier to work with. 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.
- ritchiea 9y ago
  Every web application requires at least 2 languages (a sever side language and HTML). Virtually all of them also end up also including Javascript and CSS. And Javascript as a server side language is relatively new. That's not a great argument against Rails.
  - setzer22 9y ago
    With clojure you get the frontend logic in clojurescript, backend logic in clojure (or even clojurescript itself) and due to the isomorphism between html and S-expressions, the actual page layout is also described as clojure data in a natural, unambiguous way.
lmm 9y ago
> The project I'm working on has over 1000 modules in it's dependency tree. 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?
- lozenge 9y ago
  1000 opportunities for semver to go wrong. And what happens if dependencies pin different versions of their dependencies? The code is duplicated in the JS bundle?
  - throwanem 9y ago
    Both versions appear there, yes. Not ideal, but I'd be interested to hear what you regard as more optimal behavior in the context of a dependency graph like the one you assume. (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.)
- PeterisP 9y ago
  If you're distributing software, that means that you need to verify the source each of the 1000 dependencies, check if the licence is appropriate, and verify that there aren't any current published vulnerabilities in the version that you're using. Doing this bare minimum of due diligence is easy if you have 10 dependencies, but quite costly for a 1000.
  - Sacho 9y ago
    I don't see how the number of dependencies is important here, instead of their size. You can trivially automate license checks. 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.
ritchiea 9y ago
I would say the JS community has both NIH syndrome and huge dependency trees. Everyone does things differently and there are 5 or 6 kind of decent options for any dependency you might need. Yet somehow there is rarely one great option.
- egeozcan 9y ago
  I'm a bit confused. Wouldn't NIH syndrome be the cause of huge dep. trees? I find it also funny that JS is at the top of the discussion about of article about ruby.
  - deleted 9y ago
    [deleted]
  - Sean1708 9y ago
    Nope, NIH Syndrome[0] is when you don't use a dependency because it wasn't written by your team/company/whatever so one would expect it to lead to smaller dependency trees. [0]: https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here
deleted 9y ago
[deleted]
joekrill 9y ago
What in the world does this have to do with the article in question? There isn't a single mention of Javascript in this entire article. Not even in passing. Jeez it's like a contest around here sometimes: who can bash Javascript the most.
- jbreckmckye 9y ago
  The article states that Ruby has substantial problems. 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.
  - emodendroket 9y ago
    > The biggest and most lucrative alternative to Ruby in that space is JavaScript. I wonder about this. C#, Java, Python, PHP, hell, even Scala are all viable options.
    - jbreckmckye 9y ago
      I'll grant that Java / C# might be more lucrative, but I'm doubtful about the others. The main draw to JS is that if you learn it and use it regularly, you can trade as a full-stack developer.
      - emodendroket 9y ago
        Scala is pretty well-paying, as far as I can tell. And frankly you don't have to be a JS expert to call yourself a full-stack developer; you just have to be conversant. In my experience, anyway. And from what I've seen front-end is the least well-paying specialty.
macspoofing 9y ago
>I switched from Ruby (after ~8 years) to JavaScript at the beginning of this year, and Ruby is a dream in comparison 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).
always_good 9y ago
For me it's the opposite. 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.
- positivecomment 9y ago
  Couldn't agree more. And if you need to make it more concrete, Typescript gives you that and more. Well except the variadic generic types which they are planning to have. I don't like node.js, but I occasionally use Typescript like a more powerful C#.
  - seanmcdirmid 9y ago
    Typescript’s type system is completely structural and unsound. It is very different from C#’s, fitting JavaScript well but not a better more powerful C# by far.
    - positivecomment 9y ago
      I didn't say better. I said "more powerful" and I said that in terms of expressive power. 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.
- afarrell 9y ago
  I do wish there was a keyboard-only debugger for js that was as nice as pry or pdb. Sadly, I'll probably never have a stretch of time to re-learn the C necessary to build one.
  - always_good 9y ago
    Also, after I stopped using Rails, I saw that they started embedding a repl on their error pages with the environment loaded at the point of failure. Pretty sexy. 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.
frik 9y ago
I personally would select a dynamically typed language (preferable with C-like syntax) like JS/PHP/Lua/etc over a statically typed one for web server projects most of the time. Only for specific high performance web server usecases I would use Go or Java. For video games and other high performance applications I would use C++. Larger teams have different requirements.
- always_good 9y ago
  Dynamically-typed languages on the server also tend to work well because they are often just a thin glue layer between a strict data layer (like Postgres) and the client. 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.
jbreckmckye 9y ago
> With JavaScript, once you move past the basic TodoMVC examples you are pretty much on your own. 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.
nautilus12 9y ago
You went the wrong direction :P
- lucaspiller 9y ago
  I followed the money. No other reason :)
emodendroket 9y ago
I guess, but neither language is really good.
ransom1538 9y ago
Sorry stupid question(s) here. People use mobile phones now for basically everything. JS is for building web apps. Webapps are god awful on mobile devices. So why is everyone switching over to JS? Why not just ios/android native -> to a backend. If you need a webpage just a few beautiful static html pages is great. People like the broken scrolling, the rotating arrows, loading circles, alerts?
- allcentury 9y ago
  Many companies are doing javascript everywhere -> https://facebook.github.io/react-native/ https://facebook.github.io/react-native/
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
  - boomlinde 9y ago
    He's asking "why", not "if"
leshow 9y ago
This is like moving from Kotlin to Java or something similar. Within the domain of languages, you haven't moved that much. You stayed with dynamic type system and a JIT or interpretor. Besides a little change in syntax, what else is there. I tend to like to hear about people switching languages that also cross paradigms, OO to Actor, Actor to FP, etc..

bryanrasmussen 9y ago

I guess I have to agree with everything else, but maybe MVC isn't the best model for a JavaScript application.

dfischer 9y ago

MVC is a simple concept. You don’t need a framework to organize your modules. You can easily do MVC in Js from a vanilla setup. As another commentor suggested, maybe MVC isn’t the right abstraction for the need. That’s the balance in my experience. Sometimes it makes sense, sometimes not. In the end make the compromise that allows you to develop with high reasoning ability and iterate from there.

meesterdude 9y ago
> Sometimes it makes sense, sometimes not. 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.
- throwanem 9y ago
  This sounds a bit like having a hammer, and seeing at least 90% of everything as a nail. Not that I don't find the MVC architecture useful - but really, it is hardly the only valid or reasonable approach, and your speculations on why people choose other approaches strike me as rather ill thought out besides.
  - ryanbrunner 9y ago
    On the other hand, if you find you need new complex told for every job you work on, you might be choosing those tools out of self interest rather than what's most effective. 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.
    - throwanem 9y ago
      Sure, untrammeled neophilia is a problem too, but that's not what we're discussing here, either. No one is saying that MV* is never useful, only that it's not the be-all end-all that the comment I chose to interrogate presented it as being. 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.
macspoofing 9y ago
>MVC is a simple concept. You don’t need a framework to organize your modules. 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.
- beaconstudios 9y ago
  I think the move away from MVC frameworks and the move towards microservices go hand in hand. MVC frameworks are usually better suited to monolithic apps and that's just not the way things are done at the moment, for better or worse.
- dfischer 9y ago
  Maybe we're not aligned in what I'm trying to communicate. You can create a simple MVC abstraction without a framework. It's just separation of modules and their appropriate concern.
acjohnson55 9y ago
Gotta disagree with you there, given the number of frameworks that interpret MVC dramatically differently. I actually don't think it makes sense as a paradigm for server programming to begin with, and we've been trying to shoehorn the M, V, and C on to constructs that are a different thing entirely.

sillysaurus3 9y ago

All of these concerns are not actually concerns. They're a symptom you haven't yet become a JS dev. You have to throw yourself mentally into the ecosystem, wholeheartedly, as if you were diving into a pool. At that point every one of your concerns vanish: - 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.

gkya 9y ago

Rails is crazy. If you know it well maybe it's useful but it's very unapproachable. A new project, empty, involves tens of directories and files and at least two languages (coffeescript). That's been off-putting for me. But Ruby the language is quite pleasant IMO. I guess people confound their experiences of Rails and some other Ruby tooling with the language itself.

pawelkomarnicki 9y ago
That's not true (regarding coffeescript), you could always used JavaScript for the front-end, they just installed coffeescript compiler as a default at some point. And there are not SO MANY directories, you actually care about like 3, maybe 4 ;-) (app, db, config, lib)
- gkya 9y ago
  Well I'm sorry if I was wrong about that, but it being there kind of implies that I should use it, at when I don't know better as a newbie.
bhaak 9y ago
Rails was one if not the first opinionated framework. If you follow its design philosophy, it is much easier to work with. 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.
ritchiea 9y ago
Every web application requires at least 2 languages (a sever side language and HTML). Virtually all of them also end up also including Javascript and CSS. And Javascript as a server side language is relatively new. That's not a great argument against Rails.
- setzer22 9y ago
  With clojure you get the frontend logic in clojurescript, backend logic in clojure (or even clojurescript itself) and due to the isomorphism between html and S-expressions, the actual page layout is also described as clojure data in a natural, unambiguous way.

lmm 9y ago

> The project I'm working on has over 1000 modules in it's dependency tree. 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?

lozenge 9y ago
1000 opportunities for semver to go wrong. And what happens if dependencies pin different versions of their dependencies? The code is duplicated in the JS bundle?
- throwanem 9y ago
  Both versions appear there, yes. Not ideal, but I'd be interested to hear what you regard as more optimal behavior in the context of a dependency graph like the one you assume. (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.)
PeterisP 9y ago
If you're distributing software, that means that you need to verify the source each of the 1000 dependencies, check if the licence is appropriate, and verify that there aren't any current published vulnerabilities in the version that you're using. Doing this bare minimum of due diligence is easy if you have 10 dependencies, but quite costly for a 1000.
- Sacho 9y ago
  I don't see how the number of dependencies is important here, instead of their size. You can trivially automate license checks. 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.

ritchiea 9y ago

I would say the JS community has both NIH syndrome and huge dependency trees. Everyone does things differently and there are 5 or 6 kind of decent options for any dependency you might need. Yet somehow there is rarely one great option.

egeozcan 9y ago
I'm a bit confused. Wouldn't NIH syndrome be the cause of huge dep. trees? I find it also funny that JS is at the top of the discussion about of article about ruby.
- deleted 9y ago
  [deleted]
- Sean1708 9y ago
  Nope, NIH Syndrome[0] is when you don't use a dependency because it wasn't written by your team/company/whatever so one would expect it to lead to smaller dependency trees. [0]: https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here

deleted 9y ago

[deleted]

joekrill 9y ago

What in the world does this have to do with the article in question? There isn't a single mention of Javascript in this entire article. Not even in passing. Jeez it's like a contest around here sometimes: who can bash Javascript the most.

jbreckmckye 9y ago
The article states that Ruby has substantial problems. 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.
- emodendroket 9y ago
  > The biggest and most lucrative alternative to Ruby in that space is JavaScript. I wonder about this. C#, Java, Python, PHP, hell, even Scala are all viable options.
  - jbreckmckye 9y ago
    I'll grant that Java / C# might be more lucrative, but I'm doubtful about the others. The main draw to JS is that if you learn it and use it regularly, you can trade as a full-stack developer.
    - emodendroket 9y ago
      Scala is pretty well-paying, as far as I can tell. And frankly you don't have to be a JS expert to call yourself a full-stack developer; you just have to be conversant. In my experience, anyway. And from what I've seen front-end is the least well-paying specialty.

macspoofing 9y ago

>I switched from Ruby (after ~8 years) to JavaScript at the beginning of this year, and Ruby is a dream in comparison 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).

always_good 9y ago

For me it's the opposite. 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.

positivecomment 9y ago
Couldn't agree more. And if you need to make it more concrete, Typescript gives you that and more. Well except the variadic generic types which they are planning to have. I don't like node.js, but I occasionally use Typescript like a more powerful C#.
- seanmcdirmid 9y ago
  Typescript’s type system is completely structural and unsound. It is very different from C#’s, fitting JavaScript well but not a better more powerful C# by far.
  - positivecomment 9y ago
    I didn't say better. I said "more powerful" and I said that in terms of expressive power. 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.
afarrell 9y ago
I do wish there was a keyboard-only debugger for js that was as nice as pry or pdb. Sadly, I'll probably never have a stretch of time to re-learn the C necessary to build one.
- always_good 9y ago
  Also, after I stopped using Rails, I saw that they started embedding a repl on their error pages with the environment loaded at the point of failure. Pretty sexy. 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.

frik 9y ago

I personally would select a dynamically typed language (preferable with C-like syntax) like JS/PHP/Lua/etc over a statically typed one for web server projects most of the time. Only for specific high performance web server usecases I would use Go or Java. For video games and other high performance applications I would use C++. Larger teams have different requirements.

always_good 9y ago
Dynamically-typed languages on the server also tend to work well because they are often just a thin glue layer between a strict data layer (like Postgres) and the client. 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.

jbreckmckye 9y ago

> With JavaScript, once you move past the basic TodoMVC examples you are pretty much on your own. 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.

nautilus12 9y ago

You went the wrong direction :P

lucaspiller 9y ago
I followed the money. No other reason :)

emodendroket 9y ago

I guess, but neither language is really good.

ransom1538 9y ago

Sorry stupid question(s) here. People use mobile phones now for basically everything. JS is for building web apps. Webapps are god awful on mobile devices. So why is everyone switching over to JS? Why not just ios/android native -> to a backend. If you need a webpage just a few beautiful static html pages is great. People like the broken scrolling, the rotating arrows, loading circles, alerts?

allcentury 9y ago
Many companies are doing javascript everywhere -> https://facebook.github.io/react-native/ https://facebook.github.io/react-native/
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- boomlinde 9y ago
  He's asking "why", not "if"

leshow 9y ago

This is like moving from Kotlin to Java or something similar. Within the domain of languages, you haven't moved that much. You stayed with dynamic type system and a JIT or interpretor. Besides a little change in syntax, what else is there. I tend to like to hear about people switching languages that also cross paradigms, OO to Actor, Actor to FP, etc..