Comment by carsongross | Hacker News Reader

Comment by carsongross | Hacker News Reader

I get where the guy is coming from, I'm right there as an old guy.

On the other hand, I think there is a bit too much fatalism in the article. Sometimes the kids are being stupid, and they need to be told so.

The vast majority of web apps could be built in 1/10th the code with server-side rendering and intercooler.js. All this client-side crap is wasted when you are trying to get text from computer A into data-store B and back again. It's the front-end equivalent of the J2EE debacle, but with better logos and more attractive people.

And people are starting to wake up[1][2]. It's up to us old guys to show the way back to the original simplicity of the web, incorporating the good ideas that have shown up along the way as well as all the good ideas[3] that have been forgotten. Yes, we'll be called dinosaurs, out of touch, and worse.

Well so what? We're 40 now. And one of the great, shocking at first, but great, things about that age is you begin to really, truly stop giving a fuck what other people think.

Besides, what else are we going to do?

[1] - https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...

[2] - https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

[3] - http://intercoolerjs.org/2016/01/18/rescuing-rest.html

Old guy here too. When I was a younger guy and first saw the web, after making a few web pages I naturally wondered "how can I program this?" At the time, the old guy programmers were old mainframe / terminal architecture guys, where a dumb terminal (teletype or monochrome) sent text to and from a smart "central processing unit". It was natural for them to follow server-side patterns, and invent PHP, NetObjects, ColdFusion etc. But as I'd started out in the eighties with BASIC, Pascal, Delphi, VB etc. writing stuff that ran on these "personal computers" I tended to think more about writing UIs that ran where the user actually is. Although I dabbled with various server techs, my real interest was on the front end, with Applets, ActiveX, DHTML, WebClients ... all ultimately flops of course. Then Flex RIAs, which ruled for a couple of years but were killed by mobile.

I mainly work with Angular now, React didn't quite float my boat, functional approach without a proper functional language. Elm is much more interesting, but the work they're doing on pairing React with oCaml / Reason could change that.

In short, I don't have a problem with keeping up with the new stuff - I'm glad it's finally catching up with where I was years ago:)

I did a lot of UI client/server back in the day; VB, Powerbuilder, Delphi and I remember being able to bang out an app in days. Then the web came around and turned UI development into a chore. Recently though, I started playing with Elm and it makes UI development fun again.

I can vouch for Intercooler. We're rewriting large parts of our app (used to be a complex flux beast) and it is now way more maintainable and indeed around 1/10th the code. We now keep most of our app state within the server, instead of spread throughout client and server.

Of course, it is not end-all-be-all: it solves simple interface problems, those that should't require 200mb of JS dependencies to solve. Once the interface gets complex enough, you should use JS. We've still got a couple of JS components though.

Holy shit I can't tell you how happy that makes me to hear.

Excellent. Intercooler is simple enough that if it goes awry I will just write my own, but if I don't have to then great.

But to further your point, intercooler is just a tool rather than an ideological shift in how we execute web applications.

The reason I see the whole front end JS infrastructure mess as unintuitive is precisely because my needs are served with back end code and a sprinkle of Ajax.

If I were building a complex SPA like an in browser photoshop, I might see more use in the complex ecosystem and try and tackle it. But, from a not-so-outside view it still looks like a mess.

posts like this are why I love HN. Intercooler looks cool and simple, and simple enough I can just re-write it. Angular is big enough that my eyes glaze over thinking about reading into it.

This is the first time I've heard of it and it's elegant enough that I want to start working with it.

Here's the flipside. This is way easier for me to grok than Angular but which one has way more of a presence at companies and job reqs out there? I'd probably get screened out of a lot of resume filters.

I'm a pretty senior backend guy so I'm not worried about my resume. This helps me whip up quick tooling for ops and to understand discussions and nuances from the JS devs I work with.

History repeats itself. I'm also "old" and when I saw the first presentation on Angular many years ago, the google engineer started by instantiating the controller from the view. So blatantly wrong, yet noone reacted. I saw the same sh*t go down with JSP, and though to myself that I couldn't be bothered with going through the same thing twice. So I left the presentation and never looked back. That decision served me well, very happy that I'm off that bandwagon. Still love new tech though, so I'm not backwards in that sense.

> the google engineer started by instantiating the controller from the view

Sort of playing devil's advocate here, but what did you not like about that approach? I'm guessing he should have used dependency injection? Am I missing something else?

Speaking generally (ie: not about Angular), your main app should instantiate the controller, view and model and (constructor) inject model and view into your controller.

The controller is supposed to control the view, thats why it's called controller. The controller sends data to the view for presentation and reacts to events from the view and updates the model accordingly. This way the view becomes quite passive, it only knows how to present data and where to send events. You separate the display from the driving of the display.

I think you misunderstand me. I just wanted to see how it worked... intercooler is simple enought to dig into. Angular is 4 layers+ of abstraction deep now. I'd only dig into angular's code for work. I can dig into intercooler for fun. Then very likely just write it myself.

But smaller code like this that is well factored is great for learning and picking up new tricks and style.

Thank you for mentioning intercooler.js. After skimming through the docs for five minutes I am sure I will use this regularly from now on.

After skimming through the docs, my mind went all the way back to ASP.NET Web Forms days :) This model, unsurprisingly, brings it's own problems when things get complex.

Yeah, there definitely isn't a silver bullet. However, intercooler stays a bit closer to the metal than the old ASP.NET stuff, so it doesn't have the opacity problems that came with it.

You can think of it as a declarative syntax and a few extras layered on top of the standard AJAX function call.

I don't see the obfuscation of the client and server separation .Net Web Forms have.

It is declarative, just like the .Net, but I don't think it will bring the same kind of problems. What will probably happen is that when things get complex, you'll have to manually write the complex parts - that's a very sensible "problem" in my opinion.

Bingo.

I didn't know intercooler existed, so thanks for the link. For anyone else, it's worth reading about, it actually has a very well written introduction, guide and examples.

Yep, the docs are very good, and I've been enjoying catching up on the blog archives, too, for interesting project background and philosophy.

Great to hear!

Yes! As a still-young-ish guy who's just old enough to remember when things were slightly saner, please let me encourage you to get out there and make it happen. Don't let the Javascript fatigue apologists make you feel like you're too old to have an opinion.

So Intercooler is one of the sane ones, eh? Apply to talk at a JS conference and tell us about it. If it's somewhere near me, I'll do my best to be there.

The only reason why things have gotten so out of hand is because the people without the experience and wisdom are doing all the talking.

I've applied to so many JS conferences it makes me ill to think about it. The only slot I found (outside of my local Sacramento groups) was at UberConf in Denver, and the turnout was small.

Turns out the "You are all doing it completely wrong, stop writing so much Javascript" is a tough sell at Javascript conferences. ;)

Hey, Rich Hickey got to tell a bunch of Rubyists at RailsConf to stop using objects.

Ruby folks are more open minded than JavaScript folks.

_ducks_

+1 for intercooler.js

So easy and quick to get going with it.

Reply on news.ycombinator.com