You may have a look on VueJs as a lightweight alternative to React/Angular when you need simple apps to create like the one you mentioned , it is like jQuery but with very exciting features https://vuejs.org/

https://vuejs.org/guide/comparison.html

https://hashnode.com/post/choose-between-reactjs-and-vuejs-f...

I hear you on this. A lot of that stack is very new and still changes quickly enough that I have a hard time finding good examples to work from.

I've had a very hard time getting things like react+react-router+reflux to all work together as expected. It's not been super fun as a way of working.

And I dunno if your situation is the same as mine, but all the "contemporary" JS stuff I work with (react, etc) is for side work, that is, stuff that I am building explicitly because I want to play with the stack.

So the reaction that "you don't need all that" is probably missing the point (at least if your situation is like mine): I do things like that because I want to see how stuff works, and it's better than doing it on my $$$ projects.

Our situations are very similar. For me it's just a way to play with React. I don't expect to use it at work or to make me any money.

I do expect to use it for my work.

But at this rate it seems like it needs to mature a bit and settle down before I should use it.

> I honestly loathe how much crap I'm loading for two pages: sign-up / register.

Sorry, but this is entirely your fault. You don't need any of what you mentioned to do this. You can just use jQuery if that works for you. No one except really bad junior devs on here or Reddit will say you are doing things "wrong".

PS: Use fetch instead of superagent.

You're right, the over-engineering is entirely my fault. I love the re-usability of HTML components that I get with React. I'll work this week on removing all other dependencies and server-side rendering and see if it's something I can live with.

Fetch support is awful. Rachel McAdams knew the future.

If someone else (like me) misses the Rachel McAdams reference: https://jakearchibald.com/static/posts/thats-so-fetch/fetch....

Blog post - https://jakearchibald.com/2015/thats-so-fetch/

+1 for fetch. Use the good github fetch polyfill for old browsers https://github.com/github/fetch

I tried fetch, the polymorphic-fetch module that builds on this github one and found it doesn't support .finally(), or work with the promise.finally polyfill (yes I know it's not in the spec, but seriously).

Also sinon.js couldn't mock it, and dealing with error cases is inelegant (it doesn't look like much extra code, but is hard to justify if you're just writing a small component that hits one endpoint, in terms of weird new code to explain to your teammates that is).

I have gone back to $.ajax for now, though I do mean to try out qwest [1] when I get the chance. Seems to be both tiny and also have a sane promise-y API.

[1] https://github.com/pyrsmk/qwest

Why you want stuff which is not in the spec? It's not in the spec it's not in the polyfill :/ Why the fetch from Github is not good enough for you?

Because needing to do something regardless of success or failure is incredibly common (e.g. stop a progress bar, re-enable form inputs & buttons).

The (promises) spec is lacking w.r.t. this use-case, and most ajax libraries (and a lot or promise libraries) recognise this by implementing a 'finally' equivalent.

Plenty of polyfills out there. I mentioned it because it's a lot lighter than superagent or worse, request.

Honest question, what is wrong with request (and superagent)? Is it just size or something more? I am only asking because yesterday I was looking for a promise supported library and I was comparing superagent (with its promise wrapper), request-promise, axios and node-fetch. I have narrowed it down to axios and fetch but I would like to hear your opinion on the matter.

The size. For a Node app, maybe not so bad (though I'd use node-fetch or got[1] which are smaller). For a browser app, loading all of superagent (which is almost 2 megabytes) just to make a few GET and POST calls is silly.

Never used axios but I've heard good things about it and its creator is awesome. I just use fetch because it does what I want.

[1] https://github.com/sindresorhus/got

Wow, had no idea that request was so bloated. And thanks for mentioning got. I just checked it out and I think that is the lib I will be going with on the backend. I love the stream support, very cool.

Curious - why are you using React and all of that for a simple 2 page project? Is it for the learning experience? Seems like way overkill unless its for the learning experience.

how did you get that idea?

he needs most of the libraries only on two pages: login and register. i sincerely doubt his site only has these two.

"doing things right"... by whose standards? It blows my mind how convoluted everything has become due to "doing things right" and "best practices". It's a side project, keep it in perspective. The faster it gets done, the sooner you can refactor IF you need to refactor.

If you know the site is small why do you do the pain and go react, router and fluxible etc. etc. ? The investment in this (huge) toolchain will be beneficial when you start making things more complicated... then you may hit a wall with normal jQuery/JS. But not every project needs a big React based toolchain. This is definitely a JS platform problem. I'm currently looking at Elm because it makes life easier in comparison... but there you have other gaps like not good jQuery plugin interaction.

This sounds like a big deal but that is effectively what you have to learn either way. The difference is that one is built in a competitive landscape and the other is done in a big god object.