juliendc

FYI there is a typo in the CTAs. It should be "Request Availability" instead of "Request Availibility". I'd fix that because it doesn't look very professional. Otherwise the concept is nice, makes a lot of sense.

A very respected developer in my previous company once told me: "make the change easy, then make the easy change". I guess everybody has already heard it because it's kind of a famous quote but it has really changed the way I develop since then. Every times there is something I need to implement and I feel like the codebase "resists" it, I think about this quote. I then take the necessary time to make this change easy first.

Found a link to a tweet, which looks like the original source (not sure though): https://twitter.com/KentBeck/status/250733358307500032

They are following the trends of flat design and rounded corners, which I don’t really mind. I’m more bothered by the fact that nothing is aligned: the GitHub logo, the breadcrumb, the horizontal menu and the issue title are all on different verticals. Looks messy.

I built this because I didn't find any good quality library of resources for product managers. Usually it's a simple list with just a few informations. I've put all those resources in categories such as books, apps or podcasts but also by topics like interviews, prototyping etc. I've also added metadata to each items like the price for courses or the read time for articles. Tell me what you think.

Yes I totally agree with you, it's not a fair comparaison.

My point was indeed that there is no real Rails equivalent in the Node ecosystem. Something mature which is supported by a large community over many years. Django, Spring Boot, Laravel, Phoenix play such a role in each of their language.

In Node you have to come with your own set of libraries, structure and convention, which is not the most efficient way to start and maintain a project. I agree that more senior programmers might avoid most of the common mistakes, but still you might spend time discussing little details such as structure and conventions. Frameworks such as Rails make at least some of those discussions irrelevant and allow you to quickly move on.

I can totally relate on this.

In the end I think Rails and Node have different purposes. I would still use Node for proxy-style servers. Something with a small and focused scope which has to scale.

For business intensive apps with a large scope, Rails-like frameworks are still way more productive and robust even if they are less trendy for the moment.

The current frontend state is another story indeed. Frameworks like Ember tried to bring the same Rails-like structure to the frontend world but it isn't as popular and trendy as React for whatever reason. I think it's very costly for frontend teams to reinvent a coherent structure, convention etc for every new project. At least React has brought the same way of thinking in the frontend industry.

I've recently built a Node server with TypeScript and it's a joy to use with external libraries when the types are available. It's such a time saver to not have to guess which method to call with which arguments (I've had only experience with dynamic languages before). Some libraries don't have types or they are outdated but it was a minority.

With the experience I've found that most of the type errors are actually between the backend and the frontend in web applications. It's still hard to fully type the entire flow from the database calls with the ORM to the objects manipulation in the frontend.

How are you dealing with that? We used Nexus with GraphQL but it was still a bit cumbersome.

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!