[ziftface]

The fact is, the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications. Maybe another set of tools would have been better, but that doesn't really matter. This set of tools is what everyone uses, and a lot of effort and creativity goes into making js frontend development as smooth and fast as possible.

I often need to very quickly make internal services at my job and while I like working in other languages (and i do for longer term projects), those always take longer to set up and get working. In js with next you're up and running in less than 60 seconds and if you're doing crud stuff, most of the work is frankly done for you.

[ratww]

I disagree.

Rails was already faster for CRUD apps back in the mid-2000s. Batteries included, maybe a gem or two for an admin panel or for auth. Not that it matters, but rails new is probably faster than 60 seconds too. Django is pretty good too.

ASP.NET Webforms was made for CRUD, and it even provided a WYSIWG designer back in the early 2000s. And it was just a matter of launching Visual Studio and creating a new project. Again, doesn't matter, but it was/is way less than 60 seconds, and a lot less fiddling. Webforms got an MVC version a few years later if you prefer that. And they haven't stopped: Blazor is new-ish and very productive, and runs both in the backend and in the frontend (using WASM).

Both Rails and Microsoft tech also give you a backend, which you're not putting into your equation. Sure you can have a Backend in JS but the experience it's nowhere near as ergonomic or as fast as using Rails or ASP.NET.

Sure, if you're comparing with building an app in Xcode or Android Studio then JS tooling is faster to use. But if you compare to what people were using to build CRUD for the last 20 years then JS is not really special. For interactive frontend apps? Then it's a different discussion. But for CRUD, modern JS is not that special.

[ziftface]

I can't really speak to all the technologies you mentioned, but some of the other apps I maintain are in python using django. It is also "batteries included", and does give you more tools out of the box for backend work. It's actually really nice to work with and maintain in my opinion.

I would say though, that for very quickly creating new applications that get the job done, js has been the fastest for me. And while django and similar give you more database stuff to work with, honestly that feels like a solved problem, and it's often easier to not have to do any backend work at all, and instead use something like hasura. And next does include backend code too for functions that you need to write for the backend.

Obviously, this isn't ideal for a lot of problems. I think if you can get away with it, you can be really productive. I've made crud apps for work with this stack in very little time.

[ccanassa]

It's unbeliable how many things Django gets right out-the-box. I am talking about things like i18n and i13n which are usually are afterthought for most of these frontend frameworks but Django already includes a amazing system for it.

[Aeolun]

You cannot compare those though. Rails is entirely different from plain Ruby. If you want to compare you need to take something like NestJS, which approaches Django in immediate useability.

[SulfurHexaFluri]

Rails is an excellent choice for the backend but on the frontend its much less productive than react. Most rails apps these days would use rails as an api backend and react on the frontend.

[ratww]

It really depends what for. For CRUD apps or static content, Rails still has an edge. For something else, like rich apps? Sure, JS beats it.

[com2kid]

> and if you're doing crud stuff, most of the work is frankly done for you.

React sucks for large complex forms unless you pair it with another technology or two.

Want to write a crud app fast? C# and Winforms.

Couple years back, I once did a prototype of a web app in C# and Winforms connected to Firebase. Less than a day, done.

Month later, had it working in React. Granted the React website looked nice, but the difference in efficiency is huge.

Data binding 20 fields on C# is a matter of minutes. Data binding 20 fields in React, and with Redux, ugh. I really should have just learned Redux Forms.

And for any given forms library in React, you then get to practice learning how to beat it into shape and style it how you want.

I, no kidding, think writing CRUD apps was easier with VB6 and Microsoft Access.

[ziftface]

That's really interesting, I should look into that pattern, maybe it can be applied elsewhere (I have to maintain a vb6 application at work, and I'm not terribly interested in doing that anymore).

Yeah working with redux sucks in general imo, I try to avoid it when I can. If I can get away with it, I try to avoid the problem entirely by using hasura as a backend. But sometimes that's not viable.

[com2kid]

> That's really interesting, I should look into that pattern, maybe it can be applied elsewhere (I have to maintain a vb6 application at work, and I'm not terribly interested in doing that anymore).

I hadn't used C# for years, I was shocked that the winforms designer duct taped to a community contributed Firebase library, was able to get a prototype out in hours.

I had been using JS for 2 years at that point. I estimate at 10x-15x productivity boost in C# over JS.

The C# tooling is just that good.

Now if I'd been trying to learn XAML or something at the same time, eh, probably wouldn't have gone as well.

Of course the downside here is that a Winforms app is hard to distribute, and usable only on Windows desktops.

The react web app was, well, beautiful, and usable everywhere.

But I could have written the C# app once for every platform I care about and still been better off.

Ugh, I am sad that Winforms is only ever going to be Win32 based.

[midrus]

I'm interested in knowing how you get to do "crud stuff" so fast with Next.js

- How do you do validations?

- How do you handle database migrations?

- How do you handle background jobs?

- How do you handle authentication?

- How do you handle authorization?

- How do you handle file uploads (to filesystem or S3)?

- What ORM or database toolkit do you use for queries?

- How do you send emails?

- How do you do websockets/real time?

All of these of course have answers, but each one of these comes with a lot of "decision fatigue", discussions, maintenance work and I highly doubt the cost of reaching the same level of robustness of a full stack framework is any smaller.

Real life production "CRUD stuff" is not just some http handler doing sql inserts into sqlite. There's a lot more involved. That's what Rails/Django/Symfony give you a solution for. I agree Next.js could have a faster startup for a landing page. But as soon as you need the most minimal backend, you are way, way, way further to get something robust working if not using one of the full stack frameworks.

[michaelpb]

This is just a personal preference. I would say the same about Python / Django: You get extensible login/signup/password-reset/etc authentication & user-permissions management, and even an admin interface with user groups, right out of the box. I can put together a web app in "60 seconds" that would take weeks to assemble using the JavaScript ecosystem. Having taught classes on both, I'd also say it's also easier for beginners. Again, might be my own bias or other factors, but it seemed to me that the Python/Django student's final projects have on average "out-shown" the JavaScript SPA student's final projects in terms of features that they had time to complete.

This isn't to hate on JS, this is just to acknowledge that other languages and frameworks have substantial advantages in many use-cases.

[scrollaway]

Django's user system is .. limited. You need a bunch of third party libraries to add very commonly used things such as auth APIs, oauth, 2fa, etc.

I've worked with Django for over a decade and i dislike it more and more. It hasn't evolved to match the environment around it and how to best use it. Typing is missing. Something like FastAPI is very promising but Django's admin is still superb for prototyping and its orm is a lot more instinctive so i put off switching away ...

[michaelpb]

Agreed, it definitely is limited. Also the admin panel is limited too, and although it's very extendable, the admin extension API is kind of clunky and inconsistent at times. Yeah FastAPI looks great! I've used Sanic in the past and FastAPI seems cool for some of the same reasons. I'm also following closely Django Hotwire - https://hotwire.dev/

I only brought up Django in a narrow context to challenge an assumption made by the post I was replying to, that seemed to imply that JavaScript ecosystem is indisputably the fastest for rapid prototyping. Hence my providing of a counter-example. I think this is especially true for new coders, as having certain things out of the way is super vital to keep motivated when building MVPs -- I've seen many students give up on ideas simply because implementing authentication with a Node.js-based stack was too challenging, when they would have been happily coding away had we been teaching a batteries-included framework (django / rails / etc).

[ziftface]

Funny you should mention that, I'm watching that too, and I can't wait until that's to the point where it's just as easy and seamless to get something up and running in django or a similar framework, while also having all the advantages of a frontend application and a backend one. Hotwire does look very intriguing to me.

I think overall we need a new wave of backend frameworks with what we've learned in the past decade. I'm hoping it's in python or clojure, but my guess is it's going to be in javascript (see react server components for one potential contender).

[scrollaway]

I've been in the NextJS world lately and it's honestly gotten really good. Nowhere near perfect yet but they are clearly on the right track and it's already more than usable.

NextJS+Django is my current stack of choice.

[b0rsuk]

Last time I hanged around #django, they said admin pages are for prototyping and technical admins only. Admin is not meant to be extensible. For true power without issues, you should roll your own CRUD views. Django has features which make it easier, such as viewsets.

[apitman]

The cost of developing in JS isn't necessarily lower, just amortized. Or in many cases, externalized to your users.

[ziftface]

> externalized to your users

You mean if you have customers with less powerful devices like the OP? I don't really see internal services or B2B products having that problem.

[apitman]

You original point

> the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications

Didn't hinge on whether you were creating internal tools or not. You simply used internal tools as an example of what you personally do with JS.

[ziftface]

I see your point, and I agree it's definitely not a good solution to some problems. But I think it can be very productive if your constraints allow you to use it.

[smaudet]

That would be fine if the attitude were 'best tool for the job'...

Often there is the people element to tech though - that isn't the attitude, normally optics is your tech wiz kid is doing something cool with (metaphor) peanut butter sandwiches, lets build our next office complex with peanut butter sandwiches. Architecture? What's that. Move fast, break things, eat lots of sandwiches.

[b0rsuk]

Javascript is as privileged as programming languages get. It's welded into all web browsers except perhaps Lynx. To get traction, an alternative language would need to be simultaneously included in several browsers. Good luck with that.

[tobyhinloopen]

Only webassembly can save us