Comment by git-pull | Hacker News Reader

Comment by git-pull | Hacker News Reader

I'll probably try it.

But man, am I getting jaded about all this javascript framework stuff. Every 6 months stuff breaks, every 2 years there's a huge shift.

The problem with javascript I've been facing is value. Time and effort doesn't always correlate to what I get in the other end. In fact, I can say when building, going single-page is a time sink.

And it's almost always a mistake to go SPA first. Using a django or a rails lets you get the basics and data flow nailed down early on. Get into a framework too early and have a need to change something? Have fun explaining to your manager/client how costly it is to do a "simple" modification to a JS app when you have to throw the state you built it upon out the door.

What I want is a system tightly coupled into a server-side framework like a Django or a Rails that degrades gracefully and I only have to program the interactivity one time. Something that'd plop right into the asset pipeline/django compressor so I don't have to go outside of the framework to build.

Hundreds of hours of my life have been spent chasing this dream of sharing server side code with client side JS frameworks. That's what I need.

Meteor didn't do it for me. As for rendr, I've done stuff better with backbone/express in-house. As of 2017, I get my best bang for the buck using django and pjax. No joking, I went from full DRF + Backbone Marionette -> to plain old jquery and pjax and couldn't be happier.

All these new build tools (grunt, gulp, webpack... come on), ES versions (I was ok with ES5). None of these things are helping me ship stuff ahead of / on time and correctly. They're creating an even larger gap between the server side data, logic and templates and the JS interactivity.

If anyone is listening, I'd love to have a well-supported opinionated distribution of django or rails that just renders forms, tables, etc. with angular/react/etc. and degrades gracefully.

I'm actually really excited about Angular "2+" for something you've expressed here. I know that a React developer won't see this the same way, but I really feel like it's come down (for me at least) to either Angular "2+" or React - and whatever the reason someone is going to be on one side of the fence or the other. I've written smallish to largish programs in Vue, React, Ember, Polymer - and in all of those cases tried, wherever possible to do so in RXJS and Typescript. When everything else shakes out, I'm finding that nothing is coming close to the RXJS and Typescript combination "sweet spot". There have been various attempts to make a lot of the other frameworks "typescript friendly" but it's just nowhere near.

So why is Rx and Typescript so important to me? Well specifically those two are kind of like the drug that once you try them, you literally can't go back. I've been wanting this level of type checking for 10 years on the front end. I am not willing to lose it now. As for Rx, it's the one true way to do async flows. Promises and Callbacks just end up creating large pyramidic code.

I think Typescript can sometime have a mind of its own, but it's certainly an enrichment and with Rx everything just falls into place.

At this point it's hard to ignore that all the UI libraries are just paradigms and patterns, and how we use them is getting less important. These days I just want to write Component-style UI code, and I'll be fine.

Similarl things can be said about RxJS, but I think since it's a different level of abstraction, it will hit much harder, once it gains more traction. And it's already building up a solid community much faster than before. the only thing standing in the way of people learning RxJS is the same as Angular / Vue / React. It's scary and there's a lot of fatigue still. I hope that this year is thus going to be even better for teaching. ^^

Tldr; RxJS is going to be huge, if we can teach it more and JS fatigue calms down.

We've got some really cool ideas to make Rx really first class in Angular. It's already pretty deeply integrated, but with a little work, it'll be awesome.

definitely agreed! It's become one of the biggest "advocators", so to speak. But I think people will want to learn it as a default, async primitive in JS as promises now are. Not saying support from Angular and other projects and also companies doesn't help, since it makes it look less like a "scary, new thing", but I think more people should start to teach it's benefits to be frank and blunt about it ;)

absolutely. we're 100% invested in Rx, and more than anything else I'd like to see the Observable type standardized.

What are they? I've been developing with the @ngrx suite, and it's been mostly pretty smooth, what more do you want? I would like to see a piece of documentation that lays out explicitly what happens when you pass around Observables. Hot ones, cold ones, when the auto-unsubscribe clicks in, whether

    this.property$ = some_observable();
    this.property$.subscribe(fn);

... will auto-unsubscribe (does it? who knows... try it?), what happens when you async pipe and its interaction with ChangeDetection...

Didn't GWT provide you with type checking on the frontend 10 years back ?

Still works, incidentally.

Yep. It was horrible to use, but it had type checking, sure. So did Objective-J, from around the same time period, fwiw.

Yep, I realized and regretted saying that after I posted that - there certainly are typed languages on the front end, but at some point or another they are all very disconnected from Javascript itself. I feel with Typescript you get both a user-configurable level of type checking combined with the cowboy coder flexibility of Javascript - I guess that's what I was aiming to say. Whether that's a good thing to others is up to them however. ;)

If you are Java heavy, GWT is still a great option. It is extremely mature and can do pretty much everything you want to do.

I'm glad to hear that there are some mature options out there.

Cyclejs currently seems to be the only sane observable/typescript based framework to me.

You should probably check out CycleJs. Rx like and TypeScript.

How does RxJS solve the problem of virtual DOM?

By itself it doesn't really have anything to do with it; they're solutions to completely different problems. (That said, I'm not quite sure what you mean by the "problem" of virtual DOM?)

What _is_ interesting, though, is having your virtual DOM be the output of a reactive stream, and having a virtual DOM library use that to update the actual DOM. This is the approach Cycle.js takes: https://cycle.js.org/

Intercooler.js may be along the lines of what you want, when combined with partial views.

You should try ClojureScript. Much simpler tooling (native tooling on top of Google Closure), nice integration of server and client side code.

We are not quite at the point of using NodeJs on the backend normally (and honestly the JVM is 100x better) but you can share the language.

You want get a django or rails like app at the moment.

Look into polymer. Let's you do server side rendering then use custom web components for the widgets needing interactivity.

I found building sites this way refreshing.

Yeah, I've been using polymer for quite a bit of time. It is very easly to pick up, small, fast and interoperable with everything else.

Preach brother. I've been saying the same thing for years now after a similar experience moving from an Angular SPA to a Django + Pjax app. I noticed an order of magnitude increase in productivity.I can't imagine going back now.

What were your problems with meteor? Because that sounds exactly like what you're asking for

> sharing server side code with client side JS

ever looked into clojurescript?

Reply on news.ycombinator.com