4 ms·

Does that mean there's still room in the JS ecosystem for a Rails-alike? Maybe one that could become very popular? Because I am looking for a major open source

by sbjs 8y ago

Does that mean there's still room in the JS ecosystem for a Rails-alike? Maybe one that could become very popular? Because I am looking for a major open source project to create and spearhead, something that could get hundreds of thousands of active users and a thriving subcommunity, but I've been holding off until I find just the right project.

savanaly 8y ago
There's definitely the need for this in JS. It would be extremely difficult to do, though.
vinceguidry 8y ago
Personally, having developed in both Rails and Node, I now believe that trying to recreate Rails in JS is a foolish effort. Rails is a huge project with a ton of weight behind it and unless you can generate a massive amount of corporate investment, you won't ever be able to really catch up. I'm not saying that there's no room in the JS ecosystem for another web framework, what I'm saying is that if your design goal is re-implementing Rails, you're already setting yourself up for failure. Sequelize has tried to be ActiveRecord for how long? The only thing it makes me do is want to go back to Ruby and Rails. No, what you have to figure out if you want to do a JavaScript web framework is how to get me to actually want to use JavaScript to program a website. How can prototypical inheritance actually contribute to a workflow as opposed to a more conventional inheritance scheme. But honestly, quite frankly, I can't tell what anyone would want to use JavaScript on the server at all for.
- tlrobinson 8y ago
  Apparently Steve Yegge ported much of Rails to JavaScript (on Rhino, at the time) back in 2007 at Google, but it was never open sourced AFAIK: https://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html https://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html For comparison, (according to `find . -name "*.rb" | xargs wc -l`) Rails back then was about 66K LOC (plus 38K LOC of tests) and is now 137K LOC (plus 216K LOC of tests). However, Steve says he only ported "essentially all of ActionView, ActionController and Railties, plus a teeny bit of ActiveRecord", so maybe half of the total.
- tlrobinson 8y ago
  As for the second half of your comment, it sounds like you haven't used JavaScript in awhile. ES6 introduced syntax for classical inheritance, and a bunch of other nice features.
  - vinceguidry 8y ago
    I use ES6 at my job, daily. There are some things about it that make me really hate it. First, no, it doesn't introduce classical inheritance. It introduced syntax that looks like classical inheritance. It's still prototypal inheritance under the hood. I'm not entirely sure what this means yet from the standpoint of building things with it, but I'm not enthused at the prospect. What I find happens fairly frequently with ES6 that I never found with Vanilla JS is that the extra features built on top of JS 'break'. If you add syntax to a language, that syntax needs to work. I need to be able to rely on it working. I run into constant little issues that make me think I'm missing something about scoping, when really it's some under-the-hood issue with a library or something I just don't have the time to pin down. One example is I tried using the spread operator to add keys to an object. But the spread simply, well, failed. Passing in the object worked fine. Passing in a spread version of the same object failed. I haven't resolved it yet, got pulled onto another feature. This sort of breakage is hard to Google, when I run into it again, and I'm sure I will, I may have to troubleshoot it all the way to Babel. Error reporting in Node with ES6 is garbage. Worse than garbage, it's a veritable dumpster fire. Ideally the error points to the problem, when it doesn't point to the problem you have to rely on experience and intuition to lead you to the issue. Many many errors I come across in JS are of this sort. I think most of these issues come down to the fact that ES6 is a transpiled language. This makes me long for the days of good old CoffeeScript. At least CS was close enough to Vanilla that it was easy to determine when you had an issue with the transpiler, simply grab the snippet of code and paste it into the online transpiler, look at the generated JS and work out your issue from there. It wasn't the smoothest workflow but it was effective. ES6 is stupid in ways that make building an effective workflow unreasonably difficult. I can't wait to get back to Rails. Vanilla JS wasn't that bad. It was well-understood and you could work with it effectively on the front-end. It certainly wasn't as pleasant as Ruby, but it didn't feel like the pile of hacks that ES6 does. Maybe once it stops being transpiled it'll get better.
gunn 8y ago
Definitely. And using these technologies, there are some cool possibilities beyond what rails is capable of. For instance if you used typescript (still allows devs to use plain JS), you could use types to check that forms send all the required params. For example, a login page might require: interface LoginParams { username: string; password: string; rememberMe?: boolean; } Having the typescript compiler check for inconsistencies with form data would save a lot of the troubles I've seen in rails apps.
- nicoburns 8y ago
  Unfortunately TypeScript doesn't do runtime checks like this. It assumes that incoming data conforms to the type spec! However, you might be interested in the Rocket framework (written in Rust), which does do exactly that: https://rocket.rs/ https://rocket.rs/
  - sbjs 8y ago
    TypeScript can do runtime checks like this! Granted it uses a TypeScript framework (similar to AJV) that both does the runtime checks and preserves type information for your IDE and type checker. I wrote about it here: https://medium.com/@stevenbradleyconsulting/from-0-to-type-safe-rpc-with-typescript-20f131fff3e8 https://medium.com/@stevenbradleyconsulting/from-0-to-type-s...
    - eropple 8y ago
      Aw, man - I'd hoped you'd found something to make this less of a stone-cold pain to do. Instead, it's io-ts again. Which is...interesting...but it really sucks to actually use when you have to manually define every in/out yourself. It's 2018. There's no good reason TypeScript can't emit the type information to just build these (and I don't really mean decorator metadata).
      - sbjs 8y ago
        You can add another build step right after the `tsc -w` compilation phase, which takes your .ts files, parses them to find our your types, and emits runtime code that checks your types. That's what you're describing that TypeScript should be doing on its own. But I don't see why you'd want to do this instead of using io-ts? This is more complicated overall.
crooked-v 8y ago
It sounds like you're looking for Ember. https://www.emberjs.com https://www.emberjs.com
- sbjs 8y ago
  Ember is a front-end framework, Rails is back-end.

by sbjs 8y ago

savanaly 8y ago

There's definitely the need for this in JS. It would be extremely difficult to do, though.

vinceguidry 8y ago

Personally, having developed in both Rails and Node, I now believe that trying to recreate Rails in JS is a foolish effort. Rails is a huge project with a ton of weight behind it and unless you can generate a massive amount of corporate investment, you won't ever be able to really catch up. I'm not saying that there's no room in the JS ecosystem for another web framework, what I'm saying is that if your design goal is re-implementing Rails, you're already setting yourself up for failure. Sequelize has tried to be ActiveRecord for how long? The only thing it makes me do is want to go back to Ruby and Rails. No, what you have to figure out if you want to do a JavaScript web framework is how to get me to actually want to use JavaScript to program a website. How can prototypical inheritance actually contribute to a workflow as opposed to a more conventional inheritance scheme. But honestly, quite frankly, I can't tell what anyone would want to use JavaScript on the server at all for.

tlrobinson 8y ago
Apparently Steve Yegge ported much of Rails to JavaScript (on Rhino, at the time) back in 2007 at Google, but it was never open sourced AFAIK: https://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html https://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html For comparison, (according to `find . -name "*.rb" | xargs wc -l`) Rails back then was about 66K LOC (plus 38K LOC of tests) and is now 137K LOC (plus 216K LOC of tests). However, Steve says he only ported "essentially all of ActionView, ActionController and Railties, plus a teeny bit of ActiveRecord", so maybe half of the total.
tlrobinson 8y ago
As for the second half of your comment, it sounds like you haven't used JavaScript in awhile. ES6 introduced syntax for classical inheritance, and a bunch of other nice features.
- vinceguidry 8y ago
  I use ES6 at my job, daily. There are some things about it that make me really hate it. First, no, it doesn't introduce classical inheritance. It introduced syntax that looks like classical inheritance. It's still prototypal inheritance under the hood. I'm not entirely sure what this means yet from the standpoint of building things with it, but I'm not enthused at the prospect. What I find happens fairly frequently with ES6 that I never found with Vanilla JS is that the extra features built on top of JS 'break'. If you add syntax to a language, that syntax needs to work. I need to be able to rely on it working. I run into constant little issues that make me think I'm missing something about scoping, when really it's some under-the-hood issue with a library or something I just don't have the time to pin down. One example is I tried using the spread operator to add keys to an object. But the spread simply, well, failed. Passing in the object worked fine. Passing in a spread version of the same object failed. I haven't resolved it yet, got pulled onto another feature. This sort of breakage is hard to Google, when I run into it again, and I'm sure I will, I may have to troubleshoot it all the way to Babel. Error reporting in Node with ES6 is garbage. Worse than garbage, it's a veritable dumpster fire. Ideally the error points to the problem, when it doesn't point to the problem you have to rely on experience and intuition to lead you to the issue. Many many errors I come across in JS are of this sort. I think most of these issues come down to the fact that ES6 is a transpiled language. This makes me long for the days of good old CoffeeScript. At least CS was close enough to Vanilla that it was easy to determine when you had an issue with the transpiler, simply grab the snippet of code and paste it into the online transpiler, look at the generated JS and work out your issue from there. It wasn't the smoothest workflow but it was effective. ES6 is stupid in ways that make building an effective workflow unreasonably difficult. I can't wait to get back to Rails. Vanilla JS wasn't that bad. It was well-understood and you could work with it effectively on the front-end. It certainly wasn't as pleasant as Ruby, but it didn't feel like the pile of hacks that ES6 does. Maybe once it stops being transpiled it'll get better.

gunn 8y ago

Definitely. And using these technologies, there are some cool possibilities beyond what rails is capable of. For instance if you used typescript (still allows devs to use plain JS), you could use types to check that forms send all the required params. For example, a login page might require: interface LoginParams { username: string; password: string; rememberMe?: boolean; } Having the typescript compiler check for inconsistencies with form data would save a lot of the troubles I've seen in rails apps.

nicoburns 8y ago
Unfortunately TypeScript doesn't do runtime checks like this. It assumes that incoming data conforms to the type spec! However, you might be interested in the Rocket framework (written in Rust), which does do exactly that: https://rocket.rs/ https://rocket.rs/
- sbjs 8y ago
  TypeScript can do runtime checks like this! Granted it uses a TypeScript framework (similar to AJV) that both does the runtime checks and preserves type information for your IDE and type checker. I wrote about it here: https://medium.com/@stevenbradleyconsulting/from-0-to-type-safe-rpc-with-typescript-20f131fff3e8 https://medium.com/@stevenbradleyconsulting/from-0-to-type-s...
  - eropple 8y ago
    Aw, man - I'd hoped you'd found something to make this less of a stone-cold pain to do. Instead, it's io-ts again. Which is...interesting...but it really sucks to actually use when you have to manually define every in/out yourself. It's 2018. There's no good reason TypeScript can't emit the type information to just build these (and I don't really mean decorator metadata).
    - sbjs 8y ago
      You can add another build step right after the `tsc -w` compilation phase, which takes your .ts files, parses them to find our your types, and emits runtime code that checks your types. That's what you're describing that TypeScript should be doing on its own. But I don't see why you'd want to do this instead of using io-ts? This is more complicated overall.

crooked-v 8y ago

It sounds like you're looking for Ember. https://www.emberjs.com https://www.emberjs.com

sbjs 8y ago
Ember is a front-end framework, Rails is back-end.