You probably don't need a single-page app • Hacker News Board

Re: You probably don't need a single-page app

#171

Post by petilon » Sun, Feb 17, 2019, 5:06 PM UTC

s_y_n_t_a_x wrote: post #148

petilon wrote: post #124

Earlier quoted context omitted.

Then you aren't benefiting from React at all. The point of React is DOM diffing, which you trigger using setState method.

When you change the props of a component it re-renders. Just because you use pure functions doesn't mean you don't get DOM diffing, that's silly.

At some point you have to have state. See where "state should live" here: https://reactjs.org/docs/thinking-in-react.html

But the very fact that we're having this debate is proving my point. React's programming model is unnecessarily complicated. JavaScript + DOM is all you need. The simple libs (each less than 500 lines) I pointed to get you close to this without sacrificing productivity or code maintainability while keeping the programming model simple.

Re: You probably don't need a single-page app

#172

Post by ec109685 » Sun, Feb 17, 2019, 5:06 PM UTC

zokier wrote: post #113

This is a tangent, but is Github really still mostly ssr? It sure feels more spa-like these days, full with their own loading bar.

They use turbolinks to hot swap the html.

Re: You probably don't need a single-page app

#173

Post by asaddhamani » Sun, Feb 17, 2019, 5:07 PM UTC

I agree with this so much. These days, the first thing developers will do when making a new app is setup babel + webpack + react + redux, then make an API, all for mostly CRUD applications.

Most applications don't require these frontend frameworks, and it just adds needless complexity in most cases. I've suffered due to this, and so I've recently made the move back to server rendered apps.

And Rails with Turbolinks + UJS might not perfect, but it gets you like 80% of the way there for 10% of the effort.

Re: You probably don't need a single-page app

#174

Post by [deleted] » Sun, Feb 17, 2019, 5:08 PM UTC

[deleted]

Re: You probably don't need a single-page app

#175

Post by johnchristopher » Sun, Feb 17, 2019, 5:12 PM UTC

burlesona wrote: post #147

johnchristopher wrote: post #51

> Gulp, CoffeeScript, BackboneJS, and SASS, all of which have been superseded by newer tools. Avoid the Javascript fatigue by not relying so much on Javascript! What ? These are all javascript things, right ?

That was his point. The rails stuff he learned five years ago is all still considered good practice, but the JavaScript stuff he learned (listed above) is now considered antique.

Oh, thanks. I somehow totally misread that and thought he meant those JS tech were still relevant.

Re: You probably don't need a single-page app

#176

Post by rorygibson » Sun, Feb 17, 2019, 5:12 PM UTC

1) CRUD / data entry systems: stay with request-response.

2) Complex webapps with snappy functionality that need to feel "native" - whatever that means: think about an SPA. Then realise that mostly what you need is (1).

3) Corporate homepages / brochure sites / product sites / blogs: use a static site generator like Hugo, Jekyll etc. It's amazing what you can do with a staticgen site now

[Insert shameless plug for Trolley, my product, https://trolley.link ]

Re: You probably don't need a single-page app

#177

Post by criddell » Sun, Feb 17, 2019, 5:13 PM UTC

tyingq wrote: post #22

IloveHN84 wrote: post #18

Earlier quoted context omitted.

Native will always be the best solution... Because it's native.

Technically best doesn't always win the market. I'd love not writing 3 versions of every piece of functionality.

I'm sure it's nice for you, but users like me aren't happy that every mouse move and page load is cataloged and studied and shared with partners. At least with a native app I can add a firewall rule to restrict it's ability to use the internet.

Re: You probably don't need a single-page app

#178

Post by lucasverra » Sun, Feb 17, 2019, 5:14 PM UTC

s3graham wrote: post #97

tyingq wrote: post #94

Earlier quoted context omitted.

There's a single file that's 584KB of javascript from hangouts.google.com in the "full experience" Gmail. Blocking that seems to help, a lot. I imagine there's probably some configuration to turn off hangouts that provides the same benefit.

It's in Settings.

chat off ?

Re: You probably don't need a single-page app

#179

Post by Novashi » Sun, Feb 17, 2019, 5:14 PM UTC

kissgyorgy wrote: post #162

marktangotango wrote: post #136

Earlier quoted context omitted.

I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better…

> I would note that generally server side templating is often a mish mash of business logic If you don't have good, experienced senior developers or they don't have discipline, yes. But that's true for any technology. Good developers have the knowledge for simple things like how to separate business logic from templates...

TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less.

It would be nice if, given a task, we could teach people to choose the right approach in code the first time, but given we still have trouble recognizing good developers, the fast-paced churn of rewriting apps is a decent hedge until we figure out how to train the people we want.

We seem to only want developers with this skill, but then force them to rewrite stuff often enough so that no actual long-term gains can be realized from their expertise.

Re: You probably don't need a single-page app

#180

Post by buu700 » Sun, Feb 17, 2019, 5:15 PM UTC

burlesona wrote: post #147

johnchristopher wrote: post #51

> Gulp, CoffeeScript, BackboneJS, and SASS, all of which have been superseded by newer tools. Avoid the Javascript fatigue by not relying so much on Javascript! What ? These are all javascript things, right ?

That was his point. The rails stuff he learned five years ago is all still considered good practice, but the JavaScript stuff he learned (listed above) is now considered antique.

I think the general point holds up, but why is sass in that list? I know some newer alternatives are used with React nowadays, but sass is still very much a best practice in general as far as I'm aware.

(If he means SASS vs SCSS syntax, I recall using SCSS ~8 years ago, so it's an odd choice to include either way.)