Hacker News Reader

Comment by cateye | Hacker News Reader

For most use cases, I wouldn't advice actually a JavaScript framework.

The author is seriously suggesting Next.js to build a company website.

In a lot of "website" scenarios, it makes much more sense to choose a CMS like WordPress, Drupal, Django-cms etc.

In case of a custom application development, frameworks like Ruby on Rails, Phoenix/Elixir or Django is usually a smarter choice.

Next.js is not necessarily a good fit for every problem, and it may be more suited to a specific subset of problems than is often assumed.

View on HN

> The author is seriously suggesting Next.js to build a company website.

There are massive, hyper-scale websites built on Next.js: Walmart, Nike, Hulu, Notion, just to mention a few. [1]

Are they not "serious" to you?

[1] https://nextjs.org/showcase

I think they mean "website" as in "static pages of content". Those are all web applications.

Many of these examples use Next.js to support their static content (eg, marketing). Maybe they mean that it's overkill for smaller projects or customers (eg, SMEs) which I would tend to agree with (although, there are Next.js low-code/CMS services emerging, like Builder.io or Plasmic) but for larger companies that have the JS web dev talent it can make perfect sense to do their marketing sites on Next.js. I've also served a small business (an agency) that wanted to do very funky stuff for their marketing site - Webflow or Wordpress certainly weren't going to cut it, so Next was a good fit.

Using a javascript/typescript framework to build static sites is so common place now that I'd even go as far as saying it's the standard.

Frankly, I hate working with raw HTML/CSS. It sucks. Using TSX is such a better developer experience. I'm much more productive in a nextjs app, even if it's just static, than I am with plain old markup.

That's because you're looking at the wrong alternatives. check out Hugo

Not seen Hugo, but Htmx is looking interesting.

In the last few years I've moved away from JavaScript and frameworks in a lot of cases because writing raw HTML and CSS was not cumbersome, involved vastly simpler tooling, and didn't involve other folks needing to learn some obscure framework that may have gone out of fashion. HTML and CSS are here to stay and currently they serve their purpose very well. I don't agree with your take (J|T)SX obscure the HTML whose trench coat it's trying to wear with arbitrary rules that produce unexpected effects. If author HTML is considered a burden, I'm not sure how keeping something XML-like is going to make the ergonomics or readability better.

I'll take those arbitrary rules if it lets me use component-driven design unlike raw HTML/CSS does. Very much a worthwhile trade off.

I'd say this really is an opinion, those choices have deep technical implication and are highly contextual. Next can also act as a backbone or "backend for frontend", it's not incompatible with using a CMS or building a custom application.

In a lot of "website" scenarios, it makes much more sense to choose a CMS like WordPress, Drupal, Django-cms etc.

There's no reason why you can't use those with a JS framework though. A CMS for the website content team to modify content, with a static site builder process that runs when content changes is a very common approach. You can use Next for that. And it can be entirely static, with no JS delivered to the end user at all. That gets you all the benefits of a CMS, with all the benefits of a static website, and none of the security hassles of running a public-facing Wordpress site.

I think we are talking specifically about server side rendering, which is a subset of server side functionality covered by a wide range of languages and frameworks, some of which predate things like node.js by quite some time, Like php, which literally started out as a server side template rendering language end of last century. Php and Javascript emerged around the same time if I remember correctly. I never was a big fan but it remains extremely popular and still runs quite large part of the web.

I'm not super opinionated on what people pick other than advising to not get tunnel vision and only consider one language. Also, static code generation and server side rendering are two very different beasts. Server side rendering of course can be as simple as just a static code generator where you don't actually persist the output (i.e. it's dynamic). But usually there's a bit more to it and you get server side views, caching, and a whole lot of other stuff that people forget about that is actually needed in a server application such as logging, database and other middleware integration, authorization and authentication, etc. Once you figure out you need all of that, a "lightweight" framework that isn't particularly good at any of that might not be the obvious first choice.

It's why javascript is much less of a mainstream choice on servers than it is in browsers. Yes you can use it and lots of people obviously do. But there are countless other very mature and well established technologies that you can choose from as well. And most of those can do server side rendering pretty easily as well as it is not that big of a deal to actually implement. If you need it.

I think the specific attraction of javascript based frameworks for frontend developers exploring getting into backend functionality is that they can use the same tools and frameworks that they were already using client side. Specifically react users seem to be looking for ways to use react on servers.

These do completely different things. It’s like saying “I wouldn’t advise using CSS, use HTML instead”.

I get what you are trying to explain but this analogy is completely wrong. It would mean that the two subjects are complementary and are often used together which is clearly not the case.

While a JavaScript framework like React can be used to build a company website or CMS, it is often not a good idea to use React to do this.

Off course this is highly context specific and depends on the particular requirements of the "company website". Without a strict definition of what it is, it will be always a discussion about an ambiguous and moving target.

The choice also depends on the technical knowledge and experience. For someone with years of experience with Javascript and really an expert on it, it might be still a smart choice. Or maybe we are not talking about 1 developer but a team of 10 developers etc.

I was just trying to suggest that this is not often the case.

> The author is seriously suggesting Next.js to build a company website.

Hi, I'm the author :). I wanted to highlight this recommendation has the modifier "If you'd like to learn something new". This very subjective recommendation is solely based on the exciting mix of rendering options, the vast popularity, and my preference for JS and React.

You're spot-on when you emphasize that there are web applications that are a different beast anyway and websites that run perfectly fine with a CMS in the background.

> These do completely different things.

That's exactly the point I see...? To build a website (as opposed to a web application) with mostly static content and maybe some interactive embedded content, do not use N*xt.js. Use a CMS or static site generator or whatever instead. Without any fancy client-side URL routing and whatnot. Just let the browser do its thing.

That being said, some frameworks support a SSR-only approach or even static site generation. That's also fine IMHO. Just use what you like! If you like Ruby on Rails, why not? Angular SSR? Gotcha.

I tried multiple tools like Jekyll and Hugo but found them terribly clunky. Then I found Astro and now I'm happy. Reasonably similar to SPA frameworks, but generates a static site.

If your developers are already familiar with React, I think next makes a lot of sense for a corporate website. When used as a static site generator, you can reduce a lot of complexity over wordpress et al. because you don’t need a database and can deploy directly to a CDN.

Reply on news.ycombinator.com