Hacker News Reader

Comment by codingdave | Hacker News Reader

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.

View on HN

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.

I'll pick just one point to address:

> 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".

And god help you if you want to get anything to work just a little bit differently from how the "one command" chooses to set things up.

Like, create-react-app is great, but if you have to eject, you've got no parachute

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.

> Everything else is a given.

Would you please send a link that summarizes this "everything else"? Every time I take a look at JS ecosystem I get lost.

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.

I don’t understand this sort of criticism.

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.

>Maybe 5-10 years ago, there is no need anymore

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 mostly agree with your other points.

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.

Agree with everything, but saying Next.js is just enough to create a static page is quite the strech.

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

Last I looked the rails like JS framework was https://adonisjs.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.

I think it’s the closest to rails in philosophy where they aim for sane defaults and one way to do things and also prioritize the dev experience

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

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.

Yeah it feels like this NextJS opinion is very out of date.

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.

I agree ember had issues in the past, but it's come a long way and the latest version Octane/4.0 is pretty solid.

For anyone curious linkedin.com is a massive ember.js app and they're big contributors to the project.

Remix feels a bit like Ember routing, but with SSR and React.

I think almost all modern SPA routers took a lot of lessons from the Ember router to be fair.

I wish!

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”.

This, 100% this this this this this.

Agree, and to go further (from the point-of-view of an outsider who is forced to do JS occasionally):

* 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)...

Great questions. 3 years from now you will have completely different answers.

> * 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.

This is a pretty huge assumption.

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.

It's too fine grained.

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?

The answers to this in 2022:

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

* Note: this is only valid for the time of writing. We cannot guarantee these libraries will still represent the state of the art past this date.

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 for many people NextJS or Nuxt should really be the first choice rather than going for e.g. Create-React-App or some generic boilerplate.

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.

Thanks, this was helpful.

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.

Have you tried Deno? if you hate setup and want it all to just work. I highly suggest it.

Why wouldn't you just use a JS framework that takes care of all of those questions for you?

As you start going down the path of developing a SAAS, I've even reached the point where Rails isn't enough.

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.

> 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.

> And it should only be getting more performant as they put more working into optimizing it.

You say this like it's not an 8 year old framework. I wouldn't have such high hopes for it rising significantly.

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.

"Javascript has such a minimal standard library"

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.

You hope and you hope... and then they ship a Set without any useful built-in methods: https://exploringjs.com/impatient-js/ch_sets.html#missing-se...

Because ... variety of reasons, see tis comment thread: https://twitter.com/bakkoting/status/1488363368268251138

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.

[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

> 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.

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.

Meteor comes to mind

RedwoodJS may be something you want to check out.

https://redwoodjs.com/

Agreed, I think it is the explicit goal of the project to get that same batteries included feeling of Django/Rails

Yes, RedwoodJS seems like Rails for JavaScript.

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.

Without knowing if it's possible, I really want to see a RedwoodJS w/ Remix proof-of-concept.

That would be awesome.

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.

Love using NestJS. It's true that most places are stuck using express for whatever reason so you have to be a bit ahead of the pack.

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.

If anyone else is feeling this pain please consider using this template https://cookiecutter-django.readthedocs.io/en/latest/

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:

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’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.

> 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.

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.

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.

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().

My milage does vary.

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.

Reply on news.ycombinator.com