These are chat archives for jdubray/sam

27th
Aug 2017
Paolo Furini
@pfurini
Aug 27 2017 10:59
Hi gals, it's been a long time since I wrote here.. but I've seen this before:
"Actually, how Google Engineers think web development should be is Polymer — not Angular. At Google’s I/0 17 there was maybe 2 Angular talks and about 10+ Polymer talks."
Seriously?? I've tried using polymer a couple years ago, and it drove me crazy.. it reminded me of PHP style of programming, when I looked into how components are written. How could that be considered better than Angular?
Paolo Furini
@pfurini
Aug 27 2017 11:05
I've recently started using a high level Java platform for building heavy CRUD enterprise applications, and they promote Polymer as the way to go for mobile friendly SPAs.. but I'm not so convinced. Anyone can point out how a real-world SPA could be structured using Polymer, without resembling a mess of HTML/JS/CSS all mangled together?
Janne Siera
@jannesiera
Aug 27 2017 13:45
Polymer today is quite different than Polymer a couple of years ago.
If you're going to build web apps you'll need to deal with HTML and CSS, and you'll need to construct those dynamically. Whether you do that with PHP, Razord templates, Angular templates or Polymer templates or JSX templates or completely imperative is up to you. But I see now way of not mangling html/js/css together, unless you want to completely abstract away HTML and CSS.
Polymer is based on Web Components. You can use web components without Polymer and you can build up your components however you want.
And 'better' than Angular is relative to your requirements.
Janne Siera
@jannesiera
Aug 27 2017 13:51
Whatever API you prefer to build up your views, you'll probably find something out there that at least resembles your style. But I assume you have more important requirements?
Paolo Furini
@pfurini
Aug 27 2017 13:55
By mangled together I mean that I've seen polymer components written in a single file, with html and js together
that scared me away
One component picked randomly.. Maybe I'm too old school, but I'm never going to write everything in a single html file..
Paolo Furini
@pfurini
Aug 27 2017 14:01
With everything I mean the view and the logic behind a component.. I prefer the separation of concerns even for single components, because I want to let someone else deal with the appearance for example (a web designer?), and let a JS developer deal with the logic
but maybe I'm simply wrong and the future is really this kind of monolythic components
Jean-Jacques Dubray
@jdubray
Aug 27 2017 14:06
@pfurini it goes well beyond workflow, as I mentioned earlier (and especially for CRUD) the boundary of a so called component can never match on average with the boundaries of the business logic. Data is relational, there is nothing that can be done about it.
you do need some logic in the component itself, but this should not be part of the business logic, it's more internal to the component.
For example you design a master/detail component to represent and edit purchase orders, let's say you want to add a line item
that can be considered a "component level" logic, it is only when you submit the edited entity that the business/app logic takes over
Jean-Jacques Dubray
@jdubray
Aug 27 2017 14:13
I wrote my first GUI in 1990 with Interface Builder and NeXTStep and that very question has been raging on ever since. A couple of years later NeXT published an ORM (EOF). We have been at it for nearly 30 years now.
React may have been the first one to break the mold, but they quickly put it back together (actually a lot of people noticed that React component lifecycle was strangely ressembling the one of NeXTStep, which was available as part of the iOS SDK).
I am not sure if you know the story but Steve Jobs asked Jean-Marie Hulot (who authored Interface Builder in the late 80s) to form a small team in Paris around 2003-2004 and put together the architecture of the iPhone. That's why (I think) the iOS SDK was pretty much NeXTStep (Objective-C, Interface Builder).
Paolo Furini
@pfurini
Aug 27 2017 14:31

I am not sure if you know the story but Steve Jobs asked Jean-Marie Hulot (who authored Interface Builder in the late 80s) to form a small team in Paris around 2003-2004 and put together the architecture of the iPhone. That's why (I think) the iOS SDK was pretty much NeXTStep (Objective-C, Interface Builder).

I didn't know of the team behind the iPhone, but I knew the nextstep roots of pretty much everything modern Apple is today

Jean-Jacques Dubray
@jdubray
Aug 27 2017 14:32
yes, OS X is 10 as in NeXT, and so on
Unfortunately generations upon generations of developers carry that kind of baggage and we never question it, that's true for pretty much anything OOP, FP, ... people just form camps, if not cults around a particular concept, formalism, framework, and it only dies when the camp/cult has no more members.
Paolo Furini
@pfurini
Aug 27 2017 14:34
React and the likes are really what a view engine should be, but Angular is ubiquitous.. I started developing MVPs using Ionic, and that's Angular too. Then I looked into NativeScript, that makes possible building performant native UIs, and (beside pure JS and TS) they support angular OOB
Yes, there's React Native, but It's easier to find angular devs to put on a project, than react ones. And angular feels less scary to less experienced devs.. But I know that, because of the latter, the overall quality of final products will be lower
Paolo Furini
@pfurini
Aug 27 2017 14:42
I need to prove that I could use Angular + SAM even in ionic or nativescript, but I'm pretty sure it should be possible at least for the former
If I could choose based only on my personal preference (and not the market forces) I'd use pure JS, or Inferno or Mythrill
Janne Siera
@jannesiera
Aug 27 2017 18:19
With everything I mean the view and the logic behind a component.. I prefer the separation of concerns even for single components, because I want to let someone else deal with the appearance for example (a web designer?), and let a JS developer deal with the logic
It's perfectly possible to put html/css and js in different files with webcomponents (and thus also Polymer).
Whether those are separate concerns is up for debate. One I don't really care for too much.
For me it's mostly about two things:
  1. I want to change the JS while a designer changes the HTML and not be dealing with merge conflicts && I don't want to be scrolling back and forth in the file while working with bigger components. Thus I prefer to keep HTML/CSS and JS in separate files.
Janne Siera
@jannesiera
Aug 27 2017 18:27
  1. I like templates because it restricts the kind of logic you can use to build up your views (which I regard as a good thing working with devs inexperienced and time pressured devs) and it makes it much, much easier for designers to make changes safely. BUT I don't like framework-specific templating languages (because I want to change framework and reuse templates) so I use one templating language that compiles to the framework's API. So, I have another reason to separate template and the rest of the component. If you don't do this and you just use the Polymer DSL this is not really relevant though (so it all comes down to point one).
(for some reason it changed the number from 2. to 1. automatically)
Jean-Jacques Dubray
@jdubray
Aug 27 2017 19:17
we exchanged our arguments on that one, I don't have much to add other than I feel functional HTML is better, but that's not very important, it does not change the semantics of the pattern, just a different way to render the view.
Janne Siera
@jannesiera
Aug 27 2017 19:41
@jdubray functional html has nothing to do with templates. You can have functional Html with or without templates.
Jean-Jacques Dubray
@jdubray
Aug 27 2017 20:22
you need to be able to compile them dynamically, it's not always possible/desirable
Janne Siera
@jannesiera
Aug 27 2017 21:53
@jdubray you can perfectly precompile them.