Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

None of my projects want to be SPAs

whatisjasongoldstein.com

Post reply on HN
Print view View original

311–320 of 362 posts

Re: None of my projects want to be SPAs

#311

Post by mamcx »

alecigne wrote: post #258
mamcx wrote: post #94

Another angle is that "SPAs" are build on top of a fragile and anti-engineering tech stack: JS, CSS, HTML. In the past a 'SPAs' was build on top of more solid foundation like smalltalk or later Delphi. Most issues is that the browser stack, put it in real terms, is not the "right tool for the job" and will never will, without serious re-engineering.

Could you provide some links/keywords about these alternative solutions? This sounds very interesting but I don't know were to start.

Is unclear to me if you talk about Delphi and smalltalk?

Re: None of my projects want to be SPAs

#312

Post by acemarke »

korm wrote: post #302
kerkeslager wrote: post #200

Earlier quoted context omitted.

> Redux is not great for simple projects, it is great for medium and large scale projects. I'd say that the only times I've seen Redux work effectively at all is when the project was small enough that the complexity remained manageable. > > All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. > That's the problem: react and redux are not enough for l…

> but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem I'm a consultant and in my experience this misconception is by far the most common source of problems in redux projects. Redux is a very small and simple thing so you have to build a framework around it. Even redux-thunk isn't enough - that's only 5 lines of code. I wouldn't recommend react/redux for public fac…

Hi, I'm a Redux maintainer.

FWIW, we've got a new Redux Starter kit package that tries to be a bit more "batteries included". It includes utilities that help simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state automatically. It also includes `redux-thunk` built in, as well as some middleware that check for things like mutations.

Please try it out and let us know what you think!

https://redux-starter-kit.js.org

Re: None of my projects want to be SPAs

#313

Post by rashkov »

pault wrote: post #233
kerkeslager wrote: post #201

Earlier quoted context omitted.

Why use a tool to solve a problem with another tool, rather than using tools that don't have the problem in the first place?

The problem that you end up with past a certain scale in a component-based app without a state management framework (third party or your own) is that you're performing business logic inside view components. By moving your business logic into your state management framework and using something like redux-saga that is designed specifically for managing complex asynchronous workflows, you can extract your application co…

Great points all around. One question though — how many apps actually need to share state across pages? Seems like mobile apps have this problem more than desktop apps, because their screens are small and so the UI must be split into pages. Whereas a large monitor can support an expansive UI that isn’t “split up”. So if you’re making a desktop app, what would you use instead of redux? Seems like your points about splitting off business logic, debugging and testing all still apply when the state is confined to a single heavily interactive screen with complex state.

Re: None of my projects want to be SPAs

#314

Post by em-bee »

wolco wrote: post #290
em-bee wrote: post #244

Earlier quoted context omitted.

exactly that. since 2012 i build all my websites as SPAs for this reason. more so, i am not even writing any new backends. i reuse the same backend over and over. most websites (at least the ones i have been building) are just CRUD and don't really need a custom backend. SPAs bring back the client-server architecture we had before the web. you build desktop clients that consume server-api's. server-side html generati…

You are falling into a comfortable trap where it is easier to do the same. If you took the time to learn laravel your development time can be cut in half.

the backend i have is of course written in such a framework. (it's not laravel[0], but it could be)

i am not trying to diss backend frameworks here as bad. any of these would be a good choice for the backend.

the point is that thanks to SPA and CRUD i get to reuse that same backend over and over with little or no modification. (modifications amount to fixing bugs and very rarely adding new features to the API)

my backend development time now is effectively 0!

[0] (i have been working with laravel, django and others (primarily roxen and pike) before, and while i am not a fan of php, i did find laravel pleasant to work with)

Re: None of my projects want to be SPAs

#315

Post by nojvek »

rossdavidh wrote: post #108

This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails/Django/Laravel way, but that would not set you up as a developer w…

I don’t get the hate against SPA’s. An SPA done right offers amazing interactibily and instant navigation to new views. You already have the templates cached. They probably load from a cdn with good caching policy. If done well you can totally run offline.

Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use.

This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu.

The UI can manage the state in very responsive manner. No round trips, instant 60fps render.

And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries.

Don’t throw the baby with the bathwater.

Re: None of my projects want to be SPAs

#316

Post by nojvek »

slifin wrote: post #178
kerkeslager wrote: post #119

Earlier quoted context omitted.

Yeah, some people go so far as to directly claim that something is good because Google uses it. And when Google uses it, it probably IS good for solving Google's problems. But most people aren't Google and don't have Google's problems.

Do Google still use their closure library + compiler on all their big properties? https://github.com/google/closure-library/ I'm learning Clojure at the moment, don't think I would have heard of Google Closure otherwise

Closure language and closure compiler are two different things. One is a lispy functional language with its own syntax, the other is a jsdoc typechecker and optimizer/monicker.

A lot of what clojure does, Typescript does it really well with it’s types in jsdocs.

Re: None of my projects want to be SPAs

#317

Post by slavak »

sangnoir wrote: post #191
mixmastamyk wrote: post #179

Earlier quoted context omitted.

What about tabs? SPA can make tabs troublesome. If I can't open a site in tabs it is broken to me.

Browser-side routing/state management is a solved problem - SPAs can make tabs troublesome if the developer didn't put in the effort.

For God's sake, STOP trying to re-implement my browser's interface with Javascript! I don't want you to "put in the effort" to make my URL bar, back/forward buttons, and tabs work the way they naturally do in my browser; that's what my browser is FOR! Even when the developer does put in the effort, the results are usually _just_ different enough in various subtle ways from the browser's native behviour as to be annoying.

Just build a normal website and let my browser do what it was built to do. The APIs that allow SPAs are great and useful. The Pixlr online photo editor has a good reason to be a SPA, and that works great for it. Your forum/email interface/management API would work better as a normal website.

Re: None of my projects want to be SPAs

#318

Post by wilsonthewhale »

nojvek wrote: post #316
slifin wrote: post #178

Earlier quoted context omitted.

Do Google still use their closure library + compiler on all their big properties? https://github.com/google/closure-library/ I'm learning Clojure at the moment, don't think I would have heard of Google Closure otherwise

Closure language and closure compiler are two different things. One is a lispy functional language with its own syntax, the other is a jsdoc typechecker and optimizer/monicker. A lot of what clojure does, Typescript does it really well with it’s types in jsdocs.

They're related. The ClojureScript compiler uses Google Closure as a backend and runtime library

Re: None of my projects want to be SPAs

#319

Post by korm »

acemarke wrote: post #312
korm wrote: post #302

Earlier quoted context omitted.

> but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem I'm a consultant and in my experience this misconception is by far the most common source of problems in redux projects. Redux is a very small and simple thing so you have to build a framework around it. Even redux-thunk isn't enough - that's only 5 lines of code. I wouldn't recommend react/redux for public fac…

Hi, I'm a Redux maintainer. FWIW, we've got a new Redux Starter kit package that tries to be a bit more "batteries included". It includes utilities that help simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state automatically. It also includes `redux-thunk` built in, as well as some middleware that check for things like mutation…

Thanks, this is incredibly useful, I use everything in this package! It also doesn't deviate from the spirit of Redux or abstract too much, like rematch for example. Without something like this, I find that many people structure their entire Redux code based on simple tutorials. They typically only read the docs or worry about best practices and complexity after they encounter problems. This kit will have them start off on the right foot.

Re: None of my projects want to be SPAs

#320

Post by [deleted] »

geebee wrote: post #188
GVIrish wrote: post #180

Earlier quoted context omitted.

> This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Unfortunately this is another side effect of the broken hiring process in IT. Recruiters are scanning resumes for the hottest buzzwords, hiring managers want people who have experience with whatever is currently hyped, so developers naturally steer towards those technolo…

I agree. It's also not simply a matter of making more money on the next job, it can be a matter of having a next job.

[deleted]
Post reply on HN