These are chat archives for jdubray/sam

9th
Apr 2017
Paolo Furini
@pfurini
Apr 09 2017 05:42
@DrecDroid I don't know, I have mixed feelings.. I mean, I started developing web apps 17 years ago, and I still see traditional server-side rendering frameworks a better choice when you need strong SEO support. Couple that with the fact (sorry @jdubray and other JS lovers :smile: ) that I really DON'T like writing javascript, being it ES6 or whatever number you want, so my backend will never be JS based
I know there are several solutions in several languages/technologies to do server-side rendering of javascript, but it's really worth the hassle? What's so wrong with page reloads when networks are more and more faster, and you have enough experience to build light and fast loading pages anyway?
Jean-Jacques Dubray
@jdubray
Apr 09 2017 13:18
@pfurini I had similar reservations about JavaScript 5-6 years ago, once you get your head around the language, this is possibly the most amazing programming language I have ever used. It looks odd at first, even uninteresting, but it is the only language I know where I feel the programming model does not constrain me to think in a certain way. After 3-4 years of practice I still amazed every day at the elegance of the language, considering it was designed such a long time ago. Of course json was added later and that's a possibly half the value of JavaScript.
@DrecDroid Google is actually pretty good at looking at SPAs, I don't know if you check the "See as Google" app, I was quite surprised how well they managed to parse SPAs (for SEO). This bootstrap blog sample I modified to work as an SPA seems to be totally covered by Google from an SEO perspective: https://github.com/jdubray/startbootstrap-clean-blog
@pfurini I don't mean to convince you either way, I respect your experience and as I mentioned, I am a back-end guy who crawled its way to the Front-End via SAM after trying everything else. SAM allows me to do things I could only dream of, one year ago.
Jean-Jacques Dubray
@jdubray
Apr 09 2017 13:27
All I can say is that,
1/ as I said in the article, I worked a lot with Front-End developers (as an API designer) and what I have tried to fix with SAM is the way APIs are positioned with respect to the Front-End. In a Thick-Client/SPA architecture the conventional architecture requires that all views have their own APIs (mostly because of Data Binding) and that's very costly to build and maintain. Front-End developers claim there are no alternative and it's very hard to have a discussion to change that.
2/ In React it's quite difficult to position API calls because of the way React controls the reactivity to state changes, it's too Reactive. In Angular2 this is done via services, but because of the two-way data binding, I suspect that most team will revert to 1/
3/ SAM provide a very clear guidance on how to connect APIs to the front-end (which works server side too, nothing says that SAM is a front-end pattern only. I have shown over and over that SAM is a software engineering pattern and works just as well on the back-end.
Paolo Furini
@pfurini
Apr 09 2017 13:29
@jdubray re JS, I dunno, TBH what scared me away from javascript was not the language, but the bad experience I had with nodejs and its ecosystem. On the other hand, I do value everything that makes me a better engineer/architect, and I have the feeling SAM is one of them, even if I must start using it in practice to really grasp it
and I agree with you, esp. on point 1, I've seen such architectures with a load of duplicate APIs only to serve the needs of highly specialised views. Re point 2, I can't tell, I only started studying react, and I wasn't aware of such limitation. Even in Aurelia, I use to wrap API calls into high-level services that serve one clear need and no more
Jean-Jacques Dubray
@jdubray
Apr 09 2017 13:32
At a very high level, SAM is just a different way of writing event handlers. It's that simple, everywhere you code an event handler, you can start with an action, then present the action's proposal to a model and then "render" with the State function. You could put DOM manipulations in the State functions if you wanted to, you could implement it as "request" wired to an action and response returned by the State function. SAM just states that an event handler should be broken in three parts. In general software engineering sees the handler as an orchestrator. That's really the paradigm shift.
Paolo Furini
@pfurini
Apr 09 2017 13:35
Yeah, I started writing an example myself from scratch in vanilla JS, just to see all the moving parts without the fuss of frameworks or libraries, just as you suggested before..
Jean-Jacques Dubray
@jdubray
Apr 09 2017 13:37
I may be biased, but I feel that SAM helps me think more clearly about my application, I am saying necessarily it will lead to more reusable code (resue = dependencies) and it's hard to reuse "app logic", but you probably will feel that your code is easier to extend and maintain because these three parts have very clear responsibilities and SAM allows a 'many-to-many' combination. It's that 'many-to-many' relationship which has, I think, the most value.
I would suggest you pick a few event handlers in one of your app, and just move the DOM manipulations in the State function, and you probably should get a good feel as to if SAM has any value. I am certainly interested in your honest opinion. I am not looking for praises.
If you are interested to build a slightly bigger sample and see where JQuery fits, the Bootstrap Blog Sample illustrates that. There are couple methods where I usually put the JQuery code
https://github.com/jdubray/startbootstrap-clean-blog/blob/master/js/script.js
Jean-Jacques Dubray
@jdubray
Apr 09 2017 13:42
Since I use functional HTML and try to avoid DOM manipulations, I generally don't need JQuery in the State function.
Rodrigo Carranza
@DrecDroid
Apr 09 2017 20:56
What I meant is that pure SPA is simple, also pure multi page with SEO, but when you want to deal with SPA + SEO you have to deal with both server and client side rendering which make your app really complex and tied to only one PL, javascript. I've tried google "See as google" and It will not render your page unless your app is isomorphic, I have also seen how my page was indexed by google and It doesn't include all the information like title and meta description. So i had to leave SPA for where the app really resides and everywhere else just "static" pages with a bit of js.
Paolo Furini
@pfurini
Apr 09 2017 21:49
@DrecDroid TBH it's never black & white.. for example you don't need full-stack JS on the server for server side rendering, it depends on the maturity of the stack of choice: https://github.com/aspnet/JavaScriptServices. I'm not advocating asp.net core here, just an example that shows I can write an asp.net core backend, and pre-render some SPA pages server-side, where SEO matters
Paolo Furini
@pfurini
Apr 09 2017 21:57
But I'd never write a SPA because it's cool.. if it fits the job, well I'll do, however you'll never find me writing a CMS like a SPA (I've seen several companies doing so, and I really think it's dumb)