Our great sponsors
-
-
Nest
A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications with TypeScript/JavaScript 🚀
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
proposals
✍️ Tracking the status of Babel's implementation of TC39 proposals (may be out of date) (by babel)
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
-
-
openapi-typescript-codegen
NodeJS library that generates Typescript or Javascript clients based on the OpenAPI specification
-
graphql-code-generator
A tool for generating code based on a GraphQL schema and GraphQL operations (query/mutation/subscription), with flexible support for custom plugins.
-
Devise Token Auth
Token based authentication for Rails JSON APIs. Designed to work with jToker and ng-token-auth.
-
awesome-cli-frameworks
Collection of tools to build beautiful command line interface in different languages
-
-
openapi-generator
OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I started my career with Rails, then some frontend, and now work a full-time job in Node. Agree with most or all of these points - full-stack javascript is kind of a mess and hasn't really progressed despite individual tools having done so. I think https://sailsjs.com set out to solve a lot of these issues many years ago, by trying to be a JavaScript version of Rails. I'm not sure if they ever reached "feature-parity" though.
RedwoodJS may be something you want to check out.
https://redwoodjs.com/
Agreed with everything you say here. Really want there to be a go-to Rails-like framework for JS, but nothing has reached that point yet.
I'm very bullish on SvelteKit — hits all the points you mention above and outputs a minimal, performant app. https://kit.svelte.dev/ Still in beta and changing a lot but really really lovely to use.
Heck, to scratch my own itch I'm even making a Rails-like SaaS boilerplate to go on top of SvelteKit to give me all models, user auth, admin dashboards, payments, etc that you need in almost every app these days: https://sveltesaas.com
The working group most in charge of JS is ECMA's TC-39 (TC => Technical Committee) [0]. They've been taking a very deliberate, slow path to expanding the "standard" library because they take a very serious view of backwards compatibility on the web. Some proposals were shifted because of conflicts with ancient versions of things like MooTools still out in the wild, for instance. (This was the so-called "Smooshgate" incident [1].)
This may speed up a bit if the Built-In Modules proposal [2] passes, which would add a deliberate `import` URL for standard modules which would give a cleaner expansion point for new standard libraries over adding more global variables or further expanding the base prototypes (Object.prototype, Array.prototype, etc) in ways that increasingly likely have backwards compatibility issues.
TC-39 works all of their proposals in the open on Github [3] and it can be a fascinating process to watch if you are interested in the language's future direction.
[0] https://tc39.es/
[1] https://developers.google.com/web/updates/2018/03/smooshgate
[2] https://github.com/tc39/proposal-built-in-modules
[3] https://github.com/tc39/proposals
The working group most in charge of JS is ECMA's TC-39 (TC => Technical Committee) [0]. They've been taking a very deliberate, slow path to expanding the "standard" library because they take a very serious view of backwards compatibility on the web. Some proposals were shifted because of conflicts with ancient versions of things like MooTools still out in the wild, for instance. (This was the so-called "Smooshgate" incident [1].)
This may speed up a bit if the Built-In Modules proposal [2] passes, which would add a deliberate `import` URL for standard modules which would give a cleaner expansion point for new standard libraries over adding more global variables or further expanding the base prototypes (Object.prototype, Array.prototype, etc) in ways that increasingly likely have backwards compatibility issues.
TC-39 works all of their proposals in the open on Github [3] and it can be a fascinating process to watch if you are interested in the language's future direction.
[0] https://tc39.es/
[1] https://developers.google.com/web/updates/2018/03/smooshgate
[2] https://github.com/tc39/proposal-built-in-modules
[3] https://github.com/tc39/proposals
I don't think the Rails Guides mention Devise, the authentication gem, which is pretty important if you want create a public facing website with users. The devise documentation is pretty good though. Again, a little bit of a learning curve, but once you learn it you can add user authentication to your site pretty quickly.
https://github.com/heartcombo/devise#getting-started
Rails has a templating system for generating emails (standard HTML/ERB files). If you're running an ASP.NET Web API (not MVC) the best way of doing that I've found is via Razorlight which you have to set up manually - https://github.com/toddams/RazorLight
With Rails the standard is pretty much Devise or Omniauth (or both) - does everything for you. I've never found anything for ASP like Devise which gives you an entire login system with all the required views/migrations in a couple commands.
> Rails 7 has abandoned JS bundling in favor of using somebody else's CDN. Have fun with that.
This isn't true. You can vendor your JS libraries and Rails will bundle them for you. It uses jsbundling-rails[1] to handle that.
https://youtu.be/mpWFrUwAN88?t=772
[1]https://github.com/rails/jsbundling-rails
The guides are great for someone doing what most people use Rails for. Recipes with some side cases are very appropriate for that audience.
If you want to know more about an API, there's https://api.rubyonrails.org and the classes are quite will documented. These docs don't show up in the guides and might be what you're looking for.
Specifically for routing, there's lots of additional detail here: https://api.rubyonrails.org/classes/ActionDispatch/Routing/M...
I'm currently working on two separate projects, the first is a Django project with DRF and I codegen with drf-spectacular [1] and openapi-typescript-codegen [2]. The other project also uses Django, with the API through Hasura and codegen with graphql-codegen [3]. In both of these cases I've been able to largely avoid duplicating my models clientside, or at least it isn't manual.
1: https://github.com/ferdikoomen/openapi-typescript-codegen
2: https://drf-spectacular.readthedocs.io/en/latest/
3: https://github.com/dotansimha/graphql-code-generator
I'm currently working on two separate projects, the first is a Django project with DRF and I codegen with drf-spectacular [1] and openapi-typescript-codegen [2]. The other project also uses Django, with the API through Hasura and codegen with graphql-codegen [3]. In both of these cases I've been able to largely avoid duplicating my models clientside, or at least it isn't manual.
1: https://github.com/ferdikoomen/openapi-typescript-codegen
2: https://drf-spectacular.readthedocs.io/en/latest/
3: https://github.com/dotansimha/graphql-code-generator
I mentioned Identity in my first comment. I've never found it as simple as Devise though - especially in an API only setting.
With Devise there's a third-party Gem you can use called devise_token_auth which deals with everything automatically.
https://github.com/lynndylanhurley/devise_token_auth
Thor looks great! I'd be surprised if something similar didn't exist for most languages, but with many of them living in obscurity because discovery is so hard without a well-established name for that class of tool. Some googling for "CLI framework" led me to oclif ("Thor for js"?) and to https://www.nexmo.com/legacy-blog/2020/06/12/comparing-cli-b... , but that can't be everything.
PS: https://github.com/shadawck/awesome-cli-frameworks also lists some for go and rust, getting there! (though most probably not half as complete as Thor, self-documentation should definitely be a first-class citizen!)
Check out Rux which is «A jsx-inspired way to render view components in Ruby» [to make HTML on the server]. https://github.com/camertron/rux
AFAIK Hotwire Stimulus isn’t using WebSockets. I think you’re thinking of StimulusReflex.
Normal Hotwire Stimulus is just JS controllers that references DOM nodes via CSS tags. Example: https://stimulus.hotwired.dev/
I agree that JSX is better.
