As the commenters pointed out, Express.js doesn't try to solve the same problems as Rails. Trying to use one for the other's use case doesn't make any sense.
Yes, but the problem is that there's still nothing in the node ecosystem that's as complete as Rails. Fine, express.js isn't going to do the job. Neither is anything else.
Python is plenty popular and so is C#, and when you're looking at a batteries included full stack framework you have ONE popular choices - Django or .NET. For PHP it's Laravel (sure, you have other options like Symfony but they are niche), for Elixir its Phoenix.
How is it a good thing for Node to have 5-10 competing frameworks that have similar adoption?
> How is it a good thing for Node to have 5-10 competing frameworks that have similar adoption?
How is it a bad thing? Again, JavaScript is far more popular than all of those for web related development. The issue is that like you're stating, there isn't a single main option perse. I'd use NestJS.
I think its generally bad, or at least I wouldn't want no part of it. There's decision fatigue for one - how the hell do you decide what to use.
Another problem is why would I want to relearn a new framework every time I switched companies? And how do I know these frameworks are going to survive long term in such a chaotic community?
I have little doubts Django or Rails will be here in 10 years, can you be confident all these JS frameworks will still be here? Some will and some will probably become irrelevant.
Yes Next, Nest, Sails, Gatsby, Blitz, Redwood - none of them became a leading framework like Django or Rails or Laravel has, which means being a Node developer and moving between companies or projects you'll probably relearn everything in a different framework.
For me this is just to chaotic and unstable.
I see no difference. PHP has a billion FWs and a billion more CMSs. Python is the same way. Rails is the only example you give that has merit. I mean PHP is a terrible example. I've been coding PHP since around 2007, PHP has Zend FW, Laravel, Cake, Ignitor, Symphony, Silex... it keeps going and going. All I can see from your comment is some biases against JS. You do you on what you want to learn or use. But its not really an argument that holds up imo.
Laravel is the leading PHP framework by far, I don't think it's up for debate. Ruby also has many frameworks (Padrino, Hanami) but it's obvious Rails is the common choice.
Laravel is as much of a leading framework as React/NextJS are the leading frameworks for JS(next 2.5 million weekly downloads on npm, react 15 million). Its almost a 1:1 comparison. In the same way that I already pointed out JS like php, has a million fw but insiders know what the leading ones are. Everyone knows React is the clear on top winner. NextJS is also a clear on top FW. I dont think its up for debate at this point.
Yes, and in the Ruby world we also have Sinatra, but notably, people have tried and failed to get Rails-like frameworks up and running in JavaScript (Sails.js, others). The question is whether the problem is the language or the community -- I think it's a bit of both.
I mean, there have been plenty of valid arguments against PHP the language and its standard library, but the big issue most people end up having have to do with its ecosystem, developers, and frameworks. My earliest rants about PHP was the sheer volume of bad tutorials; googling for "php sql" or whatever would invariably give you examples susceptible to SQL injection. And the other issue was that everyone was building frameworks, CMSes and forum software left right and center; there were a lot of islands, each with their own ideas, structures, etc.
PHP should have made a much bigger push early on; mark the weird and unsafe functions as deprecated and point to e.g. prepared statement alternatives. They should have built a package / dependency manager much earlier on. And they should have made a lot more efforts to get a developer community up and running.
If you're actually interested in the subject, a good way to familiarize yourself with the current state of PHP is to run through something like https://laracasts.com/series/laravel-8-from-scratch. It should give you a good idea of the current state of PHP, what educational resources look like, along with a taste of the most popular PHP framework out there.
These conversations always tend to go the same way; someone complains about PHP and then later admits it's based on their experience 5-10+ years ago. PHP has come a long way and is worth checking out if you're into web development.
Sure, community interest peaked around 2014, but usage among enterprise and startups is higher now than it ever was. Ruby is boring now because it works.
If you want typing in Rails, you're in reality itching to try Crystal lang and most likely Amber framework. Much faster too as it's a systems language.
I’m itching to try Crystal, since it has goroutines aka. greenthreads aka. fibers for easy concurrency, static types, automatic null checking, and performance on par with Golang.
But Crystal has around 468 open bugs at the time of writing :(
I did run a startup for a year that was on crystal, and I will say the community is quite good at addressing real bugs. There are a lot of "you don't know what you're doing" bugs and "this is already fixed but you haven't updated" bugs and "this is really a feature request" bugs in the tracker. I wouldn't read into it much. There hardly exists a popular programming language or framework without at least several thousand open issues.
I recall that when Active Storage was publicly announced[0], Laravel's Filesystem (itself a thin layer over Flysystem) had already been out for at least 2 years[1].
I came here to say that, as someone who's used both Rails and Laravel.
Basically it comes down to magical behavior, and the fact that Rails has way too much of it. Syntactic sugar and DSLs are maybe fine for rolling out new projects, but become burdensome on large codebases. I was on a large project and found myself in goto hell where I literally couldn't trace through the code. It was relying on every magic trick in the book to make the code as small and cute as possible, but failed utterly to provide anchors in the code where "this happens here" or breadcrumbs connecting chunks of code. It was a giant hodgepodge of I don't know what. Really clean spaghetti code I guess.
Now, Laravel has its own warts, but they aren't conceptual warts. For example, the stack traces in Laravel are way too tall, with way too many factories and patterns in the vendor code. I feel that things like the IoC container were not implemented as well as they should be. The goto hell in Laravel happens around stuff like the bootstrap process, registering service providers, queuing, etc. They made some mistakes in scattering those things around instead of handling them in one central place. Pretty much all classes provide 95% of what you need, but adding missing functionality yourself requires learning the entirety of the package (in fairness, this happens with pretty much all platforms). There's a tendency for Laravel projects to not support helper functions or custom classes in a standardized way, so sometimes it's hard to find business logic. Not nearly as hard as in Rails though. But as a whole, I'd take conceptually clean interfaces with mundane implementations and no surprises over magical behavior any day.
Just to not leave anyone out - I wouldn't implement business logic in any Javascript framework. I feel that async basically makes it impossible to do it deterministically. I'm sorry that happened to Javascript and am still in mourning about it, because it had some advantages over PHP in how it treated associative array access with "[]" the same way as object member access with "." which could have been used in PHP to implement copy-on-write everywhere and really set it apart from all other imperative languages. Mistakes were made in both, and Ruby as well, that took them all in directions that I wouldn't have chosen.
You know, I wrote up a long response about what strikes me as a good framework, but realized that the core of it is that a conceptually correct approach may not need a framework:
Today I mostly write solutions in a synchronous-blocking, functional-reactive, event-driven, immutable, stateless, data-driven, declarative manner that tries to avoid custom types/objects, manually managing nulls or asynchronous behavior. Which if all orchestrated correctly, leads to future-proof code because it's so obvious that it's self-documenting and the failure modes are all safe.
IMHO, the vast majority of software out there involving Javascript, Ruby, Python, really any of the imperative languages, can't achieve what I'm trying to do. It even feels like they actively work against me sometimes. I think of Laravel as getting most of the interfaces and approaches conceptually correct, even if the internals use factories and patterns and hand waving that I consider spaghetti. Whereas Rails involves some element of drinking the kool-aid, because it encourages some conceptually incorrect approaches like ignoring process separation to achieve better performance or fit with some preexisting notion of what's beautiful or easy. Along those lines, probably stuff like Phoenix/Elixer, Erlang, etc are closest to what I'm working towards, but they introduce their own custom syntax that strikes me as perhaps too DSL-like and I have an aversion to that. Which is the main reason why I struggle to learn stuff like Haskell.
There truly are vanishly few actually good solutions today, and I've been following web development for over 25 years now. That used to really get me down. But I realize now that the situation presents an opportunity to fix things and build a better future, which I am grateful for.
I had similar feelings with Rails. Just memorize this billion convention and you are good to go. Also didn't help that running Rails on Windows was (maybe still is) considered a bad idea.
I don't know for rails, but whatever dev I do on my Windows machine I just do it via VSCode in WSL2. Or I ssh into my dev machine (shared hosting via uberspace).
I haven't even tried to setup dev environments for python, php or js on Windows. It is just so easy to use WSL2.
Same here. Inherited a huge rails code base and it's as bad as any node project. The autoloading has been enabled in the entire project so I have no clue whether a class is defined within the project or is fetched from a gem. I've never grepped this much in my life
I've used Laravel and agree that PHP isn't all bad and can be used intelligently. And this is coming from a former CodeIgniter core dev (if you recall). But being real, you've got to admit that most PHP projects aren't in Laravel, they're batshit spaghetti code continually reinventing (or outright ignoring) the standard patterns that come in a boilerplate rails projects.
That probably has more to do with PHP being such an easy language to get started with, inviting a lot of rookies/cowboys to the party.
I don't understand the comparisons presented in the article. Comparing a full stack MVC framework to a front end library is as apples to oranges as it gets. IMHO frameworks such as NestJS and Adonis are more comparable to Ruby on Rails.
I think you don't want to support the article's claims, but you kind of support it by mentionning the choice that you need to make between NestJS and Adonis or any other frameworks. With the ruby ecosystem, there is almost always a clear convention on what to do (example: the conventional choice
is to use rails, which leads to a bunch of pre-made choices)
Conventional choice at a framework level isn't really necessary though, is it?
I mean, you can read and choose what you like whether it's Nest/Adonis/Blitz or anything else. Once that choice is made everything that follows is opinionated.
Part of the problem I think is that none of the JS frameworks became a clear winner in the full stack batteries included framework niche. For Ruby the clear winner is Rails. For Python it's Django. For C# it's .NET.
What is it for Node then - I keep getting many names - Nest/Next/Adonis/Blitz/Sails? And lately Redwood? And probably more I'm missing out?
It would have been better for Node if there were 1-2 frameworks with huge momentum behind them then 6-8 frameworks that none of them caught a lot of mindshare.
So long as that is in fact the point of the article, I agree completely. However I'd still have to point out that comparing the Rails framework to solutions which do not try to fill the same role such as React made for a confusing article.
I used to write Rails professionally for many years
This comparison isn't a good one. Rails is an all-encompasing framework.
If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have.
---
EDIT: To clarify (because it is confusingly named), NestJS is a framework modeled after Spring Boot for TypeScript + Node:
I should've been more clearer. This post isn't comparing Rails to any framework out there.
What I was trying to say is that Rails got a lot of things right and it's making me productive, because I don't have to make the same decisions over and over again when making a JS app. Rails made those decisions for me and the only thing left for me is to build my app.
I myself like Next.js and Remix a lot, but they still leave you to spend time making basic decisions, like how to organize your project or how to implement background jobs.
That's why I'd love to see more conventions and less configuration in the JS land.
> I'd love to see more conventions and less configuration in the JS land.
Which is what the parent post is saying NestJS offers. I'm not familiar with it, so can't comment on the veracity of that claim, but I think you might have missed their point, perhaps because they confusingly called it "Nest.js" which could be mistaken for "Next.js".
You could compare Red Delicious to Granny Smith and a programmer will come along and say it's an unrelated variety. The problem is even if you want to use a larger library/framework, there are over ten thousand to choose from. The JS ecosystem is built upon the Unix philosophy of "Do one thing and do it well." So there is a reason React is not a framework and that is not your fault. If you do not use a Rails copycat, you are left with many decisions for packages. Nobody has time for that so everyone just uses what is most popular. So the comparison is fair, it's just a comparison between philosophies.
The point here is that you do not have to think about choices, there is a "rails way" for every problem. There is no such thing as "the node way". They are hundreds of ways, some of them are dead ends.
And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals.
If it turns out your goals are a very simple crud app for a team of under 5 - Rails is probably a great choice.
For most everything else, you should probably understand why Rails made the choices they did, and what the trade-offs are. (ex: I would argue that the author is making a HUGE mistake by not just immediately outsourcing auth to something like a self-hosted Keycloak instance, or Okta/Auth0 - but my needs require enterprise auth support (SAML, OIDC, Provider support, etc) and maybe his don't)
But the thing is... there are TONS of simple CRUD app frameworks out there. Rails is a good one, but so is NestJS, or ASP.net Core. There's at least one "Opinionated" CRUD framework for almost every language.
Rails is still good, but I find it has a distinct "ASP.net classic" feel to it now - Too many versions, too much change, too many contradicting "opinions" between major versions.
> And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals.
That comes with a downside though, which is that for any given problem there won’t necessarily be an ultra-well-supported “happy path” where every conceivable problem has long been documented along with a solution.
To me the lack of happy paths can be a problem. It’s something that is often encountered with Android development because Google can’t make up its mind and it’s very frustrating — usually your choices are between 5 different APIs that suck in different ways, meaning you have to pick the one that sucks in a way you think you can deal with best. It’s a significant damper on both velocity and motivation.
It also comes with more debugging in the node world. Since everybody is doing things differently and the packages you install are usually poorly tested (or not at all), you very encounter shortcomings.
If you're just doing something so simple that "every conceivable problem has long been documented along with a solution." then you're using the wrong tool if you're programming anything at all.
Problems that fall into that space are usually better served by simple site builders (Wix/Square/Shopify/Wordpress/etc).
> Too many versions, too much change, too many contradicting "opinions" between major versions
Tell us you haven't used Rails much without telling us you haven't used Rails much. There's been precious little I've needed to change in my approach since the 3.x days. The new TurboJS world they're baking into 7 sounds significant though.
> Rails is still good, but I find it has a distinct "ASP.net classic" feel to it now - Too many versions, too much change,
Well Rails is gonna celebrate 20 in 2 years, so yes there's quite a lot of versions and changes over the years, that's inevitable for every long running project I think.
I think the main Thing here is that Rails is the de facto standard, the 'golden hammer' of Ruby based apps, and there is no space - or developers - for alternatives.
The JS ecosystem as we know it today started years after Rails (Rails was 2004, Node's oldest version on their releases page is from 2011), and only really took off after NodeJS came to prominence with frameworks like BackboneJS, Angular, then React and the rest in the early 2010's, and it went along with Github and the emergence of everyone and their dog building libraries and frameworks.
The attitude was different; instead of big opinionated but inflexible frameworks, people wanted to pick and choose. This was exacerbated by React that emphasized NOT being a framework but just a rendering layer.
Pick ANY one-size-fits-all framework in the JS space and you will see "bad" decisions that people don't like.
The closest thing to a full JS framework at the moment is probably Angular, which feels bloated and overly complicated (annotations, component / folder structure / file naming) or Express (stringly typed? I haven't looked at it in forever).
The dominance of Rails for its use case within the field of Ruby is is only one half of the equation. The other half is that Ruby has mostly collapsed into Rails, there's not much Ruby happening outside of Rails. This could never happen with a js framework of similarly scope, because all the other js use cases won't go away. One example of such a thing that won't go away is doing client-side stuff in the scope of a Rails protect. JS would have to lose a lot before it could achieve similar focus.
Rails has a clear one way to do things because there are no/few other options because everything else has withered away.
To put this another way: to have a convention in JS, just pick a convention, and now at least you have a convention, even if everyone else has their own.
As someone who has used Ruby as my main language at a number of companies for the last 17 years and deeply dislike Rails and rarely use it, I couldn't disagree more.
Rails draws the attention, but there's plenty other uses.
That's interesting to hear, I would have guessed that Python had long won everything that could be ruby but isn't rails. Clearly, nothing will stop the inertia of someone who just happens to be productive through experience (you can probably find works-for-me wizards for almost anything, perhaps not for vba or ada but I wouldn't bet on it).
Is there much happening in terms of libraries outside the rails scope or is it more a case of one less thing to worry about once you've become good with the batteries included?
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!)
I rarely find an area where I've needed libraries and there haven't been decent stuff available in Ruby other than when doing quite esotheric stuff (e.g. there's no good low level X11 client implementation for doing raw X11 stuff). Often multiple competing projects.
E.g. for ORMs ActiveRecord which is Rails default is in my opinions nowhere near good enough compared to e.g. Sequel, and there are several others.
Sometimes those projects involve wrapping stuff - including Python - or porting Python, but most of what I use is pure Ruby.
With respect to Python, to a lot of the Ruby community Python is in many ways the antithesis of what we want in a language. Python looks horrendous to me. It matters - I stare at code most of my day. If I were to switch languages, Python wouldn't make the shortlist even. It's not that I think Python is objectively worse, but subjectively to me it's unreadable and messy and I can afford to avoid using it most of the time.
EDIT: To expand on some of what I use or have used Ruby for: web dev with Sinatra and Padrino (my main reason for avoiding Rails here is that most of what I do is mostly API driven, and because I prefer Sequel as the ORM), financial modelling (I work for a VC), my text editor of the last few years is written in Ruby (but not packaged up to be useful for others yet - I'm gradually splitting parts of it out into gems, though), DevOps by generating terraform, service orchestration (proprietary pre-Kubernetes orchestration of containers and vms across on-prem, colocated, managed servers and VPSs split between openvz, docker and KVM), system to auto-deploy replicated sets of Postgres servers with logs and backup dumps automatically distributed to a Ruby storage service (pre-RDS, and running on the aforementioned orchestrator), PDF generation, messaging middleware, scraping, large scale crawlers, trading bots. And many more.
Ruby is a wonderful language for other things outside of Rails. I'm old. I've done csh, bash, perl, tcl, and python for scripting and miscellaneous programs. Since discovering Rails, I use Ruby for basically everything now. The only miss I've had in recent memory has been needing to do heavy statistical work with R for speed reasons, but, then, you're not going to do that in JS (or anything else) either.
It always gets me abit, angular is called bloated however all the react/vue applications i have worked with have been bloated by shitty packages left and right to fix problems that never existed in angular, im probably just to old or what not but i dont find the configuration bad since you can always figure out what went wrong, that is not the case on react/vue unfortuenately, it ends up being very opinionated by the last dev that took charge, and the endless refactors of architecture because now there is a new way of doing it..
> The attitude was different; instead of big opinionated but inflexible frameworks, people wanted to pick and choose.
I enjoy working with Node and JS, but this IMO is what contributed to the fragmented node ecosystem where you have 100 different npm libraries that do the same thing and reinventing the wheel is rampant
Arrghh... This week was the first in years where I didn't FOMO. And here comes Nest.js.
I desperately need an ad blocker though for shiny new tech thingies.
Interesting, why is Nestjs used by so many online casinos? Is that random or is there some specific feature or approach used that is particularly valuable for that use case?
Online casinos have usually been very aggressively sponsoring anything and anyone willing to take their money (and the usual reputation hit that can come with the perceived shadiness of gambling). That's especially true for newcomers who just burn as much money as they can, trying to establish a foothold. I'd say, being on the front page of a popular, credible project like that is probably sought after, hence the unusual amount of casino sponsorships
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.
I think the author went too deep into details here, as this crowd is full of people who are going to be able to rip pieces of this article to shreds. But doing so both misses the larger point and in the process proves it - Rails gave them a set of answers that are good enough so they don't need to delve deeper and can just focus on their app.
Rails is not the only choice that does so. And people with broader skill sets can assemble their own solutions and might not want that anyway. But this author just wanted to pick a platform and move on, and yep, Rails works for that.
> I think the author went too deep into details here, as this crowd is full of people who are going to be able to rip pieces of this article to shreds.
No doubt here! I know there's a lot of nitpicking, but that's just my experience so far. I wanted to make it clear by removing all "we" or "you" words from the post to make sure I'm not saying my opinion is the definitively right one :)
> Rails is not the only choice that does so.
Absolutely, the only two reasons I went with Rails is because Ruby looks beautiful to me and I was following the news in Rails world for years.
Sure. And I think what makes Rails and Django shine is they have sound default answers.
I’ve yet to see anything in Node that feels like a stable 1:1 replacement. Next.js is excellent, but you still need to sort out a lot of pieces on your own.
Recently I’ve also been impressed with Remix that was mentioned in the article. It seems to have solved the client server code duplication problem while still offering the benefits of both.
As others have pointed in this thread, there's NestJS, Sails.js and AdonisJS, which are closer to Rails than Express or Next.js. And there's Meteor too, like the sibling post mentioned.
But to be fair 99% of JS backends I see are using Express (or AWS Lambda). Considering there's lots of choices I wonder if the problem is the fact the community never focused on a single solution. I wonder if a Merb/Rails-style merge between some of them would help that.
I'm working on two inherited Django web apps right now, for the same customer. I wish Django has a default project structure like Rails. It doesn't. The only common ground between the two apps is that they are written in Python, use the same ORM and templating engine. One is a spaghetti monster of a zillion of apps that depend on each other (so the separation in apps is useless) and the database is totally opaque to inspection. The other app luckily tucked nearly everything inside a single app so its saner to navigate and we can query the database with SQL tools.
The point is that Django lacks a sane default for project structure and it costs time/money to people using it.
That's not accurate. Djano encourages, but does not mandate, a particular structure. Incompetent developers will always find a way to subvert whatever sensible defaults are at hand, which is the case you are faced with.
I have not had as much of a problem with structuring django projects. I agree there could be better documentation recommending best practices.
There is a very good talk from Dan Palmer from Djangocon 2021 called "Scaling Django to 500 apps" that gives helpful advice for project layout in a django app that may only have a few or several apps:
That said, if we're going to dig on Django, it lacks typing, core-based API patterns and any embrace of modern front end. There are positive signals though, releases are coming faster and there is some real talent on the tech board right now.
I do think django and python in general are in a defensive position to hold the future of backend webdev compared to node / deno. However, there's still plenty of opportunity to compete for developers.
> I’ve yet to see anything in Node that feels like a stable 1:1 replacement
I’m not sure why there should be; for people who are happy with “good enough” default choices for a web app, Rails exists and makes the choice “Ruby” when it comes to language.
I've never used Next.js so I decided to take a look. The first step in their Getting Started guide illustrates this pretty well...
npx create-next-app@latest
# or
yarn create next-app
I would choose npx while my friend would choose yarn but there isn't a default or even an indication of why you might like either choice. We kinda just assume everyone already has a preference for npx or yarn.
This is really a Node or JavaScript problem and not an Next.js problem. Not that I have any idea how you might solve it. This is also just a single example and we tend to have these decisions at a lot of steps along the way.
Definitely some exciting stuff like Redwood and Wasp working to solve these problems. I always loved what Meteor tried to do for this, though the JS ecosystem sort of evolved in a different direction.
Do most people use Django as a server-side framework (no frontend-JS or very minimal JS, may be jQuery)? Or, is it mostly used as an API to interact with the React/Angular/etc front-end framework? What I am trying to get at is do people still build POST-redirect-GET patterns and such for form submissions or they use Django in a more 'modern' way?
You can use either or both... server-side comes out of the box, and is used by the getting started tutorial. API-based is also very common using django-rest-framework.
I'd say it is still a mix of both and both paths are well-supported and well-maintained.
From my recent foray into modern Django world, most simple projects and MVP start out as server side like the official guide. Then, when people need some extra frontend magic like React and/or SPA, it's pretty easy to insert into Django. You just include the bundled React/Vue app into a js script still included and served by the same Django route/view/template. Of course, it's also common to start transitioning to Django Rest Framework (DRF) as your API points.
Rails does, but Ruby is so close to Python and Python has the numerical crowd so you're eventually going to need it anyway if you're successful.
I know it sucks, because Rails is better than Django, but at the end of the day I love Ruby but my day job is Python. Also, even though I can never remember capitalization, underscores , pluralization, interfaces in Python[0] at least I don't have to think when I type `and` and at least strings aren't mutable by default and when I need the data science it's right there waiting for me.
[0] lol "".startwith, "".starts_with, start_with(""), etc. In Ruby it's Time.now, come on people.
Ruby's not as consistent as you think. I can pull single examples out too -- is it 1.upto or 1.up_to? And I've never had a problem with Python's pluralization.
> In Ruby it's Time.now, come on people.
YMMV, but I don't find it terribly burdensome to import datetime and call datetime.now().
Because is it datetime.datetime.now? or date_time.date_time.now? or datetime.Datetime.now? Or datetime.DateTime.now? Or DateTime.now? or dt.datetime.now?
Because it could be any of those. Some people import datetime like numpy (import numpy as np) so they can call timedelta like dt.timedelta and this is fine and everything, but the combination of no standard in python for how to do this, plus the hard to remember interfaces, plus the multiple libraries that try to do the same thing and the different way they differ in capitalization, etc. Means there is just way too much to remember off the top of your head.
In ruby it's Time.now and I never forget it and I never have to import it and that is honestly awesome. If I open a shell anywhere in any project for any version of Ruby I've used the current time is just eight chars away, and even though I love Python, that has never been the case on any Python project I've worked on and I've worked on more than a few.
That's an interesting point. I used Rails extensively when I was a web developer. I gave this up when I shifted back to an analytical role and started writing much more numerical code in Python for analysis rather than application development.
If I were to write a web app, my first instinct would be to go back to Rails. However, I do agree with you that much as I like Ruby and Rails, Python would be my overwhelming choice for analytical or numerical code - and I do like Python.
One possibility would be to handle as much CRUD and UI development in rails as possible, and make analytical code available to the app through services in Python.
The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that.
* Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core.
* React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework.
* Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison.
* Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc.
Without speaking of the DOM and CSS, which are just _now_ starting to feel feature complete for most use cases.
Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer.
> Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core
Maybe 5-10 years ago, there is no need anymore
> React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework.
Depends on your needs. Small app? React on its own is enough. Larger app? Add a router. That’s basically it. If you want a centralized state store, you can pick one of those up. It’s really not that difficult.
> Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison
I don’t find any of this to be true.
> Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc
You mean there is nothing built in to the language itself? Yeah, that’s a feature in this case. We wouldn’t have the amazing 3rd party tooling if it did. The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command.
> The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command.
Which command would that be? Sure it's one command if you use one of a billion template projects, but just picking one of those is a chore and I'd never call that situation "amazing".
Nowadays the only choice you’re really making is which styling library to use and which state management. Everything else is a given.
Anyways, if you know enough about FE to have an opinion on the tooling, great, choose what you want. If you don’t wanna choose, use Next.js or CRA with React/Styled-Components and then add React Router if you need routing and add state management if you need it.
These aren’t difficult choices to make. I have a feeling that the problem is that people are trying to make decisions they don’t need to be making up front.
Evaluate the choices when you reach a situation that requires it.
React, Webpack, Eslint, Jest, React Testing Library
That’s the standard setup nowadays and it’s what most people should go with. If you want type checking, add TS to the mix.
But seriously, just use Next.js you can build tiny static sites with it and you can build complex SPAs. It’s very lightweight and basically just strings together all these tools while adding some convention that you can follow if you wish.
First, these generators are incredibly flexible. You can easily construct one command that fits your requirements. Understanding the correct options, your requirements for every part of the tool chain, and their occasionally predictable down-the-road implications takes quite some time, admittedly. However, all professional tools require knowledge and doc reading and experience with the latest bleeding-edge tools and experimentation and luck, I assume. Once you get a few years of experience under your belt working with this tool chain (not skipping the 3-4 hours per day after work to keep up with the latest JS ecosystem updates for this and the other new stacks you’ll need to learn throughout the week) you’ll be able to craft a command that requires very little reading or luck to use, and it could work, unmodified, for days, if not a week. If it turns out to not actually do what you want, you probably want the wrong thing— just ask on SO. But one-and-done, friend. Set it and forget it.
Second, this is all really easy if you just take the time to understand the tool chain. It’s just 4 or 19ish crucial, interdependent parts that all really should be in place from the very beginning and only most of them have inscrutable configuration schemas. Some are even documented! If you need more handholding than that, Sally, countless domain experts in countless online fora eagerly offer guidance like “go learn how X works first” or “lol that guide is weeks out of date— you have to use knippull.js instead of GROUNCE because GROUNCE was taken over by FlammBae last week and they’re just trying to sell add-ons for their data store and have ignored all PRs to support the latest version of SLAPPD which flibBleJs uses to transmogrify bNumbn{e}rs templates which you need for tr1xBits.js to work.” Once you understand how that all works, and understand how the generators implement those things, know how to compensate for the NBCF delta (Non-Backwards-Compatible Feature delta which calculates the number of implementation changes between typing the first character of your command and hitting enter,) theoretically your one-and-done is undeniably achievable.
Finally, people overstate the complexity of fixing a project started with the wrong boilerplate. Just experiment a bit. Spend a few days trying all the options to see which welcome pages don’t look broken in your browser (unless, of course, you’re using Waggle with FlermBox) and then narrow it down a bit based on that, and then just pick one. You can always fix it if it’s wrong. A literal child could understand the concept of “delete your project and start fresh” so I don’t think it should be hard to explain the concept to experienced software developers.
Developers used to paralyzingly straightforward legacy logic and organizational paradigms love to say that JS web dev tooling has the logical structure of a Wallace and Gromit short. They're completely ignoring the fact that this process was not designed— it evolved, and that’s okay. Not great, but okay.
Ultimately, it might look a little weird and insane and fragile if you peel back the onion skin to see how the sausage gets its secret sauce— but you too can achieve the pinnacle of modern developer push-button convenience with JS.
Is still either create your own or install a random package that brings other 20 as dependencies.
Example, you want to show an Alert or Yes/No popup, This are built-in everywhere but n Web world you need to review and install a third party thing, or create your own buggy or incomplete implementation.
Maybe you want modal dialogs, this is a standard in GUI tookits but you need to create your own or install a package/module/plugin specific for your project shitty framework
Maybe your designer demands a (context) menu one with keyboard shortucts and native looking like , or a scrollbar that matches the website/app theme colors or that works horizontally without holding Shift like in native apps, you have again to find 1 solution from a giant pile of shitty packages.
The dropdows,scrollbars, number spinner, color picker inputs CSS customization is pathetic, the designers demand customization and the only solution is installing third party stuff.
There is no DataGrid or ListView component with a smart implementation that can hold many items so all websites implement a crappy inefficient thing, or show you only 20 items and you need to hit NExt Page like a money or again you find a third party solution.
As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS. But as a platform the Web /DOM is still garbage, CSS got some nice feature with flexbox but that is all.
People that did not wrote complex desktop apps with a GUI framework will not understand this, and think that the shitty component they create by nesting 12 divs and catching 2 events is the exact same thing. It is not, this GUI frameworks components are efficient and handle all events/cases properly. Even Google devs were incapable to make the Youtube search suggestion dropdown work correctly, many times it gets stuck open and you can't close it without a reload.
> As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS.
Can you elaborate on this? TS is just adding type checking to JS, the only runtime addition are enums. I doubt that JS will incorporate type checking anytime soon.
I like to use class in JS to have types, some features are still missing in the major browsers like interfaces, some static stuff (I forgot), I miss the private and protected keywords , my IDE can show me errors for using the wrong types or even from JSDoc documentation but JS needs a standalone compiler/checker that will detect type errors at "compile" time.
This is a different discussion since Rails doesn't come with such an option either.
But I think you're hitting on two different, yet very related, issues here.
1. Browsers have a very limited set of standard UI components
2. Browsers are held back by the decades long, uninterrupted chain of backwards-compatibility
Both of these things are true. Back in the day, browsers forced more convention and design on elements (alert, select, input, list, textarea, etc), though developers weren't happy with the pace of innovation and design choices offered by the browsers so they began looking at alternative ways to implement the same thing. Eventually the browsers loosened up the restrictions and allowed styling of most of these elements in almost any way you like (though there still are issues).
The great thing about the web is that you are allowed to do this. You have the freedom to build things anyway you like. Of course, that comes with drawbacks like you've pointed out above. iOS is great because it provides a standard framework and approach to implement all of the things you outlined above. Though at the same time, you are limited to UX decisions that Apple deems "correct." I own an iPhone and Macbook and I wouldn't want it any other way at the OS-level.
But the web is the one platform we have where you don't have to abide by anyone's rules. The whole industry can iterate on approaches and the best ideas win. I like this world. I know it's not for everyone, but we don't have any other platform with such reach and freedom from any one company making the rules.
>The great thing about the web is that you are allowed to do this.
The truth is that for desktop(no idea about iOS or Android) I can also customize things as much as I want and I can do it faster and get better results. Desktop GUIs can give you pixel level access so you can have a button that plays a video inside it and rotates around while jump[ing and changing opacity.
About the Web I don't want to remove the option for everyone to invent their own menus if they want, I wish Mozilla,Google and Apple provide native options or as a stand alone library that you optionally include in your project.
For SPA this browser makers could colaborate to provide a standard framework, optional to use but would have all the basic features, bugs fixed and security updates, but it would be done by professional developers not as a side project by some Google dev with 0 experience in GUI toolkits.
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 full-stack 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
When I last looked at Adonis I was really turned off, but I don't remember why. Looking again, it seems like the templating is a real weakness, but lots of the other things are nice.
And there was Sails and any number of other attempts at this.
A key strength for Rails is Ruby and a key weakness for any aspiring JS equivalent is JS and the JS ecosystem.
If the Rails team had had to spend time adapting to 6 different alternatives to bundler, rack, and every other library they use it wouldn't be what it is today.
My big problem with sveltekit so far has been how strongly it wants you to use their back end.
I already have my own back end, but sveltekit is all about using their back end stuff. And their back end is 100% all in on serverless functions. If you want to write a more traditional back end and do something like grab private API keys when your service starts up, well sorry no easy way to do that, although there is an active git issue thread with people pretty much begging for the functionality.
Doing stuff like initializing logging libraries and passing them to models, or fetching API keys from secure storage buckets, is such a very common operation in any at-scale app, that I am beyond obscenely surprised sveletekit doesn't offer an out of the box way to do those things.
You can use Svelte completely separate from SvelteKit - we've been using it for a while now and integrating with our pre-existing APIs with no issues, some of those are serverless, and some are just instances behind a load balancer.
You can, but that is obviously not a happy path the svelte devs want you to use. 90%+ of tutorials and docs out there are for doing things with sveltekit.
I eventually beat it into shape of generating a true SPA, generating paths that weren't at the root of the domain, and I convinced express to serve up assets accordingly. Took way too many days to get it working though.
My issue with the JS world is that it is leaking from frontend webdev into other domains. 0.1% of your users having a bad user experience because of using a "just good enough" JS library is pretty fine for me, even if I am - as a user - in that 0.1%. But taking down your whole k8s cluster thanks to switching to a "just good enough" JS library from a battle tested python library is the exact opposite of "fine".
> Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison.
How so? I found NextJS to be one of the most pleasant and well documented frameworks to work with. Sure, you'll have to read most of the docs to find out how to do something the NextJS way, but so far, I've come to agree with every design choice they've made.
The only gripes I have with it are debugging serverless functions that work in development, but then break in the vercel/aws blackbox.
I've spoken about my dislike of next.js a few times, and it's mostly centered around its documentation. It is decent, but it is no way as complete as an established framework like Django. Have you ever compared the depth of the two? I'm on mobile, just read and compare, I don't know, the routing API docs for both.
Also the APIs are very simplistic, I haven't used it in the past few months when I quit my job, but I vividly recall how anything outside of the simple examples it provides were an exercise in frustration and digging into Github Issues and its source code. The whole data fetching system is so incredibly convoluted if you're doing a little more than static pages or build-time rendering. getInitialProps, getServerSideProps, getStaticProps, hooks, etc., all with their own caveats and performance considerations.
Next might be one of the better JS frameworks but it's laughably bad compared to Django, Rails, Phoenix.
I think in general it's a very tall order to compete with the documentation of Django. It's pretty much world class. I wish more projects had such good documentation.
I think Ember was a lot closer to a complete framework. I do believe that that's also why it didn't gain as much popularity. The learning curve was a lot steeper than for React or Angular. You won't run into the problems with the slimmer libraries till later and at that point you understand them and "just" learn the new thing, Redux or wherever you are including now. All along the way it feels smooth, but you end up with some more complicated, glued together whole. With a larger framework you might end up with something less complex and cleaner in the end.
I think on the backend we historically have had more complex problems sooner. You gotta connect to some database, serve multiple pages, track some context along, render views or API responses. It's much easier to anticipate the need for a framework or solutions to these problems sooner.
I built a product and we bet on Ember back when it, angular and react all looked like top choices. I’d say one of the biggest failures was that it didn’t provide clean upgrades We got stuck with 3.something and no clear path forward. Second, it wanted everything to be Emberized. I forget what exactly it was, but we struggled to wrap other tools in service containers so that they could be injected into our code. I think it was probably Google JS APIs like Maps, which at the time wanted you to load the toolkit their way. Ember-data probably was the biggest mistake to adopt. The amount of time I spent trying to fool some outdated JSON serializer in Rails into embedding something the way ember data wanted was a huge waste. The only other JS I’ve used seriously is Backbone, and once I was waste deep in ember I had major regrets that I didn’t choose it instead.
While I liked the React approach to UI modularization much more than that convulted MVC interpretation Ember had, Ember's routing was quite awesome, and I missed it switching to React.
> You won't run into the problems with the slimmer libraries till later and at that point you understand them and "just" learn the new thing,
No that’s only true for “junior-based development” where every greenfield project is given to juniors with an assumption that “they will learn on the job”. So they start with a simple framework and learn “while the requirement are getting more complex”.
What in fact happens is that the project was severely under-specified by the stakeholders and the juniors had “no idea that would be needed”.
> * which test framework? Mocha? Karma? Jest? Cypress?
Most of the dependencies you will install will have no tests at all anyways. This is another issue of its own, you are building on very weak foundations.
Anybody who had to maintain & keep up to date a large node codebase knows what I'm talking about. Testing is an afterthought at best and non-existent in a lot of packages. I'm not talking about the top packages of course, just the N+4 small packages you depend on.
I often find my choices will rub up against each other a lot. I never know whether to build glue code because that's the right way, or I should have picked a different library.
Regarding "require" vs "import", I find this to be a constant nightmare trying to choose one or the other. The browser and tooling for writing for the browser has all-around excellent support for using "import".
Then, at some point, I want to run some unit tests using Jest or something, and it turns into a total fucking nightmare. Each bit of tooling has certain expectations for how it expects you to import--relative vs non-relative? Do you include the .js at the end? What about .ts at the end? (That one is always "no".) Do you need .js / .mjs or .cjs / .js? Do you use ts-node? Do you want to see a warning printed to stderr every time you run Node?
1. Doesn't matter so much as long as you're using newest versions of either one. Newest yarn has plugin support which is neat. Npm has more stable backing and an open roadmap. Could be some considerations regarding monorepo support, but otherwise either is fine.
I guess your point is that this would change constantly, which isn't really the case.
Yarn and NPM has been around for a long time. Yarn 1 used to be the better choice since NPM stagnated, now they're a bit more equal.
Typescript has been around for a long time. So has ES6 modules. Same for Jest and Mocha.
The only thing that is changing somewhat are the bundlers and build tools (thankfully, they've been the weakest part of FE dev for a long time).
I've kept up with frontend for many years. There really isn't all that much "fatigue" if one actually understands what the tools do and the niches they fill.
I agree with this persons answer, if your goal is to go full custom. If you want all this setup done for you I suggest NextJS. It should be noted that Deno is not a bundler but an entirely different JS Runtime. The question should be do I use Node or Deno.
I think these are great questions. As someone who has been doing Golang for a couple of years and just got back to doing Node.js development again, I can answer some of these questions. I'll add that most JavaScript developers never think about these questions btw.
* Should I use npm or yarn?
This is one area where JavaScript is notoriously weak. As another comment mentioned, the answer might be different a couple of years from now. I discovered a package manager recently named `pnpm` and it is incredible, quite frankly. That being said, any package manager will do. They all work well (relatively, npm gets very slow in bigger projects).
* Should I introduce Typescript to be able to handle complexity better?
In 2022, the answer to this is almost always yes, for backend systems. I think this is unfortunate because you do need a transpiler. But its ease of use and type safety are hard to pass up once you've used it on a project. For frontend I tend to be more lax, although a lot of developers argue you should use TypeScript there too.
* Which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?!
Nowadays you'll likely only use `import/export`, especially if you're using TypeScript. This is not a question most JavaScript devs ask on a daily basis.
* Which test framework? Mocha? Karma? Jest? Cypress?
The short answer is it doesn't matter. The longer answer is that if you want assertions and snapshot testing built-in, Jest is a good choice. If you decide to go with Mocha, you'll need an assertion library (most commonly Chai). You probably don't want to use Karma as it was originally designed around Angular 1.x and it's starting to show its age.
Cypress is an end-to-end testing framework and has nothing to do with the rest. You'd use it in place of something like Protractor or Selenium. Additionally if you're using something like GraphQL you probably won't be able to use Cypress without a lot of hardship.
* Should I use a bundler like webpack or just move on to esbuild? Vite? Deno?!?!
This is only relevant in the frontend nowadays. And you'll probably want to use Vite. `esbuild`, while an amazing project, is a bit too verbose to set up and Vite uses it under the hood. IMO Grunt and Gulp and Webpack have never been good bundling systems (I dread every time I have to use these), so any new innovation in this area is welcome.
I see a lot of people complaining about the constant churn. I'm of the opinion that the JavaScript ecosystem is constantly improving. Vite and pnpm are absolutely amazing and I wish I would have had these tools when I was first doing frontend development. I would argue that every year JavaScript development gets way easier, not harder, and now it's the most accessible it's ever been.
Unfortunately, the amount of options can get overwhelming. Off the top of my head, there's a ton of HTTP frameworks (Express, Koa, Sails.js, Hapi.js, Nest.js, etc.) The list goes on. However I don't think this is a fair argument against JavaScript. There's a lot of choice in the Python and Golang world too. Just make good choices (maturity, stability, support) and don't always choose the newer, shinier framework, and you'll seldom run into problems in the JavaScript ecosystem IMO.
I looked at pnpm and I like it... so it's bringing the Maven strategy of having ONE place where dependencies are downloaded to and shared between projects to JavaScript!?.. which has been used since early 2000's in Java land... :D good.
This really hits home for another JS outsider that likes the language but not the ecosystem. I like to do small personal projects in Node. Simple things like consuming the Google Sheets API feel great, but when I want to expand the scope of the project and start thinking about tests, caching, and "am I doing my modules/imports/package management the RIGHT way" I usually give up or switch to a different stack.
> The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that.
Do people believe this about Angular? Not primarily a front end dev, but in my limited experience with React and Angular, it seems like Angular's strength is that it provides more structure for scaling to larger projects.
Honestly Angular is great even for startups. With the current state of the the framework and the way the Angular CLI bundles code, it's pretty hard to break 90 on PageSpeed Insights (at least without pre-rendering). But it's also not that difficult to get in the high 80s, which is pretty good for a SPA. And it should only be getting more performant as they put more working into optimizing it.
It's easy to learn, the code is super clean, TypeScript is great, and imo it generally just makes for a good work environment.
Well there are basically only two things that need to happen:
- The number of round trips needed to render a page needs to go from 3 to 2.
- The amount of JavaScript in the core framework needs to be slimmed down.
The second is already on the roadmap -- they are making Zone.js optional, and supposedly the next version of RxJS is going to be significantly smaller. In order for this to actually happen, Google needs to keep funding the project for at least another full year, which seems likely given how much they depend on it. In terms of the former -- well, it seems increasingly likely that they'll work on adding those kinds of options to the CLI once they get through with the other stuff. And if not, you can alway go back to straight Webpack and just do it yourself. (I personally like the benefits of the CLI and not having to deal with Webpack, but if Webpack keeps improving then who knows, maybe I'll switch back.)
Came here to say this. Angular ticks just about every box from the original article. It is opinionated (IMO in a good way, but YMMV), well structured, and batteries are included. You still have the flexibility to do data access, state management, and such however you like but there are well-established patterns and libraries if you want to lean on them. Modules help you scale to larger projects, with fairly painless code splitting / lazy loading. You don't have to set up any complicated build scripts, and the cognitive complexity is low (as long as you don't overuse rxjs) so junior devs can easily jump in. And, Angular is very mature now in 2022, with few-to-no breaking changes between versions. I highly recommend it as the state-of-the-art SPA platform today.
If you are creating a rich web app, you still have to deal with all of this when generating HTML+JS in another language.
Rails doesn't save you from any of this, none of the back end frameworks do. I prefer writing SPAs because if I prefer to be directly authoring my HTML+JS instead of authoring it indirectly through a framework in a different language.
My hope is that this has been/will continue to change over time, is this a fare statement? Does anyone know if the various working groups (e.g., WHATWG, W3C, etc.) have the goal of making the JavaScript more robust?
My vision is that the standard, built-in APIs would serve as a minimum viable platform that you can build simple to moderately complex applications in with only "minimal" external dependencies.
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.
> Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer.
If you can settle on a good enough batteries-included framework without analysis paralysis, you can make the individual as-needed decisions about libraries without it. It's not a problem of a higher order.
If anything, it's lower-pressure, because the cost of a wrong choice is much smaller.
A big thing a lot of people forget -- you can deploy most Rails apps to serverless/lambda (where individual controller actions are automatically mapped to individual lambdas) using Ruby on Jets with minimal to no changes to the original app. A lot of people think of Rails as a bit antiquated but that particular setup is imo ahead of what serverless framework even offers and definitely gets around the traditional problems of scaling rails app servers.
Frameworks in general are about providing a set of decisions and idioms for you to follow, and so they work very well in teams and long-lived projects. They also tend to be pragmatic rather than exotic, so they are robust and useful, not fancy and brittle.
On personal projects I do whatever the hell I want, in professional projects I always use a framework, to make sure everyone is on the same page and we don't have to bikeshed every simple decision on the road to delivery.
I think the author is trying to compare what it takes to create an MVP web-app with all modern features versus creating it in the JS ecosystem.
Also, Rails is well known to have Convention over Configuration. That helps to set up and maintain a project since everybody has to follow the same pattern. The cons is that you lose flexibility from the architecture perspective. But in Rails, you have ways to overcome that easily.
I think Rails lost popularity when the front-end JS framework movement started. Rails didn't have a response to that; people had to create the Rails app, remove the Views and use a JS framework to create the one-page app experience.
Now, if you are already spending that much time using JS for the front-end, why not use JS for the backend? But then things got too complex in the JS due to the lack of conventions.
A lot of JS tooling that popped up in the last 10 years is amazing. The React way of building a UI makes a lot of sense to me and I like it way more than HTML + JS combo from the old days. Also, using JS for both frontend and backend is convenient and great for hiring teams.
But, after years of making SPAs, it gets tiring to assemble all of the pieces from scratch every time. I don't want to configure things, I want to build my ideas.
I think in reality the JS ecosystem is fat with choice for convention over configuration style frameworks. Projects such as Nest, Sails and Adonis leave nothing on the table compared to Rails. The problem is a lot of programmers would rather loosely cobble something together with express than to stick to rigid standards. That's what I think actually leads to the problem of inane NodeJS codebases people always complain about, it's cultural rather than technical. Perhaps the accessibility and popularity of JavaScript leads to a much larger crowd of inexperienced programmers.
My hunch is that most JS developers just aren't aware of these frameworks. A lot of people in this thread are mixing up Next.js and NestJS, and NestJS is the most popular out of the three you mentioned. Sure it has a lot of stars on Github (44k), but even I had forgotten I had starred it.
I've seen this myself on the .NET side. Someone will create an MVC application then rip all the views out and tag everything with a decorator that turns those controller endpoints into API endpoints, then slap Angular or React on top of that. More recently I've seen Web APIs created which explicitly lack any front end integration (this is what we do at $DAYJOB when .NET makes sense).
I look at it the other way around, to someone coming from Ruby/Rails, there are far too many choices to make and it can seem very overwhelming. But on the flip side you get very granular control over your projects structure. Like when the author mentioned the framework options:
- NextJS, Gatsby - Best for building "websites" that are optimized for SEO
- Vite, CRA, Remix - Best for building SPA's
- Koa, Express - Backend frameworks.
On the one hand it's very overwhelming, but on the other hand, each framework accomplishes something very specific. Even the differences between NextJS and Gatsby, Gatsby uses a different model for how you would fetch data, with Next you write regular Node code, with Gatsby you do everything through GraphQL.
It is apples and oranges, but I think that's kind of the point.
Unlike Rails or even PHP, the JavaScript ecosystem is all over the place. If you choose the most popular tools available, there are many decisions to make. Not everyone wants to do devops.
Choosing something and making a decision is not as difficult as it seems. You don't have to when someone comes along and tells you "we should use pnpm because it's much faster". Before using any tool, you take a brief look at how it works and what it does, and decide accordingly. I don't understand why you see having more than one option as a problem.
I mean, analysis paralysis is a real thing. But I think people vastly overestimate the value of having a golden hammer solution like Ruby on Rails on your ecosystem and downplay the disadvantages.
why you see having more than one option as a problem
Because some of us are hardwired to choose carefully. If so, when we have to go buy some groceries we just want to get a decent car and drive. The car and driving itself is irrelevant or minutiae, but we can’t tell whether it could take left turns from the start. When there is no decent car by default, we try to be picky about every component, and when it’s almost perfect, it’s also night and the shop is closed.
It may be easy for you, for a combination of reasons: a huge experience, low perfectionism and high “fuck it, will sort it out later”-ism, and then something else. But it’s not a professional path we used to. Our professional path is to ask someone which car to buy and go buy it. But if you ask someone which js framework to use for regular tasks, you get this thread instead.
On top of that, your resume will miss a 3 years of Winch experience, which suddenly everyone demands when you lose a job or fail your company.
I think that perfectionism is a downside and coined that “easy for you” as a better mode which everyone would operate in otherwise. But it’s hard to let go of these anxious feelings, so we stick to picky routines (because if you’re not confident, it is unwise to git push). Sorry that my message wasn’t clear enough in this part.
Personally I’m trying to care less when it is reasonable to do, but even the amount of options where to do that in common js stacks is overwhelming.
For a simple MVP, Rails is enough. As features grow and frontend becomes more complicated, you can then evaluate again if you want to move the rendering part into a separate SPA while retaining Rails as API server.
I think it all goes down to the explosion of popularity of javascript, it is a bunch of tools made by a relatively new to tech people, for relatively new to tech people, still trying to understand/learn how to do things properly , it is not an attack, it is just an opinion, many new technology at their dawn have had the same issue
We need libraries that are less opinionated and more tightly focused, working through standard APIs that are open and composable. As an example, htmx works w/ any back end fine because it's "just HTML". That's great because you can use htmx with any HTML-producing backend without a big conceptual shift on either the front end or back end.
But the downside of that approach is that it is more fiddly and doesn't handle a lot of stuff out of the box (e.g. CSRF protection) that someone who wants it to "just work" expects.
This is where the other side of the barbell comes in: a nice and complete collection of htmx + whatever config is needed for a particular back-end, and all the other stuff that a typical developer might need to just get things running would be really nice. As someone from the java world, maybe just a pom.xml file w/ an init script that sets up the base project, or something like that.
I like the choices I get when building with JavaScript. There's always something new to learn and I get to pick the flavors that I like to work with. :)
But I do envy the simplicity of Ruby on Rails. I might try it for my next project after reading this article.
This article resonated with me, but the main reason I moved from RoR apps to JS/SPA was hosting costs and scalability. I can build a SPA and host the bulk of it on Amazon S3 and pay significantly less monthly costs AND have scalability built in. If you've figured out a way to do something remotely similar with Rails, I'd be back in a heartbeat.
> Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework.
Perhaps I missed it, but the single biggest reason that I moved away from SPAs (such as React) and back to server-side rendering of templates is avoiding having to model my data twice. That’s a lot of overhead.
Granted, I’m in the B2B software space, so end-user expectations are those of accuracy, consistency and performance. I imagine expectations (or perhaps priorities) are different for consumer-facing applications.
Agreed. We tried bolting a js front onto our elixir app and instead ended up using liveview. It saves us a ton of effort and has most of the bells and whistles our users expect anyway.
This comment would be more helpful with some examples. I’m personally very curious what the leading solutions are. I’ve worked with one involving GraphQL but that’s about it.
I can't speak to leading solutions, but in the .net world, there's Blazor[0] which is C# for the whole stack. There's also Fable[1] which is F# the whole way down.
btw. most of the time I wish my company used such things or that code would be more isomorphic, BUT!!! most of the time isomorphic models lead to way more problem, especially when it comes to validation.
Maybe this isn't what the GP comment meant, but I think codegen can serve this function pretty well nowadays. 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.
Can't speak for the rest of the world, but my team has been using an NX monorepo with a standard types library that can be imported into any application in the monorepo. It is trivial to use the same interface, enum, class, or other type-enforcing mechanism across multiple frontend and backend services. The development experience has been quite nice, and refactoring/changing the data structures is a breeze. If you are in the Typescript world and haven't looked at NX...check it out.
By the way, echoing some discussion above, we migrated from Express to NestJS, and it was an excellent decision.
Yep, I personally have written our backend in Python (with type-hints) and the frontend is a React SPA that I recently migrated from JS to TS.
After the migration to TS, I really want something I can use to model the data once and use in both the backend and frontend, because its very repetitive. Haven't found anything yet.
React really has nothing to do with SPA and is only the "V" in MVC. So I'm curious how you were modeling your data in the first place. Since you didn't mention the backend language, I'm going to assume you aren't using node and don't get the benefit of isomorphic code here.
I don't feel it's too much of a stretch to assume that most people doing SPA are probably using node on the server and something like Redux. Then it's a matter of "hydrating" the Redux store + React. Which basically amounts to serialization of the data and passing it to the client via a global variable embedded in the source of the HTML page. When done in this manner, the modelling and fetching of data is identical on the client and the server.
> I’m in the B2B software space
Does your software act like an application? I really feel like B2B is the place to use SPA. You have a login, some sort of dashboard, the user interacts and modifies things. SPA is really slick in this use case. Where SPA falls apart is when you need to present your site as individual pages to Google for SEO and try to get some of the benefits of SPA. That's a nightmare to get right and to maintain.
For B2B I would not use SPA on the marketing, landing, pricing, signup pages and use SPA for the application, itself. Effectively a dual site. Which works really well.
At least for the front-end part another, more complete framework like Angular might have been a better fit for the author. Angular comes with pretty much all you need.
I don’t fully understand the issues people have with JavaScript and especially React. Maybe it’s because we invested some time in setting up a baseline project with ESLint, prettier and a TSConfig that makes for an entirely fascist way of doing TypeScript that just happens to always work. Maybe it’s because we don’t NPM install a lot of things, but instead take what we need and build our own packages (riding free on the backs of hard OS labourers, but hey). Maybe it’s because we build most compute heavy things in Azure functions running either dotnet or Node. Maybe it’s because we’ve adopted ODATA, build a generic API for 95% or our use cases and then build an ODATA TS client that includes types for all ODATA URI conventions and all our tables. Maybe it’s because all our packages are build with Rollup and Microsoft’s own Type API. Maybe it’s because our pipelines flow directly through Azure DevOPs and into different deployment slots automatically once it’s set up with docker. Maybe it’s because I’ve never worked smart with another tech stack.
But building things with react is frankly the easiest, least complicated and most enjoyable thing that I have ever worked with.
For references I have a decades worth of C# experience, with a gradual transition into Python and now into C# and mainly TypeScript.
Don’t get me wrong, I don’t think you should use a tool that isn’t right for you. If Ruby works, great. If Django works, awesome. Hell, if old customised ASP 3.0 web forms help you deliver the product you need to deliver, then I’m just never going to judge you. I’ve been part of teams that created incredibly business value with tools most people would consider insane after all.
But I think TypeScript is just increasingly useful. The only thing you can’t do with TypeScript, and especially with JavaScript, is Google solutions.
I learned this the hard way when I had to build my first NPM package. It was easy enough, but then it had to work with Azure functions and I entered a world of hurt. As any good senior programmer, I read the documentation and didn’t understand one bit or it, other than GitHub enterprise has replaced NPM enterprise which is kind of shit when you’re using Azure DevOps and not GitHub, but hey, we’ll just put our packages public. I don’t have access to the corporate credit card anyway and getting it takes a week, and going public will enforce a lot of best practices on its own. Anyway, a week later and 9 million Google rabbit holes later, I stumble across rollup and Microsoft’s api for generating .d. type files. Ten minutes later, everything, works effortlessly. But that’s 9 million medium, dev.to, you name it attempts later. It’s 9 million different ts configurations. It’s 9 million package.jsons later.
So I sort of lied when I said that I didn’t get the author, because I do, but the thing is. It’s not really the technology is it? To me at least it’s rather the endless sea of useless “look at me” blog posts that inevitably follows popular technologies.
React is great until you have non-trivial state management then life starts to suck again.
The # of react apps I've seen where every key press entered into a form takes 200-500ms is super high. Heck the first version of Work At A Startup here on HN had input box latency problems that looked a lot like what I see in React all the time.
It is funny because Redux's religious adherence to a const store makes no sense. Sure it provides a cool debugging trick where you can rewind things, but other than that it seems to just provide an endless hole of performance issues with people using the spread operator incorrectly.
C# and Winforms lets me pump out CRUD apps at literally 20x the speed I can in React. What takes me a day in Winforms can take a month in React. Wish I was kidding there. I once prototyped a website in Winforms, less than day.
I spent 3 days getting a date time picker working across all browsers desktop and mobile with accessibility support working. (Only because Safari doesn't support datetime pickers....)
Web dev sucks compared to desktop development. Hell Java + Swing had higher developer productivity than web dev.
> React is great until you have non-trivial state management then life starts to suck again.
I agree. This is a bit where the lack of frontend seniority tend to show it's colors in my opinion. People try to fit every use case onto e.g. Redux (or the even less competent useState) and then try to throw middleware at it to solve all of the complexity they're drowning in.
Frontend really should utilize more powerful state management tools (when necessary of course), e.g. Observables or Finite State Machines. We're using hammers to solve problems that require screwdrivers.
I found MobX working wonders for React UI responsiveness. You can cut-off large parts of rerendering more-less for free, without worrying you'll cut-off too much.
I just wish MobX was statically typed, so I could know what has been observed by just looking at the usage site, instead of hunting for where the corresponding makeObservable is.
read quite some articles like switching from SPAs to rails|django|laravel, basically from the new cool kid back to the old man in the backyard.
but, what about using Go with its web frameworks(e.g. Gin), it has everything you need to build a web application, and it could be all in one binary, and if you want to scale it's not hard too.
ASP.NET is great but it definitely comes under the same banner of 'too many choices needed' compared to Rails.
e.g.
Framework - Which .NET framework do you use (Core/LTS)? Do you use MVC, Razor Pages, Web API and Blazor (Server or WebAssembly) or Web API and an alternative JavaScript/TypeScript based frmaework?. Do you use JSON/XML/SOAP or gRPC? How do you serialize your JSON (NewtonSoft.JSON or System.Text.JSON)?
Database - Do you use Dapper, Entity Framework or just utilize a SQLConnection object manually (And then do you use System.Data.SqlClient or Microsoft.Data.SqlClient)? Which database driver do you you use?
Authentication - Do you implement this manually? Do you use something like Identity Framework? Do you use a third party provider like Azure AD(B2C), Auth0 etc. etc.? Do you use header based authentication, JWT's etc. etc?
Jobs - Do you create a separate service project or Windows Service? Do you use HangFire or Quartz?
Email delivery - How do you render your templates? Do you send via SMTP manually or do you use a third party API like Mailgun/Sendgrid etc. etc.
Folder structure - completely up to you, no real standards there.
Testing - Do you use XUnit, NUnit, MSTest, SpecFlow?
There is no "Core" anymore: LTS is now .NET 6. If you are building webpages, the "Legacy" .NET Framework 4.x is no longer relevant in any way (unless you are unlucky enough to have legacy apps with no drive/budget for cleaning up tech debt, and I'm sorry on your behalf). The last LTS "Core" version (.NET Core 3.1) is out of support in December and the upgrade path is simply .NET 6. There's only one choice right now and it is .NET 6. (It'll complicate a bit with .NET 7 in a few months, but only in the alternating LTS/"current" versions way of things like NodeJS, nothing like the Core/Framework confusion of the past few years.)
> MVC, Razor Pages, Web API and Blazor
MVC and Web API merged many moons ago, it's not really a choice between them, they use the same APIs and are built the same way way today.
(Editorializing: Razor Pages is making many of the same mistakes of ASP Classic or PHP/ColdFusion over again, and I don't see it as a great choice personally. Blazor is making similar mistakes to both Razor Pages and Silverlight, and
really feels like ASP Classic 2.0. I understand its appeal to some development teams, but wow does it seem like a clunker from my vantage point.)
This comment is ridiculous. You've shifted this from "too many options for everything" to "any options at all". Also, how are these things framework specific? The API vs templates argument also applies for Rails. Choosing an authentication method also applies to Rails. Choosing rendered emails via SMTP vs Sendgrid - also applies to Rails. And so on. You can't mix business requirements with "tooling choices".
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
For authentication, 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 registration/login system with all the required views/models/migrations in a couple commands.
> I've never found anything for ASP like Devise which gives you an entire registration/login system with all the required views/models/migrations in a couple commands.
???????????????????????????????????????????
You know that this is built-in, right?
I've settled with Svelte (SvelteKit and Sapper), after having spent lots of time with React and Vue.
Svelte works in a way that jives with how I think and work, and I've built enough components for myself that side projects now only take hours to design and build into working prototypes.
I think everyone needs to have a "home platform" where it's just mindless to get started. Regardless whether it's JS SPAs or Rails or raw HTML!
For handling data, it's either Supabase or Airtable's API, hands down. Tailwind for design system.
I've tried Rails before, but as a newbie to Ruby, I couldn't even figure out how to write for loops. To me, that was too foreign, and too much thinking involved. And with Rails, you need to run a server too right? That's even more not-mentioned work.
489 comments
[ 0.29 ms ] story [ 300 ms ] threadBarely any convention, lots of repetition and configuration - all things Rails specifically set out to solve.
The issue is more that Node and JavaScript in general is too popular and there are way more options whereas ruby is rarely used for non rails work.
How is it a bad thing? Again, JavaScript is far more popular than all of those for web related development. The issue is that like you're stating, there isn't a single main option perse. I'd use NestJS.
PHP should have made a much bigger push early on; mark the weird and unsafe functions as deprecated and point to e.g. prepared statement alternatives. They should have built a package / dependency manager much earlier on. And they should have made a lot more efforts to get a developer community up and running.
These conversations always tend to go the same way; someone complains about PHP and then later admits it's based on their experience 5-10+ years ago. PHP has come a long way and is worth checking out if you're into web development.
PHP has mage huge strides in typing too, I havent kept up with Ruby to know if they do the same
Sorbet is trying, but it's... not there yet (although getting better).
But Crystal has around 468 open bugs at the time of writing :(
https://github.com/crystal-lang/crystal/labels/kind%3Abug
Issues are well over 1k…
[0] https://rubyinrails.com/2017/07/21/rails-introduces-active-s...
[1] https://laravel.com/docs/5.0/releases
Basically it comes down to magical behavior, and the fact that Rails has way too much of it. Syntactic sugar and DSLs are maybe fine for rolling out new projects, but become burdensome on large codebases. I was on a large project and found myself in goto hell where I literally couldn't trace through the code. It was relying on every magic trick in the book to make the code as small and cute as possible, but failed utterly to provide anchors in the code where "this happens here" or breadcrumbs connecting chunks of code. It was a giant hodgepodge of I don't know what. Really clean spaghetti code I guess.
Now, Laravel has its own warts, but they aren't conceptual warts. For example, the stack traces in Laravel are way too tall, with way too many factories and patterns in the vendor code. I feel that things like the IoC container were not implemented as well as they should be. The goto hell in Laravel happens around stuff like the bootstrap process, registering service providers, queuing, etc. They made some mistakes in scattering those things around instead of handling them in one central place. Pretty much all classes provide 95% of what you need, but adding missing functionality yourself requires learning the entirety of the package (in fairness, this happens with pretty much all platforms). There's a tendency for Laravel projects to not support helper functions or custom classes in a standardized way, so sometimes it's hard to find business logic. Not nearly as hard as in Rails though. But as a whole, I'd take conceptually clean interfaces with mundane implementations and no surprises over magical behavior any day.
Just to not leave anyone out - I wouldn't implement business logic in any Javascript framework. I feel that async basically makes it impossible to do it deterministically. I'm sorry that happened to Javascript and am still in mourning about it, because it had some advantages over PHP in how it treated associative array access with "[]" the same way as object member access with "." which could have been used in PHP to implement copy-on-write everywhere and really set it apart from all other imperative languages. Mistakes were made in both, and Ruby as well, that took them all in directions that I wouldn't have chosen.
https://sive.rs/pg
Today I mostly write solutions in a synchronous-blocking, functional-reactive, event-driven, immutable, stateless, data-driven, declarative manner that tries to avoid custom types/objects, manually managing nulls or asynchronous behavior. Which if all orchestrated correctly, leads to future-proof code because it's so obvious that it's self-documenting and the failure modes are all safe.
IMHO, the vast majority of software out there involving Javascript, Ruby, Python, really any of the imperative languages, can't achieve what I'm trying to do. It even feels like they actively work against me sometimes. I think of Laravel as getting most of the interfaces and approaches conceptually correct, even if the internals use factories and patterns and hand waving that I consider spaghetti. Whereas Rails involves some element of drinking the kool-aid, because it encourages some conceptually incorrect approaches like ignoring process separation to achieve better performance or fit with some preexisting notion of what's beautiful or easy. Along those lines, probably stuff like Phoenix/Elixer, Erlang, etc are closest to what I'm working towards, but they introduce their own custom syntax that strikes me as perhaps too DSL-like and I have an aversion to that. Which is the main reason why I struggle to learn stuff like Haskell.
There truly are vanishly few actually good solutions today, and I've been following web development for over 25 years now. That used to really get me down. But I realize now that the situation presents an opportunity to fix things and build a better future, which I am grateful for.
I haven't even tried to setup dev environments for python, php or js on Windows. It is just so easy to use WSL2.
Express isn't terrible; it's just more like Sinatra.
That probably has more to do with PHP being such an easy language to get started with, inviting a lot of rookies/cowboys to the party.
I mean, you can read and choose what you like whether it's Nest/Adonis/Blitz or anything else. Once that choice is made everything that follows is opinionated.
This comparison isn't a good one. Rails is an all-encompasing framework.
If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have.
---
EDIT: To clarify (because it is confusingly named), NestJS is a framework modeled after Spring Boot for TypeScript + Node:
https://nestjs.com/
Not to be confused with Next.js, which is a framework for building SSR React apps.
What I was trying to say is that Rails got a lot of things right and it's making me productive, because I don't have to make the same decisions over and over again when making a JS app. Rails made those decisions for me and the only thing left for me is to build my app.
I myself like Next.js and Remix a lot, but they still leave you to spend time making basic decisions, like how to organize your project or how to implement background jobs.
That's why I'd love to see more conventions and less configuration in the JS land.
Which is what the parent post is saying NestJS offers. I'm not familiar with it, so can't comment on the veracity of that claim, but I think you might have missed their point, perhaps because they confusingly called it "Nest.js" which could be mistaken for "Next.js".
Not quite. "NestJS" is actually right. :)
And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals.
If it turns out your goals are a very simple crud app for a team of under 5 - Rails is probably a great choice.
For most everything else, you should probably understand why Rails made the choices they did, and what the trade-offs are. (ex: I would argue that the author is making a HUGE mistake by not just immediately outsourcing auth to something like a self-hosted Keycloak instance, or Okta/Auth0 - but my needs require enterprise auth support (SAML, OIDC, Provider support, etc) and maybe his don't)
But the thing is... there are TONS of simple CRUD app frameworks out there. Rails is a good one, but so is NestJS, or ASP.net Core. There's at least one "Opinionated" CRUD framework for almost every language.
Rails is still good, but I find it has a distinct "ASP.net classic" feel to it now - Too many versions, too much change, too many contradicting "opinions" between major versions.
That comes with a downside though, which is that for any given problem there won’t necessarily be an ultra-well-supported “happy path” where every conceivable problem has long been documented along with a solution.
To me the lack of happy paths can be a problem. It’s something that is often encountered with Android development because Google can’t make up its mind and it’s very frustrating — usually your choices are between 5 different APIs that suck in different ways, meaning you have to pick the one that sucks in a way you think you can deal with best. It’s a significant damper on both velocity and motivation.
Problems that fall into that space are usually better served by simple site builders (Wix/Square/Shopify/Wordpress/etc).
Tell us you haven't used Rails much without telling us you haven't used Rails much. There's been precious little I've needed to change in my approach since the 3.x days. The new TurboJS world they're baking into 7 sounds significant though.
Well Rails is gonna celebrate 20 in 2 years, so yes there's quite a lot of versions and changes over the years, that's inevitable for every long running project I think.
The JS ecosystem as we know it today started years after Rails (Rails was 2004, Node's oldest version on their releases page is from 2011), and only really took off after NodeJS came to prominence with frameworks like BackboneJS, Angular, then React and the rest in the early 2010's, and it went along with Github and the emergence of everyone and their dog building libraries and frameworks.
The attitude was different; instead of big opinionated but inflexible frameworks, people wanted to pick and choose. This was exacerbated by React that emphasized NOT being a framework but just a rendering layer.
Pick ANY one-size-fits-all framework in the JS space and you will see "bad" decisions that people don't like.
The closest thing to a full JS framework at the moment is probably Angular, which feels bloated and overly complicated (annotations, component / folder structure / file naming) or Express (stringly typed? I haven't looked at it in forever).
Rails has a clear one way to do things because there are no/few other options because everything else has withered away.
To put this another way: to have a convention in JS, just pick a convention, and now at least you have a convention, even if everyone else has their own.
Roda[1], for instance, has a strong following for API work.
It’s just that Rails is a safe choice. It’ll will work fine for small teams and it will scale to the size of github when/if you need it.
1. http://roda.jeremyevans.net/index.html
Rails draws the attention, but there's plenty other uses.
Is there much happening in terms of libraries outside the rails scope or is it more a case of one less thing to worry about once you've become good with the batteries included?
Capybara is fantastic for automated testing
https://github.com/teamcapybara/capybara.
Gosu for 2d Games:
https://www.libgosu.org/
Example 2d game with Gosu:
https://github.com/victords/super-bombinhas
CRuby will be in browsers!
https://bugs.ruby-lang.org/issues/18462
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!)
E.g. for ORMs ActiveRecord which is Rails default is in my opinions nowhere near good enough compared to e.g. Sequel, and there are several others.
Sometimes those projects involve wrapping stuff - including Python - or porting Python, but most of what I use is pure Ruby.
With respect to Python, to a lot of the Ruby community Python is in many ways the antithesis of what we want in a language. Python looks horrendous to me. It matters - I stare at code most of my day. If I were to switch languages, Python wouldn't make the shortlist even. It's not that I think Python is objectively worse, but subjectively to me it's unreadable and messy and I can afford to avoid using it most of the time.
EDIT: To expand on some of what I use or have used Ruby for: web dev with Sinatra and Padrino (my main reason for avoiding Rails here is that most of what I do is mostly API driven, and because I prefer Sequel as the ORM), financial modelling (I work for a VC), my text editor of the last few years is written in Ruby (but not packaged up to be useful for others yet - I'm gradually splitting parts of it out into gems, though), DevOps by generating terraform, service orchestration (proprietary pre-Kubernetes orchestration of containers and vms across on-prem, colocated, managed servers and VPSs split between openvz, docker and KVM), system to auto-deploy replicated sets of Postgres servers with logs and backup dumps automatically distributed to a Ruby storage service (pre-RDS, and running on the aforementioned orchestrator), PDF generation, messaging middleware, scraping, large scale crawlers, trading bots. And many more.
There's plenty of space.for alternatives. But Rails is good enough for those who are happy with a hammer, and so it's what gets talked about the most.
I enjoy working with Node and JS, but this IMO is what contributed to the fragmented node ecosystem where you have 100 different npm libraries that do the same thing and reinventing the wheel is rampant
Rails is not the only choice that does so. And people with broader skill sets can assemble their own solutions and might not want that anyway. But this author just wanted to pick a platform and move on, and yep, Rails works for that.
No doubt here! I know there's a lot of nitpicking, but that's just my experience so far. I wanted to make it clear by removing all "we" or "you" words from the post to make sure I'm not saying my opinion is the definitively right one :)
> Rails is not the only choice that does so.
Absolutely, the only two reasons I went with Rails is because Ruby looks beautiful to me and I was following the news in Rails world for years.
I’ve yet to see anything in Node that feels like a stable 1:1 replacement. Next.js is excellent, but you still need to sort out a lot of pieces on your own.
https://redwoodjs.com/
Recently I’ve also been impressed with Remix that was mentioned in the article. It seems to have solved the client server code duplication problem while still offering the benefits of both.
But to be fair 99% of JS backends I see are using Express (or AWS Lambda). Considering there's lots of choices I wonder if the problem is the fact the community never focused on a single solution. I wonder if a Merb/Rails-style merge between some of them would help that.
The point is that Django lacks a sane default for project structure and it costs time/money to people using it.
There is a very good talk from Dan Palmer from Djangocon 2021 called "Scaling Django to 500 apps" that gives helpful advice for project layout in a django app that may only have a few or several apps:
https://2021.djangocon.us/talks/scaling-django-to-500-apps/
That said, if we're going to dig on Django, it lacks typing, core-based API patterns and any embrace of modern front end. There are positive signals though, releases are coming faster and there is some real talent on the tech board right now.
I do think django and python in general are in a defensive position to hold the future of backend webdev compared to node / deno. However, there's still plenty of opportunity to compete for developers.
I’m not sure why there should be; for people who are happy with “good enough” default choices for a web app, Rails exists and makes the choice “Ruby” when it comes to language.
This is really a Node or JavaScript problem and not an Next.js problem. Not that I have any idea how you might solve it. This is also just a single example and we tend to have these decisions at a lot of steps along the way.
I'd say it is still a mix of both and both paths are well-supported and well-maintained.
I know it sucks, because Rails is better than Django, but at the end of the day I love Ruby but my day job is Python. Also, even though I can never remember capitalization, underscores , pluralization, interfaces in Python[0] at least I don't have to think when I type `and` and at least strings aren't mutable by default and when I need the data science it's right there waiting for me.
[0] lol "".startwith, "".starts_with, start_with(""), etc. In Ruby it's Time.now, come on people.
> In Ruby it's Time.now, come on people.
YMMV, but I don't find it terribly burdensome to import datetime and call datetime.now().
Because is it datetime.datetime.now? or date_time.date_time.now? or datetime.Datetime.now? Or datetime.DateTime.now? Or DateTime.now? or dt.datetime.now?
Because it could be any of those. Some people import datetime like numpy (import numpy as np) so they can call timedelta like dt.timedelta and this is fine and everything, but the combination of no standard in python for how to do this, plus the hard to remember interfaces, plus the multiple libraries that try to do the same thing and the different way they differ in capitalization, etc. Means there is just way too much to remember off the top of your head.
In ruby it's Time.now and I never forget it and I never have to import it and that is honestly awesome. If I open a shell anywhere in any project for any version of Ruby I've used the current time is just eight chars away, and even though I love Python, that has never been the case on any Python project I've worked on and I've worked on more than a few.
If I were to write a web app, my first instinct would be to go back to Rails. However, I do agree with you that much as I like Ruby and Rails, Python would be my overwhelming choice for analytical or numerical code - and I do like Python.
One possibility would be to handle as much CRUD and UI development in rails as possible, and make analytical code available to the app through services in Python.
* Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core.
* React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework.
* Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison.
* Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc.
Without speaking of the DOM and CSS, which are just _now_ starting to feel feature complete for most use cases.
Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer.
Maybe 5-10 years ago, there is no need anymore
> React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework.
Depends on your needs. Small app? React on its own is enough. Larger app? Add a router. That’s basically it. If you want a centralized state store, you can pick one of those up. It’s really not that difficult.
> Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison
I don’t find any of this to be true.
> Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc
You mean there is nothing built in to the language itself? Yeah, that’s a feature in this case. We wouldn’t have the amazing 3rd party tooling if it did. The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command.
> The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command.
Which command would that be? Sure it's one command if you use one of a billion template projects, but just picking one of those is a chore and I'd never call that situation "amazing".
Like, create-react-app is great, but if you have to eject, you've got no parachute
Anyways, if you know enough about FE to have an opinion on the tooling, great, choose what you want. If you don’t wanna choose, use Next.js or CRA with React/Styled-Components and then add React Router if you need routing and add state management if you need it.
These aren’t difficult choices to make. I have a feeling that the problem is that people are trying to make decisions they don’t need to be making up front.
Evaluate the choices when you reach a situation that requires it.
Would you please send a link that summarizes this "everything else"? Every time I take a look at JS ecosystem I get lost.
That’s the standard setup nowadays and it’s what most people should go with. If you want type checking, add TS to the mix.
But seriously, just use Next.js you can build tiny static sites with it and you can build complex SPAs. It’s very lightweight and basically just strings together all these tools while adding some convention that you can follow if you wish.
First, these generators are incredibly flexible. You can easily construct one command that fits your requirements. Understanding the correct options, your requirements for every part of the tool chain, and their occasionally predictable down-the-road implications takes quite some time, admittedly. However, all professional tools require knowledge and doc reading and experience with the latest bleeding-edge tools and experimentation and luck, I assume. Once you get a few years of experience under your belt working with this tool chain (not skipping the 3-4 hours per day after work to keep up with the latest JS ecosystem updates for this and the other new stacks you’ll need to learn throughout the week) you’ll be able to craft a command that requires very little reading or luck to use, and it could work, unmodified, for days, if not a week. If it turns out to not actually do what you want, you probably want the wrong thing— just ask on SO. But one-and-done, friend. Set it and forget it.
Second, this is all really easy if you just take the time to understand the tool chain. It’s just 4 or 19ish crucial, interdependent parts that all really should be in place from the very beginning and only most of them have inscrutable configuration schemas. Some are even documented! If you need more handholding than that, Sally, countless domain experts in countless online fora eagerly offer guidance like “go learn how X works first” or “lol that guide is weeks out of date— you have to use knippull.js instead of GROUNCE because GROUNCE was taken over by FlammBae last week and they’re just trying to sell add-ons for their data store and have ignored all PRs to support the latest version of SLAPPD which flibBleJs uses to transmogrify bNumbn{e}rs templates which you need for tr1xBits.js to work.” Once you understand how that all works, and understand how the generators implement those things, know how to compensate for the NBCF delta (Non-Backwards-Compatible Feature delta which calculates the number of implementation changes between typing the first character of your command and hitting enter,) theoretically your one-and-done is undeniably achievable.
Finally, people overstate the complexity of fixing a project started with the wrong boilerplate. Just experiment a bit. Spend a few days trying all the options to see which welcome pages don’t look broken in your browser (unless, of course, you’re using Waggle with FlermBox) and then narrow it down a bit based on that, and then just pick one. You can always fix it if it’s wrong. A literal child could understand the concept of “delete your project and start fresh” so I don’t think it should be hard to explain the concept to experienced software developers.
Developers used to paralyzingly straightforward legacy logic and organizational paradigms love to say that JS web dev tooling has the logical structure of a Wallace and Gromit short. They're completely ignoring the fact that this process was not designed— it evolved, and that’s okay. Not great, but okay.
Ultimately, it might look a little weird and insane and fragile if you peel back the onion skin to see how the sausage gets its secret sauce— but you too can achieve the pinnacle of modern developer push-button convenience with JS.
Is still either create your own or install a random package that brings other 20 as dependencies.
Example, you want to show an Alert or Yes/No popup, This are built-in everywhere but n Web world you need to review and install a third party thing, or create your own buggy or incomplete implementation.
Maybe you want modal dialogs, this is a standard in GUI tookits but you need to create your own or install a package/module/plugin specific for your project shitty framework
Maybe your designer demands a (context) menu one with keyboard shortucts and native looking like , or a scrollbar that matches the website/app theme colors or that works horizontally without holding Shift like in native apps, you have again to find 1 solution from a giant pile of shitty packages.
The dropdows,scrollbars, number spinner, color picker inputs CSS customization is pathetic, the designers demand customization and the only solution is installing third party stuff.
There is no DataGrid or ListView component with a smart implementation that can hold many items so all websites implement a crappy inefficient thing, or show you only 20 items and you need to hit NExt Page like a money or again you find a third party solution.
As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS. But as a platform the Web /DOM is still garbage, CSS got some nice feature with flexbox but that is all.
People that did not wrote complex desktop apps with a GUI framework will not understand this, and think that the shitty component they create by nesting 12 divs and catching 2 events is the exact same thing. It is not, this GUI frameworks components are efficient and handle all events/cases properly. Even Google devs were incapable to make the Youtube search suggestion dropdown work correctly, many times it gets stuck open and you can't close it without a reload.
Can you elaborate on this? TS is just adding type checking to JS, the only runtime addition are enums. I doubt that JS will incorporate type checking anytime soon.
I mostly agree with your other points.
But I think you're hitting on two different, yet very related, issues here.
1. Browsers have a very limited set of standard UI components
2. Browsers are held back by the decades long, uninterrupted chain of backwards-compatibility
Both of these things are true. Back in the day, browsers forced more convention and design on elements (alert, select, input, list, textarea, etc), though developers weren't happy with the pace of innovation and design choices offered by the browsers so they began looking at alternative ways to implement the same thing. Eventually the browsers loosened up the restrictions and allowed styling of most of these elements in almost any way you like (though there still are issues).
The great thing about the web is that you are allowed to do this. You have the freedom to build things anyway you like. Of course, that comes with drawbacks like you've pointed out above. iOS is great because it provides a standard framework and approach to implement all of the things you outlined above. Though at the same time, you are limited to UX decisions that Apple deems "correct." I own an iPhone and Macbook and I wouldn't want it any other way at the OS-level.
But the web is the one platform we have where you don't have to abide by anyone's rules. The whole industry can iterate on approaches and the best ideas win. I like this world. I know it's not for everyone, but we don't have any other platform with such reach and freedom from any one company making the rules.
The truth is that for desktop(no idea about iOS or Android) I can also customize things as much as I want and I can do it faster and get better results. Desktop GUIs can give you pixel level access so you can have a button that plays a video inside it and rotates around while jump[ing and changing opacity.
About the Web I don't want to remove the option for everyone to invent their own menus if they want, I wish Mozilla,Google and Apple provide native options or as a stand alone library that you optionally include in your project.
For SPA this browser makers could colaborate to provide a standard framework, optional to use but would have all the basic features, bugs fixed and security updates, but it would be done by professional developers not as a side project by some Google dev with 0 experience in GUI toolkits.
I'm very bullish on SvelteKit — hits all the points you mention above and outputs a minimal, performant full-stack 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
Oh, and also they provide a repl to your app code and data… that is huge and super hard to find in the js world
A key strength for Rails is Ruby and a key weakness for any aspiring JS equivalent is JS and the JS ecosystem.
If the Rails team had had to spend time adapting to 6 different alternatives to bundler, rack, and every other library they use it wouldn't be what it is today.
I already have my own back end, but sveltekit is all about using their back end stuff. And their back end is 100% all in on serverless functions. If you want to write a more traditional back end and do something like grab private API keys when your service starts up, well sorry no easy way to do that, although there is an active git issue thread with people pretty much begging for the functionality.
Doing stuff like initializing logging libraries and passing them to models, or fetching API keys from secure storage buckets, is such a very common operation in any at-scale app, that I am beyond obscenely surprised sveletekit doesn't offer an out of the box way to do those things.
I eventually beat it into shape of generating a true SPA, generating paths that weren't at the root of the domain, and I convinced express to serve up assets accordingly. Took way too many days to get it working though.
How so? I found NextJS to be one of the most pleasant and well documented frameworks to work with. Sure, you'll have to read most of the docs to find out how to do something the NextJS way, but so far, I've come to agree with every design choice they've made.
The only gripes I have with it are debugging serverless functions that work in development, but then break in the vercel/aws blackbox.
Also the APIs are very simplistic, I haven't used it in the past few months when I quit my job, but I vividly recall how anything outside of the simple examples it provides were an exercise in frustration and digging into Github Issues and its source code. The whole data fetching system is so incredibly convoluted if you're doing a little more than static pages or build-time rendering. getInitialProps, getServerSideProps, getStaticProps, hooks, etc., all with their own caveats and performance considerations.
Next might be one of the better JS frameworks but it's laughably bad compared to Django, Rails, Phoenix.
I think on the backend we historically have had more complex problems sooner. You gotta connect to some database, serve multiple pages, track some context along, render views or API responses. It's much easier to anticipate the need for a framework or solutions to these problems sooner.
For anyone curious linkedin.com is a massive ember.js app and they're big contributors to the project.
While I liked the React approach to UI modularization much more than that convulted MVC interpretation Ember had, Ember's routing was quite awesome, and I missed it switching to React.
No that’s only true for “junior-based development” where every greenfield project is given to juniors with an assumption that “they will learn on the job”. So they start with a simple framework and learn “while the requirement are getting more complex”.
What in fact happens is that the project was severely under-specified by the stakeholders and the juniors had “no idea that would be needed”.
* should I use npm or yarn? Why do I see most package authors recommending yarn when npm is the default as far as I know?
* should I introduce Typescript to be able to handle complexity better?
* which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?!
* which test framework? Mocha? Karma? Jest? Cypress?
* should I use a bundler like webpack or just move on to esbuild? Vite? Deno?!?!
It's a nightmare every time I am forced to use JS (usually because of cloud services normally offering JS lambdas and nothing else)...
Most of the dependencies you will install will have no tests at all anyways. This is another issue of its own, you are building on very weak foundations.
It's too fine grained.
Then, at some point, I want to run some unit tests using Jest or something, and it turns into a total fucking nightmare. Each bit of tooling has certain expectations for how it expects you to import--relative vs non-relative? Do you include the .js at the end? What about .ts at the end? (That one is always "no".) Do you need .js / .mjs or .cjs / .js? Do you use ts-node? Do you want to see a warning printed to stderr every time you run Node?
1. Doesn't matter so much as long as you're using newest versions of either one. Newest yarn has plugin support which is neat. Npm has more stable backing and an open roadmap. Could be some considerations regarding monorepo support, but otherwise either is fine.
2. Yes
3. Use ES6 modules
4. Jest + Cypress
5. Vite
Yarn and NPM has been around for a long time. Yarn 1 used to be the better choice since NPM stagnated, now they're a bit more equal.
Typescript has been around for a long time. So has ES6 modules. Same for Jest and Mocha.
The only thing that is changing somewhat are the bundlers and build tools (thankfully, they've been the weakest part of FE dev for a long time).
I've kept up with frontend for many years. There really isn't all that much "fatigue" if one actually understands what the tools do and the niches they fill.
* Should I use npm or yarn?
This is one area where JavaScript is notoriously weak. As another comment mentioned, the answer might be different a couple of years from now. I discovered a package manager recently named `pnpm` and it is incredible, quite frankly. That being said, any package manager will do. They all work well (relatively, npm gets very slow in bigger projects).
* Should I introduce Typescript to be able to handle complexity better?
In 2022, the answer to this is almost always yes, for backend systems. I think this is unfortunate because you do need a transpiler. But its ease of use and type safety are hard to pass up once you've used it on a project. For frontend I tend to be more lax, although a lot of developers argue you should use TypeScript there too.
* Which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?!
Nowadays you'll likely only use `import/export`, especially if you're using TypeScript. This is not a question most JavaScript devs ask on a daily basis.
* Which test framework? Mocha? Karma? Jest? Cypress?
The short answer is it doesn't matter. The longer answer is that if you want assertions and snapshot testing built-in, Jest is a good choice. If you decide to go with Mocha, you'll need an assertion library (most commonly Chai). You probably don't want to use Karma as it was originally designed around Angular 1.x and it's starting to show its age.
Cypress is an end-to-end testing framework and has nothing to do with the rest. You'd use it in place of something like Protractor or Selenium. Additionally if you're using something like GraphQL you probably won't be able to use Cypress without a lot of hardship.
* Should I use a bundler like webpack or just move on to esbuild? Vite? Deno?!?!
This is only relevant in the frontend nowadays. And you'll probably want to use Vite. `esbuild`, while an amazing project, is a bit too verbose to set up and Vite uses it under the hood. IMO Grunt and Gulp and Webpack have never been good bundling systems (I dread every time I have to use these), so any new innovation in this area is welcome.
I see a lot of people complaining about the constant churn. I'm of the opinion that the JavaScript ecosystem is constantly improving. Vite and pnpm are absolutely amazing and I wish I would have had these tools when I was first doing frontend development. I would argue that every year JavaScript development gets way easier, not harder, and now it's the most accessible it's ever been.
Unfortunately, the amount of options can get overwhelming. Off the top of my head, there's a ton of HTTP frameworks (Express, Koa, Sails.js, Hapi.js, Nest.js, etc.) The list goes on. However I don't think this is a fair argument against JavaScript. There's a lot of choice in the Python and Golang world too. Just make good choices (maturity, stability, support) and don't always choose the newer, shinier framework, and you'll seldom run into problems in the JavaScript ecosystem IMO.
I looked at pnpm and I like it... so it's bringing the Maven strategy of having ONE place where dependencies are downloaded to and shared between projects to JavaScript!?.. which has been used since early 2000's in Java land... :D good.
I don't care to implement a forgot password form or api token generation for the Nth time. Give me an 80% solution and then on with the show.
I couldn't even imagine starting with all of these disparate pieces of JS tooling - 10 steps back. Strong defaults and integration give so much.
I genuinely think templates like JumpStartPro are the future of Rails.
https://jumpstartrails.com/
Very high level template functionality already baked in so that you can immediately get to solving the core business issues.
Do people believe this about Angular? Not primarily a front end dev, but in my limited experience with React and Angular, it seems like Angular's strength is that it provides more structure for scaling to larger projects.
It's easy to learn, the code is super clean, TypeScript is great, and imo it generally just makes for a good work environment.
You say this like it's not an 8 year old framework. I wouldn't have such high hopes for it rising significantly.
- The number of round trips needed to render a page needs to go from 3 to 2.
- The amount of JavaScript in the core framework needs to be slimmed down.
The second is already on the roadmap -- they are making Zone.js optional, and supposedly the next version of RxJS is going to be significantly smaller. In order for this to actually happen, Google needs to keep funding the project for at least another full year, which seems likely given how much they depend on it. In terms of the former -- well, it seems increasingly likely that they'll work on adding those kinds of options to the CLI once they get through with the other stuff. And if not, you can alway go back to straight Webpack and just do it yourself. (I personally like the benefits of the CLI and not having to deal with Webpack, but if Webpack keeps improving then who knows, maybe I'll switch back.)
Rails doesn't save you from any of this, none of the back end frameworks do. I prefer writing SPAs because if I prefer to be directly authoring my HTML+JS instead of authoring it indirectly through a framework in a different language.
My hope is that this has been/will continue to change over time, is this a fare statement? Does anyone know if the various working groups (e.g., WHATWG, W3C, etc.) have the goal of making the JavaScript more robust?
My vision is that the standard, built-in APIs would serve as a minimum viable platform that you can build simple to moderately complex applications in with only "minimal" external dependencies.
Because ... variety of reasons, see tis comment thread: https://twitter.com/bakkoting/status/1488363368268251138
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
If you can settle on a good enough batteries-included framework without analysis paralysis, you can make the individual as-needed decisions about libraries without it. It's not a problem of a higher order.
If anything, it's lower-pressure, because the cost of a wrong choice is much smaller.
On personal projects I do whatever the hell I want, in professional projects I always use a framework, to make sure everyone is on the same page and we don't have to bikeshed every simple decision on the road to delivery.
Also, Rails is well known to have Convention over Configuration. That helps to set up and maintain a project since everybody has to follow the same pattern. The cons is that you lose flexibility from the architecture perspective. But in Rails, you have ways to overcome that easily.
I think Rails lost popularity when the front-end JS framework movement started. Rails didn't have a response to that; people had to create the Rails app, remove the Views and use a JS framework to create the one-page app experience.
Now, if you are already spending that much time using JS for the front-end, why not use JS for the backend? But then things got too complex in the JS due to the lack of conventions.
A lot of JS tooling that popped up in the last 10 years is amazing. The React way of building a UI makes a lot of sense to me and I like it way more than HTML + JS combo from the old days. Also, using JS for both frontend and backend is convenient and great for hiring teams.
But, after years of making SPAs, it gets tiring to assemble all of the pieces from scratch every time. I don't want to configure things, I want to build my ideas.
> Next.js, Remix, Gatsby, Vite, Create React App, Koa or Express?
- NextJS, Gatsby - Best for building "websites" that are optimized for SEO
- Vite, CRA, Remix - Best for building SPA's
- Koa, Express - Backend frameworks.
On the one hand it's very overwhelming, but on the other hand, each framework accomplishes something very specific. Even the differences between NextJS and Gatsby, Gatsby uses a different model for how you would fetch data, with Next you write regular Node code, with Gatsby you do everything through GraphQL.
"Next.js", not to be confused with NestJS...
Unlike Rails or even PHP, the JavaScript ecosystem is all over the place. If you choose the most popular tools available, there are many decisions to make. Not everyone wants to do devops.
Because some of us are hardwired to choose carefully. If so, when we have to go buy some groceries we just want to get a decent car and drive. The car and driving itself is irrelevant or minutiae, but we can’t tell whether it could take left turns from the start. When there is no decent car by default, we try to be picky about every component, and when it’s almost perfect, it’s also night and the shop is closed.
It may be easy for you, for a combination of reasons: a huge experience, low perfectionism and high “fuck it, will sort it out later”-ism, and then something else. But it’s not a professional path we used to. Our professional path is to ask someone which car to buy and go buy it. But if you ask someone which js framework to use for regular tasks, you get this thread instead.
On top of that, your resume will miss a 3 years of Winch experience, which suddenly everyone demands when you lose a job or fail your company.
I'm sorry that you understand this from my message. That's not what I meant. good luck with your professionalism.
Personally I’m trying to care less when it is reasonable to do, but even the amount of options where to do that in common js stacks is overwhelming.
For a simple MVP, Rails is enough. As features grow and frontend becomes more complicated, you can then evaluate again if you want to move the rendering part into a separate SPA while retaining Rails as API server.
This was the path that my previous company took.
We need libraries that are less opinionated and more tightly focused, working through standard APIs that are open and composable. As an example, htmx works w/ any back end fine because it's "just HTML". That's great because you can use htmx with any HTML-producing backend without a big conceptual shift on either the front end or back end.
But the downside of that approach is that it is more fiddly and doesn't handle a lot of stuff out of the box (e.g. CSRF protection) that someone who wants it to "just work" expects.
This is where the other side of the barbell comes in: a nice and complete collection of htmx + whatever config is needed for a particular back-end, and all the other stuff that a typical developer might need to just get things running would be really nice. As someone from the java world, maybe just a pom.xml file w/ an init script that sets up the base project, or something like that.
I know I'd like the latter for my java projects!
Also pretty useful when you start a new project and you know what's happening.
I like the choices I get when building with JavaScript. There's always something new to learn and I get to pick the flavors that I like to work with. :)
But I do envy the simplicity of Ruby on Rails. I might try it for my next project after reading this article.
Most React websites did not need React.
Even more so in 2022z
Because it is hard for me to see how you can create a backend API in JS and host it on S3.
I might be wrong as my knowledge in JS is limited.
> Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework.
Granted, I’m in the B2B software space, so end-user expectations are those of accuracy, consistency and performance. I imagine expectations (or perhaps priorities) are different for consumer-facing applications.
[0]: https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
[1]: https://fable.io/
btw. most of the time I wish my company used such things or that code would be more isomorphic, BUT!!! most of the time isomorphic models lead to way more problem, especially when it comes to validation.
1: https://github.com/ferdikoomen/openapi-typescript-codegen
2: https://drf-spectacular.readthedocs.io/en/latest/
3: https://github.com/dotansimha/graphql-code-generator
By the way, echoing some discussion above, we migrated from Express to NestJS, and it was an excellent decision.
After the migration to TS, I really want something I can use to model the data once and use in both the backend and frontend, because its very repetitive. Haven't found anything yet.
I don't feel it's too much of a stretch to assume that most people doing SPA are probably using node on the server and something like Redux. Then it's a matter of "hydrating" the Redux store + React. Which basically amounts to serialization of the data and passing it to the client via a global variable embedded in the source of the HTML page. When done in this manner, the modelling and fetching of data is identical on the client and the server.
> I’m in the B2B software space
Does your software act like an application? I really feel like B2B is the place to use SPA. You have a login, some sort of dashboard, the user interacts and modifies things. SPA is really slick in this use case. Where SPA falls apart is when you need to present your site as individual pages to Google for SEO and try to get some of the benefits of SPA. That's a nightmare to get right and to maintain.
For B2B I would not use SPA on the marketing, landing, pricing, signup pages and use SPA for the application, itself. Effectively a dual site. Which works really well.
But building things with react is frankly the easiest, least complicated and most enjoyable thing that I have ever worked with.
For references I have a decades worth of C# experience, with a gradual transition into Python and now into C# and mainly TypeScript.
Don’t get me wrong, I don’t think you should use a tool that isn’t right for you. If Ruby works, great. If Django works, awesome. Hell, if old customised ASP 3.0 web forms help you deliver the product you need to deliver, then I’m just never going to judge you. I’ve been part of teams that created incredibly business value with tools most people would consider insane after all.
But I think TypeScript is just increasingly useful. The only thing you can’t do with TypeScript, and especially with JavaScript, is Google solutions.
I learned this the hard way when I had to build my first NPM package. It was easy enough, but then it had to work with Azure functions and I entered a world of hurt. As any good senior programmer, I read the documentation and didn’t understand one bit or it, other than GitHub enterprise has replaced NPM enterprise which is kind of shit when you’re using Azure DevOps and not GitHub, but hey, we’ll just put our packages public. I don’t have access to the corporate credit card anyway and getting it takes a week, and going public will enforce a lot of best practices on its own. Anyway, a week later and 9 million Google rabbit holes later, I stumble across rollup and Microsoft’s api for generating .d. type files. Ten minutes later, everything, works effortlessly. But that’s 9 million medium, dev.to, you name it attempts later. It’s 9 million different ts configurations. It’s 9 million package.jsons later.
So I sort of lied when I said that I didn’t get the author, because I do, but the thing is. It’s not really the technology is it? To me at least it’s rather the endless sea of useless “look at me” blog posts that inevitably follows popular technologies.
The # of react apps I've seen where every key press entered into a form takes 200-500ms is super high. Heck the first version of Work At A Startup here on HN had input box latency problems that looked a lot like what I see in React all the time.
It is funny because Redux's religious adherence to a const store makes no sense. Sure it provides a cool debugging trick where you can rewind things, but other than that it seems to just provide an endless hole of performance issues with people using the spread operator incorrectly.
C# and Winforms lets me pump out CRUD apps at literally 20x the speed I can in React. What takes me a day in Winforms can take a month in React. Wish I was kidding there. I once prototyped a website in Winforms, less than day.
I spent 3 days getting a date time picker working across all browsers desktop and mobile with accessibility support working. (Only because Safari doesn't support datetime pickers....)
Web dev sucks compared to desktop development. Hell Java + Swing had higher developer productivity than web dev.
I agree. This is a bit where the lack of frontend seniority tend to show it's colors in my opinion. People try to fit every use case onto e.g. Redux (or the even less competent useState) and then try to throw middleware at it to solve all of the complexity they're drowning in.
Frontend really should utilize more powerful state management tools (when necessary of course), e.g. Observables or Finite State Machines. We're using hammers to solve problems that require screwdrivers.
I just wish MobX was statically typed, so I could know what has been observed by just looking at the usage site, instead of hunting for where the corresponding makeObservable is.
but, what about using Go with its web frameworks(e.g. Gin), it has everything you need to build a web application, and it could be all in one binary, and if you want to scale it's not hard too.
Do you choose ASP.NET MVC? ASP.NET Razor Pages? Blazor? ASP.NET Web API + Angular/React/etc?
I think this article is basically saying "stick to the boring stuff that does what you need out of the box". What is that in .NET land though?
e.g.
Framework - Which .NET framework do you use (Core/LTS)? Do you use MVC, Razor Pages, Web API and Blazor (Server or WebAssembly) or Web API and an alternative JavaScript/TypeScript based frmaework?. Do you use JSON/XML/SOAP or gRPC? How do you serialize your JSON (NewtonSoft.JSON or System.Text.JSON)?
Database - Do you use Dapper, Entity Framework or just utilize a SQLConnection object manually (And then do you use System.Data.SqlClient or Microsoft.Data.SqlClient)? Which database driver do you you use?
Authentication - Do you implement this manually? Do you use something like Identity Framework? Do you use a third party provider like Azure AD(B2C), Auth0 etc. etc.? Do you use header based authentication, JWT's etc. etc?
Jobs - Do you create a separate service project or Windows Service? Do you use HangFire or Quartz?
Email delivery - How do you render your templates? Do you send via SMTP manually or do you use a third party API like Mailgun/Sendgrid etc. etc.
Folder structure - completely up to you, no real standards there.
Testing - Do you use XUnit, NUnit, MSTest, SpecFlow?
There is no "Core" anymore: LTS is now .NET 6. If you are building webpages, the "Legacy" .NET Framework 4.x is no longer relevant in any way (unless you are unlucky enough to have legacy apps with no drive/budget for cleaning up tech debt, and I'm sorry on your behalf). The last LTS "Core" version (.NET Core 3.1) is out of support in December and the upgrade path is simply .NET 6. There's only one choice right now and it is .NET 6. (It'll complicate a bit with .NET 7 in a few months, but only in the alternating LTS/"current" versions way of things like NodeJS, nothing like the Core/Framework confusion of the past few years.)
> MVC, Razor Pages, Web API and Blazor
MVC and Web API merged many moons ago, it's not really a choice between them, they use the same APIs and are built the same way way today.
(Editorializing: Razor Pages is making many of the same mistakes of ASP Classic or PHP/ColdFusion over again, and I don't see it as a great choice personally. Blazor is making similar mistakes to both Razor Pages and Silverlight, and really feels like ASP Classic 2.0. I understand its appeal to some development teams, but wow does it seem like a clunker from my vantage point.)
For authentication, 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 registration/login system with all the required views/models/migrations in a couple commands.
??????????????????????????????????????????? You know that this is built-in, right?
https://docs.microsoft.com/aspnet/core/security/authenticati... https://docs.microsoft.com/aspnet/core/security/authenticati...
also the same choices apply to rails.
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
Svelte works in a way that jives with how I think and work, and I've built enough components for myself that side projects now only take hours to design and build into working prototypes.
I think everyone needs to have a "home platform" where it's just mindless to get started. Regardless whether it's JS SPAs or Rails or raw HTML!
For handling data, it's either Supabase or Airtable's API, hands down. Tailwind for design system.
I've tried Rails before, but as a newbie to Ruby, I couldn't even figure out how to write for loops. To me, that was too foreign, and too much thinking involved. And with Rails, you need to run a server too right? That's even more not-mentioned work.
Ruby has iterators, so you don't need for loops.
list_of_things.each {|thing| thing.dostuff }