Hacker News Reader

Comment by Townley | Hacker News Reader

Recognizing the right tool for the job landed you job security for the next two years (and you're deserve it!)

But it could have very easily gone the other way. If your website had complicated validation rules on multi-page forms (not unheard of in healthcare) the site would be better off for some basic state management interacting with a standardized authentication/authorization framework that you didn't have to write.

From what you're describing, it sounds like you did right by the client in this circumstance. But sometimes, it does have to be complicated. And in those circumstances, frameworks and javascript (unlike garbage) have an important place.

View on HN

> But sometimes, it does have to be complicated.

It almost never has to be complicated. People just enjoy making it so.

Looks at their inventory management system

Everything has an absolute complexity. You can't get rid of it, just move it around.

True. But the absolute complexity of a certain procedure is often not nearly as complex as the workflow that is implemented for it.

If it is just validation a js framework would be overkill.

jQuery would fit well here.

You missed the multi-page forms part. As soon as you have state of some fields affect how other fields or parts of the page display it becomes complex really quickly. There is an explosion of possible states. If you've ever seen code like this, you know why more modern js frameworks were invented:

    onSomethingChanged() {
      $('#foo').prop('disabled', true);
      $('#spinner').removeClass('invisible'); 
      $('#error-1').prop('hidden', true);
      $('.buttons').hide(); 
      if (value) {
        $('#btn-2').show();
      } else {
        $('#btn-2').hide();
        $('#btn-3').show();
      }
      // etc ...
    }

My favorite combination for dead simple sites is HandlebarsJS.

1. Render model from your JS object.

2. attach events

3. Change model

4. Go to step 1

You're just describing MVC which is essentially what most frameworks contain at their core on some level.

I know. I use server side rendering all of the time - well at least until I got back to my safe place doing back end work. It was one project for $reasons I had to use a very light framework that I could copy paste the entire library into the page. I couldn’t depend on the device having an internet connection. I could also precompile the templates.

I think he would model that as POSTing. Server side PHP would render document from scratch from the state.

It's silly to do a round trip to the server just to change some local UI state, right?

Not really, this kind of thinking is exactly what led to the client-side JS framework mess.

Round trips are just fine. Browsers are smart, servers are fast, and HTML compresses well. The site you're reading right now (HN) requires a reload. Stackoverflow requires a reload. Neither are slow to use.

If your page is really that complicated, then I suggest Vue or Preact which are efficient and designed to progressively enhance pages instead of rebuilding everything in JS.

Compression over HTTPS can be problematic, as it makes the key easier to crack.

I would like to trade out AngularJS for Vue someday, though.

Connectivity is not always available, and errors retrieving it may mean you have to re-enter everything. Being able to "navigate" the site without the dinosaur is a tremendous boon for end users. You wouldn't be able to send anything without a connection, but you could buffer it for an opportune moment.

Sites like HN and Stackoverflow have a vastly different audience than most bread-and-butter sites, and tackle different kind of issues.

Most bread-and-butter sites are just fine as server-side rendered page. Large client-side frameworks reimplementing the browser and server functionality should be rare, when the situation actually calls for it.

If you really need a offline site then a simple service worker is all you need to cache the pages, not a big JS app.

"Big JS app"'s aren't that big if done correctly. The entirety of Angular8 fits into ~170KB, less than some thumbnails.

You can write bad apps in any language and environment, similarly a site/app is not bad just because it's done in Y.

Don't underestimate pjax/turbolinks as a first approach. This way you get to render on the server without refreshing the whole page. For most business websites this is more than enough to keep rendering snappy.

In theory, yes. In practice, by the time you get your whole web-app game on, the full round trip is often at least as fast, and frequently faster.

Depends on the app. In some cases it results in a much simpler and easier to maintain environment (ie, Larvel or Symphony will do this better than Angular...)

On a side note, all that complexity in the example could be managed with adding/removing a single CSS class :p

Yeah, I didn't really try to make it realistic. But I've seen very similar code, it would maybe reset inputs, calculate some results, stuff you can't really do with a single css class. T

Reply on news.ycombinator.com