21 ms·

I've a bunch of small Rails apps running on Heroku and I've to say that I'm impressed by the relevance of the new features in the latest Rails releases. Action

I've a bunch of small Rails apps running on Heroku and I've to say that I'm impressed by the relevance of the new features in the latest Rails releases. Action Text, Active Storage and Action Cable are solving common and painful issues in any web app. I've recently built a web app with Node and the time we spent solving problems which have already been solved a thousand times is astonishing. Things like picking an ORM, having a proper database migration system, running a test suite. It's actually quite depressing when you come from Rails where everything is working coherently out of the box. The fact that there is no standards in the Node ecosystem make it a bit more painful. You have to carefully choose between many different libraries to solve your problem. Some of them are in TypeScript, other still use callbacks, etc. We basically had to glue together many libraries to get something working. All those hours could have been spent building the actual product and delivering value to our customers. Hope they will ship many more releases!

tsotpsstt 7y ago
Well, I don't believe rich text editing and websockets are that common to be included in Rails by default. I can't find any excuse for not distributing those features as separate gems. It's not that hard to add "gem actiontext" to the Gemfile and run "bundle install" if you're one of that 1-2% who needs WYSIWYG.
- freehunter 7y ago
  I don't have any numbers to back it up but I believe you're wildly underestimating the number of Rails projects that need WYSIWYG editing. The state of WYSIWYG editors in Rails is so unacceptably poor that I'm glad they're bundling it out of the box. It's kind of like Microsoft making their own laptops, because every other Windows laptop of the time was undeniably junk.
  - dzader 7y ago
    Yeah, I am extremely excited about this - small sample size but I've worked on a handful of rails apps and I seem to always need a WYSIWYG editor and could never find one I really liked - glad to see it better incorporated!
  - debaserab2 7y ago
    > the state of WYSIWYG editors in Rails is so unacceptably poor Rails is a web framework. Why does it have anything to do with a WYSIWYG editor on the frontend? There's a giant vast offering of WYSIWYG editors to choose from that POST data back to your web backend just like any other form. I don't want rails to have any opinion or "state" of WYSIWYG selection for my application. I kinda feel like Rails had it's heyday around 3.2 or 4.0 and since then has been creating problems to solve instead of solving actual popular use cases.
    - hit8run 7y ago
      You don't need to use action text if you want to go with an own solution. Action Text is so well integrated that inserting (and uploading) images via drag and drop works out of the box.
    - freehunter 7y ago
      >I don't want rails to have any opinion Man did you pick the wrong framework. >There's a giant vast offering of WYSIWYG editors to choose from As someone who has tried them all, I can definitively say this is not true. Trix/ActionText is the only one that works. >Why does it have anything to do with a WYSIWYG editor on the frontend? Because Rails is a full stack web framework. It includes its own front-end for tons of stuff. It's opinionated and wants people to do things The Rails Way.
      - debaserab2 7y ago
        > As someone who has tried them all, I can definitively say this is not true. Trix/ActionText is the only one that works. That's an obviously false statement. There's like a dozen react based ones alone and at least as many vanilla JS ones all over the web. I've implemented several in Rails before with image upload support. Works no differently than any other web backend. > Because Rails is a full stack web framework. It includes its own front-end for tons of stuff. It's opinionated and wants people to do things The Rails Way. No, Rails explicitly does not have opinions on everything. It doesn't even come with built in authentication handling, which is a pretty major web framework component. I like that it has strong opinions about things like handling the HTTP request/response, configuration, code layout, ORM, etc but leaves a lot to the user to implement. In the past they've even culled features off into their own gem when they decided it wasn't relevant enough. A WYSIWYG text editor doesn't seem all that much like core functionality to me.
  - reilly3000 7y ago
    It looks like a decent WYSIWYG editor was one of the headline features of this 6.0 release. Its straight from Basecamp so you know its polished to the hilt. https://trix-editor.org/ https://trix-editor.org/ https://edgeguides.rubyonrails.org/action_text_overview.html https://edgeguides.rubyonrails.org/action_text_overview.html
- geospeck 7y ago
  You can choose to skip them rails new app_name --skip-action-cable --skip-action-text etc... Most of these libraries can be skipped, just type: rails new -h see all the options Edit: in case you decide later on that you need them you can install them as you described with `gem actiontext` etc...
- pmontra 7y ago
  Of all the Rails projects I've been working on in the the last 15 years (all of them) probably only two needed rich text editing. One of them is the only Rails project I'm working on now. We're not changing the editor (ckeditor) but I could start a new project with the new default. I wouldn't mind installing it as a separate gem.
freehunter 7y ago
I've been trying to use NodeJS after using Rails for years and it's just such a terrible experience. I don't want to install every basic package by hand and generate every model and view and controller by hand. This is basic boilerplate nonsense that made Rails so popular 15 years ago, and NodeJS throws away every lesson we learned from Rails. React is okay as a front-end but without a full stack framework, the current state of Javascript is like stepping back into 20 year old PHP development, where everyone just hacks together anything they can find with no structure, no convention, and no security.
- martinlev 7y ago
  Definitely agree with this. I have been switching from developing in ruby into Node 2 years ago as I thought this was "the new thing" for web apps. Now I just want to move away from Node. Large scale Node applications looks like 20 years ago, copy and paste all over the place, cheap libraries, no developer happiness, you have to reinvent the wheels, etc.
  - selestify 7y ago
    Why did Node become so popular if this is the case?
    - deleted 7y ago
      [deleted]
    - lbotos 7y ago
      "WebScale" and a generation of programmers that grew up on Javascript thinking it would be cool to write JS on the server too.
    - laumars 7y ago
      Laziness I think. People wanted to use the same language for the backend as the frontend rather than picking their tools based on what does the job the best.
      - 7y ago
aledalgrande 7y ago
The main pain with Node, if you come from outside, is being able to know which modules are well supported, and will be for the years coming. As an example, I spent quite a long time investigating ORM libraries for relational DBs, and the projects that were half dead were the majority. Knex was suggested by everyone, but at that time the project leadership was changing so the future was uncertain. I settled on Sequelize, which had most of the functionality, but several points did not make sense: - the documentation is hard to search - I had to create a PR for sequelize-cli (separate module, that is not recommended for production!) to get the same functionality of `rails db:create` - the syntax was changed to use Op instead of strings for security, in a minor version - the way associations are defined is weird at best - no support for ES6 in the cli, so all migrations are ES5 Etc. And this is just for an API server. I looked into the frontend part and it was so much work. I am still using Node for server processes when I have to, but I wouldn't recommend it over Rails. The way you can generate a simple app that does something useful, configure it and deploy it to Heroku in few hours is unchallenged.
- zawerf 7y ago
  > know which modules are well supported, and will be for the years coming Doesn't matter if you're coming from outside or not, no one can predict the future. For example winston was probably the most recommended logging library (14k stars) and was a good recommendation at one point. But then they decided to do a rewrite for v3 which introduced a ton of bugs and incompatibilities. I spent several days trying to get it to log in the old format and failed and ended up downgrading back to v2. This is a recurring theme in the js ecosystem (another example is react-router which is just a huge piece of shit and no one should depend on it despite its 37k stars).
  - fyfy18 7y ago
    Any suggestions for an alternative to react-router?
    - ybahubali2018 7y ago
      Did you tried Router5( https://router5.js.org/ https://router5.js.org/ ) They have a react version. I experimented with it in one of the small projects i worked on. My experience was positive. Most importantly, it's API is simple and easy to use.
Cort3z 7y ago
Node.js is not equivalent of Rails. Rails is a framework, while Node.js is a runtime. Node.js is equivalent of MRI.
- anm89 7y ago
  Everybody is aware of this. The point is why would you choose the node ecosystem for any complex task when it forces you to manually solve all of the things Rails does for free. It's insane for a project of any complexity except for very specialized cases. Put another way, you're exactly right, it is apples to oranges, or a better analogy might be a Porsche to a Pontiac. Why would you ever choose the thing which is inferior in almost every way?
  - Cort3z 7y ago
    From the comments it does not look like necessary everyone is aware of this. You should have a look at things like adonisjs.com to get a better comparison. I am not saying node-based tech is better or worse, but to dismiss all nodejs server side and say Rails is better at everything is not a healthy attitude, especially regarding the shaky history of the Ruby language itself (eg. The whole RubySpec thing). And; how can node be inferior in every way when it isn't even the same kind of entity? It seems you are barking up the wrong tree. It is a testament to how successful Rails is when it is hard to distinguish it from the programming language it runs on. Congrats to them.
chaostheory 7y ago
Node's main problem is that the only real dominant framework is express, a Sinatra like framework. Other than that there's so many redundant libraries and frameworks, that it's hard not to suffer from the paradox of choice, which eats up a lot of time. It's a bit easier though if you limit yourself to using Typescript based frameworks; less choices.
hrdwdmrbl 7y ago
You're right about Node, but I think it's a bit apples to oranges because they're suited to different use-cases. Rails is great for mostly static sites. Node is great for mostly dynamic sites. It's almost as simple as that.
- cutler 7y ago
  Whilst Node and Rails certainly have different niches the distinction between static and dynamic sites is lost on me. Both are written in dynamically-typed languages and both produce HTTP responses dynamically. What's the basis of your Rails = static sites assertion?
  - hrdwdmrbl 7y ago
    I didn't literally mean static sites ️ By static I mean I site like Github, Craigslist, Wikipedia. Stuff doesn't change often. Uses forms for submitting data. By dynamic I mean sites that make heavy use of ajax, you want real-time anything, high levels of interactivity in the interface. These are often apps.
    - cutler 7y ago
      Rails has an --api option and most of the Rails roles offered by recruiters these days are a combination of Rails and React, Vue or Angular. Rails assets are served with webpack and there are options for React, Vue and Angular when creating a new Rails app.
      - hrdwdmrbl 7y ago
        Yes but Rails is still optimized for REST CRUD apps. It's great at those apps. I use it to develop those kinds of apps. But when you want something super reactive and customized and interactive and dynamic and real-time, I reach for Node.
        cutler 7y ago
jamil7 7y ago
My two cents is the sweet spot for node is as an auxiliarily tool rather than a whole web app framework. For instance adding some realtime functionality to an existing app, as a server renderer for SPAs or some microservice glue. The community has resisted large rails-like frameworks from the beginning and I think it just shouldn't be used this way.
WhitneyLand 7y ago
There’a an architectural lesson to be learned/recalled here for “hardcore” developers. I didn’t realize that Github ran mostly on Rails until this article and was kind of surprised given the scale of the site and Rails reputation for performance. It’s a great reminder of architecture/design truism: if your site is not inherently performance bottlenecked, then you problably shouldn’t let language or framework performance be the sole deciding factor in choosing or whether to migrate to a platform. Unless we’re talking about >= order of magnitude difference, or a site whose user experience is being limited by performance. Perf and scalability are just one factor. Pragmatism across many factors with perf/scale being one, and making yourself as blind as possible to technology religion, biases, personal investments, and digging beyond simplistic conventional wisdom (rails has perf issues), looks to remain a core ability for making arch decisions. Experience can actually be a negative: I wouldn’t have a problem developing efficiently in node or coming up with an alternative to migrations for example. But what I can or cannot ramp up on quickly the fastest is likely irrelevant and maybe detrimental when considering what’s best for a project as a whole. Seeing comments here about productively gains from specific Rails features, and another comment saying they can’t imagine living without migrations as a built in feature, just seem like great reminders of how important it is to try and avoid making decisions relative to the experience or needs of only one or a few people. It seems like good tech arch decisions need to consider DX issues enough to seem very similar to good UX decisions, the primary contrast being the users have very different stories and requirement scenarios.
ChefboyOG 7y ago
As someone who did their first "serious" web development with Node, but has worked for the last year at a Rails shop, I still love Node for my personal projects, but much prefer Rails for anything that requires collaboration. Ryan Dahl has a speech about his regrets with Node, and most of them center around the way code is managed. IME, the sloppiness to how code is managed in Node, combined with the lack of conventions/dominant Rails-esque framework in the Javascript ecosystem, leads to codebases where no one is sure how or why something is set up the way it is. As annoyed as I sometimes get with Rails' forced conventions or auto-magic abstractions, the beauty is that they are consistent. With a team full of experienced Rails engineers, you can pretty much guarantee that multiple people on your team can explain the "why" behind something quickly. This is a massive productivity save, especially when you're ramping up.
truth_seeker 7y ago
Following are the alternatives :- Action text in RoR <=> DraftJS (Isomorphic ReactJS plugin with server side rendering), Froala (compatible with most of SPA frameworks) Active Record in RoR <=> SequelizeJS (ORM), Slonik(Non-ORM, my recommendation) in NodeJS Action Cable in RoR <=> WS, Socket.io 2.0 (recommended) DraftJS - https://github.com/facebook/draft-js https://github.com/facebook/draft-js Froala - https://www.froala.com/wysiwyg-editor https://www.froala.com/wysiwyg-editor SequelizeJS - https://sequelize.org/master/ https://sequelize.org/master/ Slonik - https://github.com/gajus/slonik https://github.com/gajus/slonik WS - https://github.com/websockets/ws https://github.com/websockets/ws Socket.io - https://socket.io/ https://socket.io/

tsotpsstt 7y ago

Well, I don't believe rich text editing and websockets are that common to be included in Rails by default. I can't find any excuse for not distributing those features as separate gems. It's not that hard to add "gem actiontext" to the Gemfile and run "bundle install" if you're one of that 1-2% who needs WYSIWYG.

freehunter 7y ago
I don't have any numbers to back it up but I believe you're wildly underestimating the number of Rails projects that need WYSIWYG editing. The state of WYSIWYG editors in Rails is so unacceptably poor that I'm glad they're bundling it out of the box. It's kind of like Microsoft making their own laptops, because every other Windows laptop of the time was undeniably junk.
- dzader 7y ago
  Yeah, I am extremely excited about this - small sample size but I've worked on a handful of rails apps and I seem to always need a WYSIWYG editor and could never find one I really liked - glad to see it better incorporated!
- debaserab2 7y ago
  > the state of WYSIWYG editors in Rails is so unacceptably poor Rails is a web framework. Why does it have anything to do with a WYSIWYG editor on the frontend? There's a giant vast offering of WYSIWYG editors to choose from that POST data back to your web backend just like any other form. I don't want rails to have any opinion or "state" of WYSIWYG selection for my application. I kinda feel like Rails had it's heyday around 3.2 or 4.0 and since then has been creating problems to solve instead of solving actual popular use cases.
  - hit8run 7y ago
    You don't need to use action text if you want to go with an own solution. Action Text is so well integrated that inserting (and uploading) images via drag and drop works out of the box.
  - freehunter 7y ago
    >I don't want rails to have any opinion Man did you pick the wrong framework. >There's a giant vast offering of WYSIWYG editors to choose from As someone who has tried them all, I can definitively say this is not true. Trix/ActionText is the only one that works. >Why does it have anything to do with a WYSIWYG editor on the frontend? Because Rails is a full stack web framework. It includes its own front-end for tons of stuff. It's opinionated and wants people to do things The Rails Way.
    - debaserab2 7y ago
      > As someone who has tried them all, I can definitively say this is not true. Trix/ActionText is the only one that works. That's an obviously false statement. There's like a dozen react based ones alone and at least as many vanilla JS ones all over the web. I've implemented several in Rails before with image upload support. Works no differently than any other web backend. > Because Rails is a full stack web framework. It includes its own front-end for tons of stuff. It's opinionated and wants people to do things The Rails Way. No, Rails explicitly does not have opinions on everything. It doesn't even come with built in authentication handling, which is a pretty major web framework component. I like that it has strong opinions about things like handling the HTTP request/response, configuration, code layout, ORM, etc but leaves a lot to the user to implement. In the past they've even culled features off into their own gem when they decided it wasn't relevant enough. A WYSIWYG text editor doesn't seem all that much like core functionality to me.
- reilly3000 7y ago
  It looks like a decent WYSIWYG editor was one of the headline features of this 6.0 release. Its straight from Basecamp so you know its polished to the hilt. https://trix-editor.org/ https://trix-editor.org/ https://edgeguides.rubyonrails.org/action_text_overview.html https://edgeguides.rubyonrails.org/action_text_overview.html
geospeck 7y ago
You can choose to skip them rails new app_name --skip-action-cable --skip-action-text etc... Most of these libraries can be skipped, just type: rails new -h see all the options Edit: in case you decide later on that you need them you can install them as you described with `gem actiontext` etc...
pmontra 7y ago
Of all the Rails projects I've been working on in the the last 15 years (all of them) probably only two needed rich text editing. One of them is the only Rails project I'm working on now. We're not changing the editor (ckeditor) but I could start a new project with the new default. I wouldn't mind installing it as a separate gem.

freehunter 7y ago

I've been trying to use NodeJS after using Rails for years and it's just such a terrible experience. I don't want to install every basic package by hand and generate every model and view and controller by hand. This is basic boilerplate nonsense that made Rails so popular 15 years ago, and NodeJS throws away every lesson we learned from Rails. React is okay as a front-end but without a full stack framework, the current state of Javascript is like stepping back into 20 year old PHP development, where everyone just hacks together anything they can find with no structure, no convention, and no security.

martinlev 7y ago
Definitely agree with this. I have been switching from developing in ruby into Node 2 years ago as I thought this was "the new thing" for web apps. Now I just want to move away from Node. Large scale Node applications looks like 20 years ago, copy and paste all over the place, cheap libraries, no developer happiness, you have to reinvent the wheels, etc.
- selestify 7y ago
  Why did Node become so popular if this is the case?
  - deleted 7y ago
    [deleted]
  - lbotos 7y ago
    "WebScale" and a generation of programmers that grew up on Javascript thinking it would be cool to write JS on the server too.
  - laumars 7y ago
    Laziness I think. People wanted to use the same language for the backend as the frontend rather than picking their tools based on what does the job the best.
    - 7y ago

aledalgrande 7y ago

The main pain with Node, if you come from outside, is being able to know which modules are well supported, and will be for the years coming. As an example, I spent quite a long time investigating ORM libraries for relational DBs, and the projects that were half dead were the majority. Knex was suggested by everyone, but at that time the project leadership was changing so the future was uncertain. I settled on Sequelize, which had most of the functionality, but several points did not make sense: - the documentation is hard to search - I had to create a PR for sequelize-cli (separate module, that is not recommended for production!) to get the same functionality of `rails db:create` - the syntax was changed to use Op instead of strings for security, in a minor version - the way associations are defined is weird at best - no support for ES6 in the cli, so all migrations are ES5 Etc. And this is just for an API server. I looked into the frontend part and it was so much work. I am still using Node for server processes when I have to, but I wouldn't recommend it over Rails. The way you can generate a simple app that does something useful, configure it and deploy it to Heroku in few hours is unchallenged.

zawerf 7y ago
> know which modules are well supported, and will be for the years coming Doesn't matter if you're coming from outside or not, no one can predict the future. For example winston was probably the most recommended logging library (14k stars) and was a good recommendation at one point. But then they decided to do a rewrite for v3 which introduced a ton of bugs and incompatibilities. I spent several days trying to get it to log in the old format and failed and ended up downgrading back to v2. This is a recurring theme in the js ecosystem (another example is react-router which is just a huge piece of shit and no one should depend on it despite its 37k stars).
- fyfy18 7y ago
  Any suggestions for an alternative to react-router?
  - ybahubali2018 7y ago
    Did you tried Router5( https://router5.js.org/ https://router5.js.org/ ) They have a react version. I experimented with it in one of the small projects i worked on. My experience was positive. Most importantly, it's API is simple and easy to use.

Cort3z 7y ago

Node.js is not equivalent of Rails. Rails is a framework, while Node.js is a runtime. Node.js is equivalent of MRI.

anm89 7y ago
Everybody is aware of this. The point is why would you choose the node ecosystem for any complex task when it forces you to manually solve all of the things Rails does for free. It's insane for a project of any complexity except for very specialized cases. Put another way, you're exactly right, it is apples to oranges, or a better analogy might be a Porsche to a Pontiac. Why would you ever choose the thing which is inferior in almost every way?
- Cort3z 7y ago
  From the comments it does not look like necessary everyone is aware of this. You should have a look at things like adonisjs.com to get a better comparison. I am not saying node-based tech is better or worse, but to dismiss all nodejs server side and say Rails is better at everything is not a healthy attitude, especially regarding the shaky history of the Ruby language itself (eg. The whole RubySpec thing). And; how can node be inferior in every way when it isn't even the same kind of entity? It seems you are barking up the wrong tree. It is a testament to how successful Rails is when it is hard to distinguish it from the programming language it runs on. Congrats to them.

chaostheory 7y ago

Node's main problem is that the only real dominant framework is express, a Sinatra like framework. Other than that there's so many redundant libraries and frameworks, that it's hard not to suffer from the paradox of choice, which eats up a lot of time. It's a bit easier though if you limit yourself to using Typescript based frameworks; less choices.

hrdwdmrbl 7y ago

You're right about Node, but I think it's a bit apples to oranges because they're suited to different use-cases. Rails is great for mostly static sites. Node is great for mostly dynamic sites. It's almost as simple as that.

cutler 7y ago
Whilst Node and Rails certainly have different niches the distinction between static and dynamic sites is lost on me. Both are written in dynamically-typed languages and both produce HTTP responses dynamically. What's the basis of your Rails = static sites assertion?
- hrdwdmrbl 7y ago
  I didn't literally mean static sites ️ By static I mean I site like Github, Craigslist, Wikipedia. Stuff doesn't change often. Uses forms for submitting data. By dynamic I mean sites that make heavy use of ajax, you want real-time anything, high levels of interactivity in the interface. These are often apps.
  - cutler 7y ago
    Rails has an --api option and most of the Rails roles offered by recruiters these days are a combination of Rails and React, Vue or Angular. Rails assets are served with webpack and there are options for React, Vue and Angular when creating a new Rails app.
    - hrdwdmrbl 7y ago
      Yes but Rails is still optimized for REST CRUD apps. It's great at those apps. I use it to develop those kinds of apps. But when you want something super reactive and customized and interactive and dynamic and real-time, I reach for Node.
      - cutler 7y ago

jamil7 7y ago

My two cents is the sweet spot for node is as an auxiliarily tool rather than a whole web app framework. For instance adding some realtime functionality to an existing app, as a server renderer for SPAs or some microservice glue. The community has resisted large rails-like frameworks from the beginning and I think it just shouldn't be used this way.

WhitneyLand 7y ago

There’a an architectural lesson to be learned/recalled here for “hardcore” developers. I didn’t realize that Github ran mostly on Rails until this article and was kind of surprised given the scale of the site and Rails reputation for performance. It’s a great reminder of architecture/design truism: if your site is not inherently performance bottlenecked, then you problably shouldn’t let language or framework performance be the sole deciding factor in choosing or whether to migrate to a platform. Unless we’re talking about >= order of magnitude difference, or a site whose user experience is being limited by performance. Perf and scalability are just one factor. Pragmatism across many factors with perf/scale being one, and making yourself as blind as possible to technology religion, biases, personal investments, and digging beyond simplistic conventional wisdom (rails has perf issues), looks to remain a core ability for making arch decisions. Experience can actually be a negative: I wouldn’t have a problem developing efficiently in node or coming up with an alternative to migrations for example. But what I can or cannot ramp up on quickly the fastest is likely irrelevant and maybe detrimental when considering what’s best for a project as a whole. Seeing comments here about productively gains from specific Rails features, and another comment saying they can’t imagine living without migrations as a built in feature, just seem like great reminders of how important it is to try and avoid making decisions relative to the experience or needs of only one or a few people. It seems like good tech arch decisions need to consider DX issues enough to seem very similar to good UX decisions, the primary contrast being the users have very different stories and requirement scenarios.

ChefboyOG 7y ago

As someone who did their first "serious" web development with Node, but has worked for the last year at a Rails shop, I still love Node for my personal projects, but much prefer Rails for anything that requires collaboration. Ryan Dahl has a speech about his regrets with Node, and most of them center around the way code is managed. IME, the sloppiness to how code is managed in Node, combined with the lack of conventions/dominant Rails-esque framework in the Javascript ecosystem, leads to codebases where no one is sure how or why something is set up the way it is. As annoyed as I sometimes get with Rails' forced conventions or auto-magic abstractions, the beauty is that they are consistent. With a team full of experienced Rails engineers, you can pretty much guarantee that multiple people on your team can explain the "why" behind something quickly. This is a massive productivity save, especially when you're ramping up.

truth_seeker 7y ago

Following are the alternatives :- Action text in RoR <=> DraftJS (Isomorphic ReactJS plugin with server side rendering), Froala (compatible with most of SPA frameworks) Active Record in RoR <=> SequelizeJS (ORM), Slonik(Non-ORM, my recommendation) in NodeJS Action Cable in RoR <=> WS, Socket.io 2.0 (recommended) DraftJS - https://github.com/facebook/draft-js https://github.com/facebook/draft-js Froala - https://www.froala.com/wysiwyg-editor https://www.froala.com/wysiwyg-editor SequelizeJS - https://sequelize.org/master/ https://sequelize.org/master/ Slonik - https://github.com/gajus/slonik https://github.com/gajus/slonik WS - https://github.com/websockets/ws https://github.com/websockets/ws Socket.io - https://socket.io/ https://socket.io/