Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In JS there is a lot of convention but on a micro level. The times of monolithic Rails apps which have strict conventions are over and it's good: Too much magic and strict conventions often forced devs into patterns which didn't match the use case. Even experienced Rails devs tried to solve every problem the same way.

You also confusing matters. You need Webpack, Babel etc for the frontend not the backend. And even in the frontend it got abstracted away by things like creat-react-app. So you shouldn't them see them too often.



First, Webpack and Babel are totally used for backend. If you look at a lot of Node libraries, they use ES6 modules in their [docs](https://github.com/graphql/graphql-js). While you could use mjs for this, it's still experimental.

I do think create-react-app is a good innovation in the JS world. However, I've never found a good equivalent on the back end. Setting up even the most basic CRUD REST API requires a whole lot of typing for very little reward.

As for convention, I think JS could do with more of it. I find that when I talk about adding more convention, people take it quite literally as "we need to reinvent Rails in JS". That's not at all what I mean. Convention can be something as simple as Rack, which is a consistent, useful interface between servers. Convention does not and is not tied to monoliths or MVC or any other aspect of Rails.


> I do think create-react-app is a good innovation in the JS world. However, I've never found a good equivalent on the back end. Setting up even the most basic CRUD REST API requires a whole lot of typing for very little reward.

This is where services like Google Firebase Functions become useful.

I went from having never written a REST API in my life, to up and running in under 20 minutes.

First time I went to create some endpoints on my own server, wow, that was a pain.


Firebase is a dream. It's almost a shame they got bought by Google because it's such a fantastic idea. All of the things I used to dread setting up (auth, deployment, serverless) are automated and dead easy. The documentation is clear and caters to the common usecases. I managed to set up a Sendgrid email that sends on database writes within an hour or two.


> The documentation is clear and caters to the common usecases.

I wouldn't quite say that, but I'll agree with your other points. :)

(More than once the docs have been out of date, or just flat out wrong, costing me many hours of development time...)


JS is so good for APIS because of its dynamic JS objects. If you then take also a document storage you don't need any ORM anymore and write your entire API in 5 mins. Rails was a nightmare compared. JS lets you do stuff yourself. You don't any framework holding your hand. Maybe that's your problem.


In what world you think the usability of a language is determined by being able to get a Restful API up in 5 minutes?

Yeah, document storage for business-critical data. I'll pass. There's a reason important data gets stored in Postgres.


Simply not true. Rails continues to be the choice for many companies who don't base tech choices on what the latest bandwagon is.

JS is mess.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: