Hacker News Reader

Comment by peteforde | Hacker News Reader

Honestly, when I read this kind of thing, I have absolutely no idea what would compel someone to throw away the MVC framework of their choice to logarithmically ramp up the complexity of their apps. Most things that people build don't need anything like this. It is of great concern that code bootcamps are now teaching JS frameworks as the default expectation.

I guess it'll be more project work for those who get brought in to bail these projects out.

View on HN

I head to re-read your comment 5 times before I understood that by "MVC framework" you mean "thing that renders HTML on the server".

Admittedly it's a bit of a beef of mine, but most React apps are very MVC. I even blogged about it a while ago: https://blog.talkjs.com/how-react-brought-model-view-control...

I am an EE doing some web development on the side. Since a few weeks ago, my stack was mostly Flask (backend) + JQuery (frontend). My web apps were always light on the front end. Then I wanted to experiment with React. So far, I really like the declarative component design but don't like the Single Page App approach. Is there a way to render components on the server for each page individually without having to set up a new react project/web pack build step for each page?

The search term you want is 'react ssr' or 'react server side rendering'

Followup question. Does it actually make sense to use React and render it server side only to get declarative component design?

I can totally see the use case for React for web apps which provide a lot of user interaction on the frontend. But for all other web apps it doesn't seem to make sense as you also have to handle quite a few disadvantages (e.g. SEO unfriendly, user can't copy URL and send to a friend)

Am I missing something?

Next will manage your URLs and all the SSR does is generate static files for each page with the base data and loader so future requests grab static JSON versions of the pages. There is no need for it to be rendered in the server. You could do it locally and push the resulting files up. URLs will work as you expect them to.

There's a good chance you're not missing something - Lots of people don't like SPA's because the consistency of a normal website isn't there. The best SPA's I've used don't actually feel like SPA's and it's worth mentioning that no one seems to mind Amazon/Github/Youtube not using React/Vue/Angular

Gatsby JS is worth a look. It's basically a framework to create static pages server side, with React's constructs and tools.

You can even use data from your Flask based backend directly, to create the static pages.

Next.js (https://nextjs.org/) lets you render pages on the server but have your React app behave normally after that. It's potentially useful for SEO and reducing latency for final page display.

https://reactjs.org/docs/react-dom-server.html#rendertostati...

    Most things that people build
    don't need anything like this.

True. It would be great to show examples of websites that benefit from the complexity of an extra library to handle client side state. I would think less then 1% do.

For example, lets look at how HN handles state syncing. Function "toggle" in this file handles collapsing/expanding threads:

https://news.ycombinator.com/hn.js

    function toggle (ev, id) {
      var on = !afind($(id), collapsed());
      (on ? addClass : remClass)($(id), 'coll');
      recoll();
      if ($('logout')) {
        new Image().src = 'collapse?id=' + id + (on ? '' : '&un=true');
      }
      ev.stopPropagation();
      return false;
    }

How would the react+redux approach look like? Is it really worth it?

React+redux (or just react) doesn't add much to websites. Maybe Vue.js would be a better fit when some complexity is needed in a website.

I see React as a tool for building web applications, not websites. Using it for something like hacker news is not needed nor worth it, except for learning purposes or for the sake of using your favorite tech (which has its pros and cons).

Edit: I use React a lot, and really like it. It's just not the perfect tool for everything, and by no means a necessary one (at least when you don't have much complexity); even if it is a good one in many cases.

In the case of HN, seeing the current js [1] I find it pretty obvious that no "big tool" like React is necessary. It doesn't mean using React for a HN clone is a bad thing, one just don't have to.

[1]: https://news.ycombinator.com/item?id=17915560&goto=news

In my book, "website" and "web application" are equivalent.

How do you define those terms?

Imo, not all websites are web apps. You can certainly still create a static website using just HTML. The term "app" to me implies functionality beyond the presentational.

I don't define them precisely either. I'll borrow an answer from stack overflow [1]:

This is totally personal and subjective, but I'd say that a website is defined by its content, while a web application is defined by its interaction with the user. That is, a website can plausibly consist of a static content repository that's dealt out to all visitors, while a web application depends on interaction and requires programmatic user input and data processing.

For example, a news site would be a "website", but a spreadsheet or a collaborative calendar would be web "applications". The news site shows essentially the same information to all visitors, while the calendar processes individual data.

Practically, most websites with quickly changing content will also rely on a sophisticated programmatic (and/or database) backend, but at least in principle they're only defined by their output. The web application on the other hand is essentially a program that runs remotely, and it depends fundamentally on a processing and a data storage backend.

[1]: https://stackoverflow.com/a/8694944/7510753

Most web applications don't need a JS framework either, so the distinction's actually worthless.

Web applications have interactive functionality as their focus. Websites have the consumption of what a human, and not an HTML parser, would call a "document": video, text, and images. They may not be statically served, but their code exists to facilitate the serving of what are recognizably documents.

Wordpress's backend is a web application. That web application exists to drive the website that is its frontend. Not really a controversial standpoint, I don't think, except amongst the hyper-literal who but-for about comment features (hence the use of "focus" above).

The guy who builds your website has never heard of big O.

I build content driven websites as part of my job (not my favourite part by any means). I’ve most certainly “heard of Big O” - something they teach you in the first year of any university-level computing course.

Don’t be a dick.

I wasn't being a dick, most designers and people who bill themselves out as website creators come from a creative background instead of a development background. For every 12 website creators I know with a photography/art/graphic design background, I only know one with a C.S. background.

Once you're using React for a web app, the cognitive load is not that high to use it to blam out a site, too. And it need not be slow or heavy, either; the website I'm currently working on uses React for rendering (both server-side and not, but it took me about an hour to get server-side rendering working for something where the very minimal state is only presentational) and has about a 60KB-gzipped JavaScript+CSS+images bundle all-told. (Of that, React is 5KB. Woo?)

I could use Vue, but I'm already using and continuing to use React, and I'm good enough at (what isn't actually) my job (because I'm no frontend developer, this is just what I do on the side) to minimize its impact on end users.

I also use React for fully static sites via Gatsby, though I don't love it, and to quickly build HTML mail templates. Granted, the bigger value here for me is JSX rather than React, but for my use cases they're functionally the same thing, and I do think you can get a lot out of using it. Especially if elsewhere in the stack you're already undertaking more complexity with it.

If you don't love Gatsby, you could try out https://github.com/nozzle/react-static

I've looked at that too, but to be honest I find it confusing. :/

Just to echo expand on TekMol's reply as he's been downvoted for perhaps being too curt, but the distinction's essentially worthless as most web applications don't need the complexity of a big js framework either. When he says websites, he means web dev in general, no distinction necessary.

That’s easy, it’s <Thread/> plus a bunch of code that I’ve omitted :p

JS can follow MVC / OO model. Simply most people don't try to do it and go with functional approach; add to this simplicity JS can be diven into, and you get the results we get where people cry that JS (jQuery) gives unmaintainable code. Reactive libraries try to address the issue by forcing you to create OO components and (to a degree) MVC patterns.

Me neither, Java and .NET MVC frameworks forever! :)

Reply on news.ycombinator.com