These are chat archives for jdubray/sam

20th
Sep 2017
Janne Siera
@jannesiera
Sep 20 2017 01:26
@Vertex21 in index.html, change targetSize to 25
Performance is amazing on chrome (native wc support) but completely terrible on Edge (no native support)
You can download and install the react version (it's on github) to run side by side with the react fiber and react stack versions.
Jean-Jacques Dubray
@jdubray
Sep 20 2017 06:36

According to this nothing beats pure JavaScript.

sorry I have to laugh

@ddavis914 I just completed a 4 month ES6 project (with SAM of course). It was a stats dashboard (using C3.js) and a bit of CRUD. Happy to give some general feedback if you'd like. I can also share some code (not from this project though). I have SAM-enabled a few templates earlier this year that I am happy to share privately.
Jean-Jacques Dubray
@jdubray
Sep 20 2017 06:42
The beauty of ES6 is that it's here to stay. Ten years from now, your code will most likely still be running as if it was 2017, npm, webpack, react, angular will all be gone by then (at least the version you are using today). I just can't believe that our entire industry can be so brainwashed as to believe that anything else would save them time and money.
Languages evolution is > 99% backward compatible. That's a historical fact, unlikely to change.
Framework evolution is < 10% backward compatible, when they don't die on you on a short notice
Fred Daoud
@foxdonut
Sep 20 2017 10:35
@jannesiera thanks for the code example! I will have a look.
Maxime
@maxime1992
Sep 20 2017 10:59

@jdubray I guess it's probably not the main point of this channel, but according to your last post here I do have say the following and ask you few questions:

The beauty of ES6 is that it's here to stay

ES7 is already on the way and ES8 too... So you'll have retrocompatibility but then it's like saying "better stick with ES4, will still be there 10 years from now"

npm

So you do not use depencendy manager?!

webpack

You DO manage your imports by hand?!

react, angular will all be gone by then

How do you know that? AngularJs was built in 2009 and still millions of apps are running it in 2017

at least the version you are using today

So what? We should stick with a 10 years version without never updating our libs?

our entire industry can be so brainwashed as to believe that anything else would save them time and money

Have you ever built large applications? Real question, no offense. I'm just wondering.

Framework evolution is < 10% backward compatible, when they don't die on you on a short notice

Is it worth thinking this way? Don't you have a smartphone? Are you still using a nokia 3410? Because smartphones are not really "backward compatible" these days.

I understand the kind of frustration you're facing now and I've been (close) to it. Because the javascript fatigue is something real and we always have something new to learn. But it's not (only) about "save them time", it's mostly about building scalable applications.

So yes, if you just need to draw a chart and do some CRUD it might be enough to go with ES6 only. But for medium/large applications, it's definitely not a good idea. How do you handle a protected route? Is your code splitted by component or something getting close to that, which allows you to maintain and scale? Have you any open source code for a large app built only with ES6 we can take a look in?

Also, how do you test your application? And the project you've been working on, were you alone? Or working with 10 people?

Sorry if I seems mad, it's not my goal here. Frameworks also have downsides, yes. But your argumentation here just feel wrong to me so maybe you can answer my questions and I'll see things differently.

But here's my opinion about all that:
Frameworks are here to bring a higher level of web page manipulation where mostly think about the logical part rather than trying to handle DOM updates.
Tooling and building tools are very handy. For example webpack is so much more reliable than trying to handle your dependencies by hand, knowing in which order you have to import them etc. Typescript (and probably flow) is a lifesaver. Working on a large project with other people, you do not need to spend time writing doc about the types and thinking a lot about them when using some data. It's all typed and you just use that power so save time and energy. It's also really helpful when refactoring or discovering a project where you can see wherever a variable is being used etc.

So as I said, please let me know what kind of apps you've been writing, with how many people, for how long (days, weeks, months, years?), were they POCs or real apps in production.

Fred Daoud
@foxdonut
Sep 20 2017 12:42
@maxime1992 what is your preferred web dev stack?
Maxime
@maxime1992
Sep 20 2017 12:56

@foxdonut For now, I'm really comfortable with:

  • Angular (2, 4, etc) --> dependency injection for the win! And of course everything else provided by this framework I love :)
  • Angular-cli to handle all the build system for me so I can just focus on the code
  • Typescript: I've already talk about that in the previous comment
  • Rxjs to work with streams within my app instead of promises. Way more powerful and once you've passed the gap of thinking in a reactive/functional way, it's incredible for front dev but Rx is also available for java, scala, ruby, and many others so it's definitely a good investment
  • Redux, because thinking of my data as a database with normalized state that I can later compose with selectors is great. Also there are many middlewares available and the famous ReduxDevTools for time traveling and more
  • Ngrx, which is a mix between Rxjs and Redux: It turns your store into an Observable (rxjs) and you can think of all your data as a big stream

This is only my preferred web dev stack but I'm sure there are awesome others with react, vue, etc. But anyway, Rxjs + Redux is definitely something I really love as it's framework agnostic and I can reuse those way of thinking anywhere.

Maxime
@maxime1992
Sep 20 2017 13:03
And to be fair, yes I've spent a looot of time to feel comfortable building large apps with that stack but now all the patterns, way of thinking, functions provided by angular and the tooling, I feel "free" and confident that I can design and code whatever app is in my mind :) So it's a big investment, yes. But for me it's worth it! :smile:
Jean-Jacques Dubray
@jdubray
Sep 20 2017 14:40

@maxime1992

The beauty of ES6 is that it's here to stay

it's not exactly what I said. Languages do evolve but unlike frameworks they do so in a backward compatible way. You can start in ES6 and continue in ES7, ES12 or ES26, let's try to do that with Angular.js and Angular2.

Yes, Angular.js apps are still running today but it's just harder to invest in them, over time, it will be harder to find people who want to maintain them.
Jean-Jacques Dubray
@jdubray
Sep 20 2017 14:46

So you do not use depencendy manager?! You DO manage your imports by hand?!

I try to use as few dependencies as I can. I use traceur to transpile ES6 to ES5 during development then when I am done, I transpile it.
It's all here: https://github.com/jdubray/startbootstrap-clean-blog

Jean-Jacques Dubray
@jdubray
Sep 20 2017 14:57

I can't expect this approach would scale to what you qualify as a "large application", but it's certainly good enough for 80% of the apps if not more.

Have you ever built large applications? Real question, no offense. I'm just wondering.

The short answer is "no"

Is it worth thinking this way? Don't you have a smartphone? Are you still using a nokia 3410? Because smartphones are not really "backward compatible" these days.

The problem is when you spent $1B building an ASP.Net Web app and you have to explain to your boss that you should switch to Angular.js. Your example makes no sense because it does not includes the cost of switching.

Jean-Jacques Dubray
@jdubray
Sep 20 2017 15:06

I understand the kind of frustration you're facing now and I've been (close) to it.

To be frank, my frustration is not about JS fatigue at all (I can't have enough of JavaScript. this is by far my favorite language).
1/ In the 90s I built a small company on NeXTStep which was just incredible at the time. Steve Jobs took it all away when he returned to Apple and killed NeXTStep. I had don't the hardest part, built an incredible product (of course couldn't have done it without NeXTStep) and lost it all.
2/ Frameworks have an opinionated programming model that do not scale, you can Webpack your code all you want, "large Web apps" collapse under the weight of the programming model, not the dependency management, that's a very small problem.

So as I said, please let me know what kind of apps you've been writing, with how many people, for how long (days, weeks, months, years?), were they POCs or real apps in production.

I am a back-end guy, I have been coding front-end projects in production in the last two years, just because I wanted to put SAM in practice (and not pontificate in vacuum). They are mid size Web apps in Angular2 and ES6, and as I said, even though I am ok with Angular2, I don't see any reason why people would use it.

Sorry if I seems mad, it's not my goal here. Frameworks also have downsides, yes. But your argumentation here just feel wrong to me so maybe you can answer my questions and I'll see things differently.

It's ok, I like healthy discussions. I don't pretend to be right. Everyone come with their experience.

Jean-Jacques Dubray
@jdubray
Sep 20 2017 15:12
So the type of apps I have been building in the last couple of years were 1-3 people, 4-7 months projects. Medium size?
Jean-Jacques Dubray
@jdubray
Sep 20 2017 15:20
to be honest, I see people jumping on stuff like Elm or Cycle.js and I can't help but think, "what are they thinking?" who in the world can bet any money on frameworks like that? React, Angular, I can understand. Vue maybe, everything else? Look at dependency management? Grunt, Gulp, Webpack, ... I truly feel that the best advice I can give to myself is:
1/ you should use a dependency when you have no other choice,
2/ when using a dependency you should have a clear exit strategy
3/ what is the programming model of that dependency, how you code bend to fit in?
Jean-Jacques Dubray
@jdubray
Sep 20 2017 15:26
I do feel comfortable today that I can build anything in ES6/HTML5/CSS3 and if I could get people's attention, or at least to give it a try, they would see the light.
Janne Siera
@jannesiera
Sep 20 2017 15:38
@jdubray do you have any reference material about Petri Nets vs TLA+ ? In what way they are different and/or alike?
Jean-Jacques Dubray
@jdubray
Sep 20 2017 15:45
Dr. Lamport has been pretty clear in his talks that he does not see Petri Nets to be useful at all (and I spent litterally 20+ years breathing and leaving with Petri Nets)
From Dr. Lamport's word, programming is about writing "steps" to transition from one state to another: Sn+1 = STEPn(Sn)
Jean-Jacques Dubray
@jdubray
Sep 20 2017 15:51
A lot of formalisms can fit under that umbrella from Pure Functions to Petri Nets. The question is not so much whether it can fit, but what is the best way to factor a Step, for a given class of state machines (say from a switch to a distributed system, such as a Web app).
devin ivy
@devinivy
Sep 20 2017 16:00
@jdubray do you think it's approximately accurate to say that petri nets take a global approach to state machines, while TLA+ takes a localized approach?
i.e. in petri nets you have to understand the entire state machine at once. and in TLA+ you focus on allowed transitions only from where you are.
Janne Siera
@jannesiera
Sep 20 2017 16:01

@jdubray if you would allow me to comment on the discussion that you are having with @maxime1992 .

I don't think you and I have a lot of areas of disagreement (templating is definitely one of them though ;) and I don't think we'll disagree too much here, either. I'm just trying to make you aware of they way you are being perceived sometimes.

I think you and I both agree that most front-end frameworks are overengineered. I can certainly agree that you need to be careful with chosing dependencies, and agree a 100% that a clear exist strategy is the most important factor in making that decision. Nothing is forever after all.

Now, if you want to get people's attention, you ought to try and understand those people first. And ought not to (accidentally) offend them. Condeming the big frameworks is one thing. Things like npm, webpack, testing frameworks, etc. are something completely different. Even though you might be right and they are complete overkill for 80% of applications out there, a lot of us are working on the other 20% that DO benefit from them. Maybe not to get our app working, but those tools can help us save time or boost performance in a way that gives our companies/products a competitive edge.

I'm not trying to say you should or should not use npm, webpack, bla bla. I just would like to point out that to be taken serious, and have people take a shot at your ideas, you have to take others serious. Most of us have a very good reason to use those tools, even if there might be ways to solve our problems that we don't know about and would make these tools unnecesary.

It's just because of this urge to find better solutions to our problems that people 'jump' on things like CycleJS. Of course we'll try them out in smaller projects that don't need them, but that's how we see if they truly work and are robust enough to be leveraged by the company. And that might mean learning to fix some things the 'CycleJS' way without necesarily using the actual framework. This is also the reason why people will give SAM a shot.

And people take things personal all the time, even when they really shouldn't.

Am I making any sense?
Probably time for me to re-read this one.
Jean-Jacques Dubray
@jdubray
Sep 20 2017 16:11
@devinivy IMHO, Petri Nets are just too rigid, they actually don't define a "step" at all. It's just a mapping of state and actions and even though they can "compute", no one would want to "compute" with Petri Nets. I truly believe today that it was an honest mistake and lots of people went down that road because it seemed to work and indeed worked in some cases, but it's not working for the vast majority of problems. I think it's one of these formalism that the human mind is naturally attracted to, and as such it feels right, but that's about it. I would not use them any longer, even to switch a light. This is 2017, everything is connected!

Things like npm, webpack, testing frameworks, etc. are something completely different.

yes, I agree, but again, it seems that we jump into a number of things just because it looks cool or someone said it looks cool. For instance it's well proven that 100% code coverage is useless because you can have 100% code coverage and 1% path coverage. Only the "path" matters. SAM helps tremendously because its building blocks (actions, acceptors, reactors ...) are meaningful units that can be individually tested.

Jean-Jacques Dubray
@jdubray
Sep 20 2017 16:17
@jannesiera I can see the value of Webpack, but it looks to me that's a circular dependency. Webpack exists because Frameworks have become unmanageable, because their architects/designers paid zero attention to their design.

you ought to try and understand those people first

I am trying, but there are so many moving parts, I am not sure how I can keep up. I feel comfortable with what I am doing, and all signs point to a NoFramework movement. I don't think it was possible prior to ES6, but once the browsers will complete their support for ES6, then people will rediscover the beauty of NoFramework. Of course, there will always be the IE11 case :-((

Jean-Jacques Dubray
@jdubray
Sep 20 2017 16:25

to find better solutions to our problems that people 'jump' on things like CycleJS.

I am not quite sure what problems Elm and Cycle.js set out to solve, they are just shinny hammers as far as I am concerned.

I spent the last 20 year or so working on programming models (BPM, B2B, Composite Applications, SOA...). IMHO, the solution is in the programming model, not in the framework.
Victor Noël
@victornoel
Sep 20 2017 16:37
well... a framework is only an implementation of a paradigm/pattern/programming model :)
Jean-Jacques Dubray
@jdubray
Sep 20 2017 16:37
React clearly opened up a new direction, but the management of their programming model has been abysmal
@victornoel yes, but in general there is very little clarity about it, Frameworks rarely explain why they are (or apologize for) doing things a certain way
Victor Noël
@victornoel
Sep 20 2017 16:43
;)
Janne Siera
@jannesiera
Sep 20 2017 16:44

@jdubray you are giving the impression that you are completely unaware of the dynamics of bigger IT teams/projects. I'm not saying that you are unaware per se, but that's how you will be perceived by a lot of people reading this (I believe).

For me it doesn't really matter. But I am concerned that your message will get lost this way to a lot of people who might benefit from it.

Jean-Jacques Dubray
@jdubray
Sep 20 2017 16:56
maybe, perhaps I just do things differently, not better/worse. That being said, after spending so many years, building products and solutions (in IT), I see the same patterns at play. I appreciate the feedback in any case.
@victornoel frameworks tend to compete on features, not programming model. One could even argue that React tried to compete on programming model and got overwhelmed by a number of people building "features" for them. It's a delicate balance.
Jean-Jacques Dubray
@jdubray
Sep 20 2017 17:02
@jannesiera I only spent 6 months in a big e-commerce company in Seattle ($1-2B in revenue), all my other projects have been more standard IT projects. AT that time it was all about Ruby, the big body on the front-end had convinced management to rewrite their 15 properties in Ruby and after 2 years, they could only deliver the login screen (I am not joking). On the back-end the other big boys team who could not stend the idea of implementing an ESB, ended up... writing their own. I was able to demonstrate that there were more "classes" per service than lines of code in the implementation of the service. It was just insane, abstraction over abstraction.
After that I was gobbled up in a large OmniChannel transformation for a financial institution.
It may be just me, but the common thread across every project I have been into has been the reluctance to face problems. People will push their technology until it fractures, no one seem to be capable to see the problems ahead and have an objective discussion about the solutions.
Jean-Jacques Dubray
@jdubray
Sep 20 2017 17:07
In that OmniChannel transformation people had decided using XSLT (against my recommendation), XSLT has been around since 1998-1999 and ever since people have felt it could be useful. Even today the performance is abysmal. I don't know how many times I have demonstrated it was not viable. And yet we wait until the last minute to fix it, until the pain is unbearable and you need to ship yesterday.
Jean-Jacques Dubray
@jdubray
Sep 20 2017 17:12
So again, I don't want to claim I am better than anyone, but at a minimum I don't take any technology on face value, and no one should. I am very bitter in that instance where I used a product from someone I knew well (CEO of a large middleware company) and the product was buggy to the point where it could not be used. He was not a "friend" but someone who claimed to be above the traditional ISV level, delivering high quality software with high integrity. So, again, it may be just me, but I just can't trust a lot of things and I'd rather use as few as possible.
Janne Siera
@jannesiera
Sep 20 2017 18:38

@jdubray I completely understand your sentiment. And like I said, I think we are largely on the same page.

Please, note that I have not been commenting on the merit of your opinions, but on the way you express those opinions.

I know I can have a frank and fair discussions with you and you're always game. That's great and I appreciate that. I was, however, under the impression that you are trying to get people interested in SAM want to share something valuable. Why else did you set up a gitter channel, wrote articles and made presentations?

It is in that context that I am merely suggesting that you might want to, just ever so slightly, adjust the way you express your ideas.

And I might be completely out of line here, and certainly don't want to offend you.
I just want to point out, that the way you are perceived can be bitter.
Now, again, I have no issue with you or the way you communicate. But I am certain that there is a better strategy to make people listen to you.
Fred Daoud
@foxdonut
Sep 20 2017 19:06
@jannesiera I am with you on that. I have no problems with @jdubray myself either and have learned many valuable lessons. JJ I appreciate that you have changed my way of thinking and how I approach solving problems. But, as Janne said, in some discussion threads, the way that you jump in and comment may be perceived as harsh/negative/abrasive by some. Maybe you don't care about that, and if that is the case, I respect that. I know you're not in it for marketing reasons or for gaining popularity. Still, think of it this way: getting more people to listen to what you have to say will make more likely that we'd have a change in the industry, and that would be great.
Victor Noël
@victornoel
Sep 20 2017 19:31
At least it is a great filter to keep really interested people on board :P
I think explaining SAM and all the background that @jdubray has behind so that he arrived to this conclusion is not an easy task, and often people put all their focus on technology instead of patterns (it was hard to explain sam to co-workers, they always wanted to go back to redux or ngrx and say "this is the same", or "you can also do it with redux", etc) and the when you add "harsh" comments on all the technologies people already use (and often with good reasons, as @jannesiera perfectly explained, as well as @maxime1992 and even I in the past, I don't believe that es6 is enough for the projects I'm working on with @maxime1992), this doubles the mental effort of newcomers to understand the approach and the whole way of thinking about producing applications.
Also over the internet, it's not always easy, we don't all have the talent of the people who made the redux.js.org website: good communication and marketing skills are not easy.
But at least, really interested (and intelligent of course :P) people stay and try to understand anyway and bit by bit, understanding emerges and new people make documentations, explanations and samples. Like this not everything rests on @jdubray shoulders ;)
Jean-Jacques Dubray
@jdubray
Sep 20 2017 21:16
@jannesiera @foxdonut @victornoel (and everyone else in this forum) I appreciate the feedback and above all, all the discussions. It's a bit selfish, but I found what I was truly looking for when I stumbled upon SAM, so I am not too concerned about how people look at me. I used my first framework in 1990 with incredible dev tools for the time, I understand the feeling. Nearly three decades later, I realized, and I am truly convinced, that they are no longer needed. We have to return to the source and the foundation of programming which is about managing state (not just the bits to quote Barbara Liskov), nothing less, nothing more. It's ok if you disagree with that position, maybe I am just a fool, or at least fooling myself. That being said, I'd rather go back to practical discussions.
Victor Noël
@victornoel
Sep 20 2017 21:36
right on, let's go back to the good stuff, all of this about frameworks is just an "on the side" discussion on this channel and doesn't really add or remove anything from SAM even if we seem all to enjoy arguing about it :)
Jean-Jacques Dubray
@jdubray
Sep 20 2017 21:59
:+1: