Separation of concerns RANT - MPJ's Musings - FunFunFunction #47
Вставка
- Опубліковано 28 сер 2016
- 💖 Support the show by becoming a Patreon
/ funfunfunction
Separation of concerns is pretty misunderstood concept, in programming in general, no just JavaScript and web development. I talk about separation of concerns in the context of React and combining HTML, CSS and JavaScript in one place, but also in the more general programming sense in function extraction.
I'm also active on:
• Twitter / mpjme
• Medium / mpjme
• Quora www.quora.com/profile/Mattias... - Наука та технологія
What about Vue?
It's fine, but I see a lot of people using the template language thinking that they are separating concerns.
Basically, it's a great tech, great team but a lot of its users (at least initially) use it as a sort of excuse not to change and learn.
@@funfunfunction I think it makes sense. Don't reinvent the wheel. Don't get me wrong, I'm cool with both. But it's not only about me, but about teams. I just think, maybe it isnt always good to feel "comfortable", learning new things is great and that. But is an investment in the end. If you see it from a company, it may seem like Vue is a cheaper investment with sort of the same benefits. Is this really a good point or just an illusion? What do you think?
By the way, thanks for taking the time to answer. Time is one of the most valuable resources haha.
I think Vue is largely the same thing as React - it's packaged better and has some differences but it's not paradigm leap in the way that React and Flux was over Angular 1. I honestly am not all that interested - it's a fine product but a choice between React and Vue is not going to make a big difference on your technology org - if you're staring that hard on this decision you care too much about tooling. Any kind of process improvement such as pair programming, CI improvements, test coverage policies etc are going to give you more than the any if any difference that changing between these two tools is going to provide.
As for comfortable - that's a very fucking dangerous path to go for a team. I've been in teams with a horrible acceptance culture around their old Perl backend. While we shouldn't jump on every new thing ever, technology does grow stale over time and it's important for a team to be hungry to constantly improve, or their habits will eventually land them on very thin ice.
Fun observation: as for templates, it's more of a cyclical thing rather than a new thing. The discovery that we did that JS is a good templating language and that JSX is fine was a discovery we did back in 2000 when we discovered that Smarty, the reigning PHP templating engine, was an unnecessary layer and we could just do away with it, replacing it with PHP and a little bit of discipline and understanding of what separation of concerns actually is (which many of template advocates misunderstand, confusing it with putting things in files, language or other proverbial correctly colored bucket). After that, new developers that had not learned the lesson joined the community and now they are learning the lesson all over again. :)
This is probably the most useful video you've done for me. It made me realize why I used to need so many monitors to see all of my "concerns". We started using react on our projects and I started noticing I'm using less "window" space to develop. From going the route of separating files by type/language, to building components specific to a concern, I no longer need more than 1 monitor to develop. And it didn't even occur to me until I watched this rant. :) Good job.
haha :)
🤣
I can't wait for the day when I don't have to explain this concept to colleagues, I'm tired of their eyes glazing over.
I like rants like this. It's advice on how to be a better programmer rather than on how to use a tool.
Great video, MPJ!
I like to summarize this moment we are living in the web development as the transition from "reusable CSS classes" to "reusable components".
In the past years, we were taught to write CSS properties in a way that we could reuse it across many different HTML elements. Since a piece of CSS won't necessarily be used on a single HTML element, the separation between these two tools was natural and made sense at that time.
However, after the release of libraries like React that encourage developers to build web projects based on components, we started to switch from the "reusable CSS classes" to the "reusable components" approach, where HTML, CSS and JS are all contained in a single reusable unity of functionality.
I'm one of this people using JSX and inline styles in order to build self contained components, and I can tell that I'm having a very good experience with it.
This video combined with your comment helped me realize why components are so popular now, thank you. I see now why inline styles aren't so bad, and actually beneficial in a lot of cases, unless styles are being repeated over and over again, then it would probably be best to extract it into a tag or a .css file
When I learnt OOP at college the teacher always used to say: 'you shall not have methods with more than 10 lines'. After more than a decade of receiving that teaching, I yet have to see a real world app written like that.
Hi MPJ, nice rant :)
Although i agree with the fact that separation of concerns in html/css/js is problematic, i'm still not convinced that React has solved it. Yes, it is nice to separate everything into components and have everything in one place. But you cannot use React for every type of website out there. Most of the time you'll end up with a lot of duplicate code, especially if you want to add css into the mix. It's my belief and experience that CSS should most of the time be delivered separately, otherwise you end up duplicating a lot of styling just for the sake of having easier to read code. And while html and javascript can be tied together much better, you still run into problems of nuance when one component needs to be slightly different depending on where it is inserted in a page so that it still makes semantic sense.
So what i think is best when thinking about separation of concerns is to really think about what you're doing and how it makes more sense. If you're building applications that rely heavily on reusable components, React should be a definite choice; if you're building a blog, a news site or an e-commerce website, maybe classical approaches would be more helpful so that you can better satisfy SEO and semantics. Also, if we're trying to optimise page load times and do some good micro-management of resources loading, again, components might not be the best answer, especially when you want to throw caching into the mix.
Also, what do you do when you have skilled people focused on HTML/CSS but not so good at Javascript? Or if you have really good Javascript developers that still struggle with advanced HTML/CSS? Does this not trigger by itself a need to separate these "concerns"? From my experience, it's a really good idea to separate the work that these people do and let them focus on what they're good at. Trying to merge 3 sets of mentalities into a single file often leads to confusion and conflicts because of each party's preferred approach.
And now to finish my rant, i don't think that HTML, CSS and Javascript were separated based on "what felt right". It requires three totally different mindsets if you want to do them right. I think you can only really combine them into one file or component when HTML and CSS are not that important to the final product.
Hi Daniel! I think you're totally wrong about duplicating styling in Javascript. It's quite the opposite. CSS will duplicate your code and will in the long run pretty much inevitably end up delivering dead code to your clients. What's so good about styling in javascript is that it's.. javascript! It's a complete programming language goddamnit! You can structure it however you want and reuse code how much you want. Just look at this for example, "css mixins" with 100% Javascript.
const blueCircleStyle = { width: '100px', height: '100px', ...roundedMixin(10) }
And yes React is a library for building web applications, not blogs (i would probably build a blog in it anyways though).
Well that's the thing, you think of it from a programmer's point of view. But, again, this only makes sense to someone like you. It doesn't make the same sense to a CSS guy. When following OOCSS or Atomic CSS guidelines (which don't duplicate code) you'll cringe at the thought of "limiting" your styles to contexts. And yes, you can argue that all those styles can be declared as a kind of global config object and use them throughout your components. Fine. But what this means is that you suddenly have a separate css-like file that you just added to make all of your framework support something that is already native to browsers. Add to this the fact that you are now limiting style calculations until your scripts are running.
All i'm saying is everybody needs to look at the bigger picture. Each part of a website is built with different sets of optimisation in mind. Browser vendors are working hard so that each step in the website rendering process works as smoothly as possible. So when you think that putting css and html in javascript is better from a code perspective, you need to think what it does from a performance perspective as well. What is easy for you to organise and read might slow down a colleague dedicated to just working with the styles and markup. Someone dedicated to doing SEO on a website will have a really hard time navigating all those components instead of opening a HTML page and doing his optimisations there.
Again, it all depends on what you're building. But thinking that component based separation is a recipe for success on any web project is, in my opinion, far from objective.
I used to think the reason why we should separate css and html from code (beside the obvious fact that they are not the same) was so that different team members could focus on each.
For example. I could develop the app and then hand the CSS responsibilities to the marketing department so they "brand it". They don't have to know Javascript but they sure do know their css and stylings.
Having said that. I'm definitely more affective at working with the entire component in one file than to break everything into it's own file.
Great rant. I've had a similar feeling when it comes to using inline CSS vs. creating class/IDfor an html element.
Some people say, that one should "never use inline CSS", which I think doesn't really make sense in every single scenario.
Let's say we're building a small website, and we use an element that we know will never be used again in the context of the page (eg. some special button). I believe that creating an id/class for this element just doesn't make sense (I hate jumping around the code, even when using editor that allows screen split). Quite often I see those extremely long .css stylesheets with millions of classes for what would seem like a small website.
One can paint himself in the corner by being extremely devoted to not using inline CSS. Let's say we create a class and we use it for 3 divs. Then we realise, that we need more margin for just one of them, compared to what we've defined in the class. Now we have to create a new class for this element and repeat hell a lot of code (or create even more classes to keep shared code / create new classes to describe the differences). But we could extract just the margin to the inline-css, and leave the rest of the shared code within the class. This way we have least amount of code doing what we want. And if we ever want to change the margin, we could just change the value in one place, not risking the "chain reaction" that forces us to change a lot of code.
Generally speaking, I think that when word "you should NEVER do that" appears in the discussion, it's good to be a bit suspicious and not accept every concept immediately.
5:10 - took me like 10 years to realise this.
Now I write everything in one unit, till I get a eureka moment how to separate it all, then refactor. Result is much cleaner separation and parts of code are actually reusable when working on next feature.
Your videos put me in the "coding mood" like nothing else! :)
+Anton Loss so glad to hear this, its the best feedback possible because it's EXACTLY what I aim for.
Thank you MPJ, this is a really great video and I will try to use these tips when working. Thanks again!
glad that you liked it!
Great lesson as always :-)
Maybe you can share with us YOUR experience with React. My problem with React is, that there are soo many tools, additional libraries (server side rendering, webpack) and concept's to use (redux).. Incredibly hard to find a starting point and confusing. That makes me unmotivated start to try it out. If I'am getting disappointed, all that work's has had all in vain. Is React recommended for big applications or just SPA?
Keep up the good work!
Dealing with a legacy system using classic asp, I thought this was bad for the longest time as well. So when I saw angular 2, I was miffed. Why are all the templates inline?
And then I had to refactor and take components and insert them into another project, and realized that having the CONSERNS all in one location allowed me to simply pull 1 file, 1 component, 1 idea, and add it anywhere valid angular 2 could exist.
instead of having to search through css, make sure I have all the classes and id's, making sure I have the right html snippet. SUddenly it all makes sense!
I created a playlist to refer people to for good folder structure ideas and I've been looking for a clear explanation like the first half of your video. You explained it more clearly in your rant with your papers than any of the dozens of other videos I've sifted through. Thank you for making this.
Vertical Slice Architecture comes to mind for a correct separation of concerns for folder structuring
Do more videos like this. Ideas, concepts, deep exploration and deconstruction of "Best Practises" its the way to go for improving programming mind.
Your videos about tools, performance, composition over inheritance etc are really put some of my thoughts to place. Big thanks for that, truly.
I've seen this mistake a lot in an OOP context too. Typically the 'User' class starts breaking over 150 lines and somebody decides its a good idea to cut and paste all the private methods into a module, 'UserHelper'. This happens a couple more times ('UserQueryHelper', 'UserSomethingElseHelper') and voila, you're having to grep the whole codebase every time you need to find a method defined on user. >_
I have to say I really like your videos. Although I don't share all your points of view, I find it very interesting, refreshing and challenging to feed my thought on the matters you raise.
Fantastic, you opened my mind now. And now i begin to understand how to actually separate things.
Pure gold, I needed to hear this so bad right now. thank you!
Thank you. . you have somehow eased my issue with this.i hope u are well now
Although I agree that separating html, js and css is not separation of concerns, it’s still pretty handy: you can open html, css and/or js of the same component in two tabs of the code editor and edit them side by side rather then scroll one bigass file up and down.
This is still the absolute best video on this subject. Props.
Yep I had the grab my pitchfork and torch reaction but took a step back relaxed and then came back and listened again. found that it did actually raise some questions I have had before.
I am mostly a C# developer though that is changing of late. Early on I would think a method I was writing was getting too long and would pull pieces out to be a private method in the same class. Then of course you try to unit test that code and since it was private you couldn't mock it so you had to still test it as part of the public method. So you then play with making it internal or worse public so it can be tested separately though the original is still dependant. then you move it out to a class with an interface so you can mock it.
Over time of course I have gotten much better at seeing the "seams" and breaking by true concerns but it took a lot of coding and really ugly code to get there.
Thanks for challenging our beliefs yet again.
this video is gold. thanks mpjme
The "Over more than one pages" thing is so people can see the entirety of a variable's scope. With javascript now, you can create small local scopes, but it used to cause a lot of mental friction to have to scroll up a couple of pages to see what the contents of a variable were (e.g. had it been initialised). Function separations were never entirely arbitrary, and they had the advantage of bottlenecking what information came into and went out of a specific block of code.
Brilliant as always!
Interesting talk, thanks. I think the problem though is that the web is used for two completely different purposes:
1) Distributing content (blogs etc). In this case, it makes sense to divide your content (HTML) from your styling & layout (CSS).
2) Applications (Gmail etc). In this case, there isn't really "content", there is application data ("model") and some way to present that data (and respond to user input) - which in practice is a hodgepodge blend HTML + CSS + JS. In an ideal world, we'd have better building blocks for creating web applications that are more suited for this purpose than the traditional content publishing use (i.e. we need web components, but that is still work in progress).
Agreed. Separation of technologies is not (always) separation of concerns, but isn't the Vue.js/Riot.js way of mixing HTML/CSS/JS in a single file cleaner than putting them all into JavaScript?
Amazing video, thanks!
You drew a face at 10:31
Hahaha
cant unsee x.x
Totally saw that too! 😬
He also draws a horrified cyclops at 18:40
I thought it was a wonderful self portrait...
The separation of concerns is to separate things in groups for the "reasons that they might need to change", just like SRP. That is why components in React or Vue also make perfect sense. And, it is also why Vue is a better framework over React too.
Scott
Thank you, your view has made me rethink learning react, because really made noise to me, this whole mix html with javascript.
I was mulling over the matter
There WAS a time when the HTML/CSS/JavaScript separation made sense. That was when HTML was primarily a document format, rather than a programming environment. In fact, pure HTML is still a better format for archival text than PDF (not enough structure) or Word/OpenOffice (too much irrelevant structure).
Not that that's relevant to the modern use case, where HTML/CSS/JS is a general-purpose UI framework.
I think the ten lines thing is more about having functions that only do one thing so that they are easy to test. Every time you have a branch in within a single function, in the best case, you are multiplying the possible path combinations by the number of paths in the branching you just added. Smaller methods usually means less branching, which means less combinations to test which means easier to test. If we were easily able to test branches within a method in isolation, then this would not be an issue, but currently the best way to do that is to create small methods that only do one thing.
Smaller methods that do just one thing also make reuse much more likely and thus there is a reduction in duplication. So the idea behind the 10 lines limit is to encourage splitting, because people are lazy.
+foobars I understand the intention, but expressing the advice in the form of line length limitation is damaging. Having small and short functions will not make code testable, nor will it make them isolated and doing just one thing. Short, small functions is a symptom of these things, not the other way around.
Rules like 10 lines limit, and 80 columns, can be easily cheated, that kind of rules just lead to bad naming of variables. Also it is an open invitation to inline several expressions into one line. Force your team to use those rules, and please don't surprise when you get code that looks like "const fn = (a,b,c=b*2+a*6) => c=2+b+c*c*d,b=7*c+1,a+b+c". Come on, use "code golf" only as sport, not for production. Let minifiers minify ;)
Programmers in their early stages see a correlation between LOC and loss of control. This is usually where OO comes in because it contains excellent control structures to reduce LOC. Some people never grow out of this phase. It turns out that it's not LOC that makes you loose control of a code base. You could have a file with millions of lines of console.log("Hello, world!"); That is extremely easy to understand even though there are millions of lines of code. It turns out that complexity is the real problem. Only when programmers realize this can they grow out of OO and start to look to paradigms that manages complexity rather than LOC.
There are some good things with separating, but the browser is able to optimise HTML, CSS and JS separately very effectively. If you're thinking about page rendering, you want to get HTML (DOM!) and CSS (CSSOM!) going as soon as possible. If you rely on JavaScript to do its thing, you have to wait until the DOM is ready before you can really start messing with it, and that means your render times can be affected.
Now there are certainly some good benefits to JS managing some of this, but for pure render performance, JS is... challenging.
Render time is indeed a vital metric and certainly worth optimizing for but it's not the only key metric. Maintainability is perhaps even more important. I was going to say render optimization trumps maintainability if you are loading megs of code but then... maintainability becomes so critical in that situation so even then. Teams will change over time and the next guy needs to be able to read your code or the thing that you so carefully built will become a house of cards very quickly.
That's why we have server rendering and webpack
so why have the frameworks that use shadowdom in javascript such good benchmarks?
React + webpack + html and css into js = super fast
generally on SPAs you cant do shit without the javascript anyways
Thx! You convinced me to take a second look at React :)
Have you ever read Introduction to Objectivist Epistemology? It calls the phenomenon where we only hold so many units in our consciousness at once the, "Crow Epistemology" where there was a study done on crows to prove that animals (including humans) were like that.
That's the way I need to explain to others of this field :) Thanks for idea.
Divide & conquer is actually a recursive paradigm, but I too like to think of it in line with separation of concerns. :)
Fantastic video though, I wish more people I worked with could think this way when they introduce new code. I always find myself untangling it myself and separating things properly.
Really really really good. Thank you for correcting me :)
Nice to hear my initial reaction that separating html, css and js didn't really help make the code any easier to write, read or think about wasn't entirely wrong. Of course, when you're learning, you just assume the code masters have good reasons for such practices and iron the habits in despite any reservations.
I think when people say, "Separation of Concerns" in regards to HTML/JS/CSS, what they are actually concerned (PUN?) about is the clarity of the code. Because of that they should be educated about the concepts I call "Separation of Context" and "Separation for Clarity".
These concepts are based on three points:
1. HTML has the SCRIPT and STYLE tags; and PHP and ASP have inline code execution syntax. They are there for good reason, and should be used appropriately.
2. As much as possible, keep styles within the STYLE tags and Javascript within the SCRIPT tags. I am seeing fewer and fewer reasons to use the "STYLE" and "ON-EVENT" attributes on an HTML element, especially if you are using a library.
3. If you need to pass values from server code to client code, do that by setting them to client side code variables before the actual client side functional code. Even better, IMO, provided all of them to the client side code as JSON.
These three points provide enough "separation" that the code on a single HTML file/template can be read with minimal confusion. Beyond that, to use the classic SOC argument here is unreasonable. It is like assuming these features are slated to be removed from HTML and server side code as a result of each of them no longer needing each other for a rich user experience.
So again, "Separation of Context" and "Separation for Clarity" instead of "Separation of Concerns". Code remains clean, readable and can exist on the same file.
Very nice rant! Totally agree.
Hey Mpj 0/
Just passing to say that your lecture at BrazilJS was awesome.
It was a pleasure to meet you there, I hope you enjoyed your time here. =D
Good Rant/Perspective. Liked and Subscribed. Cheers
A massive advantage of React / React Native is that you can have an app which renders for the Web, Android and iOS github.com/grigio/HAgnostic-News and it isn't an abstraction because you can take advantage of the native components that each OS provides
First of all, I totally agree that the separation has to be meaningful in terms of concern rather than just looking at technology. I do though think that it's rarely useful to put those technologies in the same files, if it's possible and meaningful to separate them. Take some Angular component for example. It's completely possible to separate the technologies into different files and that it often meaningful because the separation of concern is already made by creating a component that only does one thing.
Fantastic rant! I'm actually in the middle of rethinking the way we do modules and this had a lot of good arguments I never thought about! However I did miss having some practical dummy examples to back up the separation of concerns.
+Rudi Ørnhøj thanks! Yeah, the problem is that I don't have any code to show. I encounter this at work a lot but I can't reuse that. Perhaps I could re-write the case for the videos.
funfunfunction that would be awesome - if you do I hope you'll take something as low practical as files structure briefly into consideration..
On a side note i believe that design pattern and informed decision making (beyond "we think this is right" is lacking in loosely typed language)
great show!
Omg I've totally lost myself when you said "VAHAHA! Ok. This is not going to be Q&A anymore..."
good function extractions leads to better readability, by allowing you to quickly figure out what the extracted function is doing.
If you have to re-read the extracted function again from top to bottom, because they are so arbitrary, then it is poorly extracted. In that case, comments would be better.
That's what I learned from the video, at least.
Great video again.
@9 minutesish
It is separation of concerns. It all depends on your concerns. You have a fallacy in your reasoning. You seem to think that separation of concerns means that a problem can only occur at one place (or one file), but as you point out it can occur multiple places. This has not necessarily anything to do with separation of concerns.
Consider the two scenarios:
1) Separation of concerns: 1 css file, 87 html files. You need to fix a CSS mistake. You only need to update that 1 css file.
2) Mixture of concerns. 0 css files, 87 html files that include css. You need to fix a CSS mistake. You need to update all 87 files.
It is quite easy to point out the benefits separation of concerns brings in this scenario.
However, as you mention, some times you have a problem that occurs in several files, both HTML and CSS, and possibly javascript as well. Separation of concerns may help against this, but not necessarily. I fail to see how this is a problem with SoC as the problem can occur regardless of it.
Concern = shopping cart, settings page, shared ui components like buttons, global company color (spotify green)
Concern != css, html, javascript
You are conflating separation of technologies with removing duplication - we can have shared variables even if we separate by concern instead of technology, so it would be just be one change in scenario 2) as well. The difference is that we can a scope it - since CSS files are always global that means that we have to be very careful when adding or removing CSS because all CSS affects all parts of the app. If you keep shopping cart-related CSS in your shopping cart component, rather than in the global css space, you can work much faster and safer because the scope is as wide as you need it to be, and no wider.
Eh, okay. I'll let you define your own concerns. And I am totally onboard that this can be solved with variables. However, I still think you are in the wrong with the "jumping between context", or context switching (opening/closing files) is a problem. One of the good things with SoC is the context switching. You worry about one ting at a time. You seem to hint towards this being about how you work in you IDE. The alternative to context switching would be what? Scrolling or jump to line?
You actually convinced me to try out react :))))
This is why I love Styled Components
This reminded me of an article related to what Casey Muratori calls "compression-oriented programming"
We're not separating html, css and javascript. We're separating structure (mostly html, but also simple ifs and for loops that are only about creating a structure). We're also the styling of the page, which is why we use classes instead of inline styles since styling has nothing to do with structure. And lastly we separate the logic, that transforms whatever the business needs to whatever web components need to function.
So no, separating concerns is a whole other onion.
Very good video.
Have you read the book "Clean Code"? In it Robert C. Martin talks a lot about the importance of dividing code into many short and well-named functions. I thought that sounded like a great idea but now I'm not sure which coding style I should adopt.
I think we talk about the same thing, but I think that a lot of people twist what Uncle Bob says. Reading that segent again I think we're talking about the exact same thing.
The thing I want to stress is that separation of concerns (often) cause short functions, but it's not the other way around.
I really think that it is misleading to give line number counts on how long functions should be - it's over-simplified and superficial advice. The goal is to *separate big problems into smaller problems, isolated from eachother*. Doing this almost always CAUSES your code to be a lot of short functions, but arbitrarily writing short functions does NOT CAUSE your code to be separated into many smaller problems. I see junior programmers writing extremely hard to follow code because people have twisted Bobs advice into the dumbed-down version that is "write short functions".
I'm surprised the simple notion of code reuse in being ignored here. The reason we separate JS & CSS from HTML is because the same JS library or CSS file can be used by multiple HTML pages.
While separating code into files is a necessary precondition to making code reusable, it doesn't make code reusable. That would be like saying "I'm buying golf clubs in order to golf". You also have to get out there on the course, or you will have wasted money on expensive clubs.
Thank you, it is a valid point. It is practically answer my first concern. Now, what about unitTesting?
Fair enough. But in extending your analogy, the impression I get from your video is that you're telling people: "You don't need golf clubs to golf. That is a falacy." or perhaps I'm misunderstanding.
For me the solution, historically, has been parameter capable templates on the back-end... ideally with an easy looping method. React is basically just a really good template engine. The idea that templates should be packaged as single units is not new, it's just that React brings it to the front end.
(See EJS, Jade, templates in PHP, Java etc.)
That was maybe the nicest, friendliest, kindest rants I've heard/seen. ;)
I agree (almost entirely) with everything you said, but I think it's important to note that you've come at this from a full stack developer perspective. There are other perspectives that might need a little bit of time to consider as well.
I have worked with a number of developers who only knew how to work with one or two of these "concerns".
Putting Html in your javascript files is a perfectly logical thing to do when you understand how the two languages work and interact. But, putting Html in your javascript file when you have a designer who creates the views to accomplish some "design goal" is going to create problems for the teams that work together.
Being mindful of the reasons that we separated the code into these three buckets in the first place (display logic vs interaction control vs design)*. I've found that we often encounter problems that span all 3 only when we either: failed to consider how certain parts of the structure "rely on"/"interact with" one another, or when we try to do things that are not easy, and rely on hacks to achieve.
*There were also factors of bandwidth and code duplication that influenced the separation of Html and Css - and Javascript wasn't used for what it is today either, so perhaps it's just the evolution of things that their separation change with it.
That carrot function looks tasty, bro! Good stuff as always.
I agree with your opinion and in some way you are right. Just arbitrarily branching logic into just HTML, CSS and JS is nonsense. But also I think that writing complex operations in JS just for the sake of eliminating the use of HTML and even CSS is overwhelming and sometimes it could be non-performant.
So I agree we should separate by our "concerns" or "Domain problems" but I think is still a good practice to separate HTML and CSS from JS whenever possible (Think of the separation of concerns as separating by Components or units of work and think of the HTML/CSS/JS as a meta-separation of concerns).
Entertaining and informative as always, I have to admit you've changed my view a bit.
By the way, which type glasses are your wearing ? :)
No way. It's really nice to have my JS open to the point where I'm programming and right beside it I have the html file open to the point that corresponds.
I used to do that scroll up and down a million times thing... then I started separating file types and started saving time and increasing productivity.
But with, for example, React, you still separate your app into components, each of which should be of a manageable size. Plus, nearly every code editor can display a split view of the same file, which alleviates the scrolling issue even on longer files.
Yeah, it sounds like we're on the same page. Separating everything out is exactly what I'm saying is good. More modular code is excellent and easy to work with. I don't exactly agree with his idea that the pieces and code that work together have to be together.
Especially having the languages separated out into html, css, and js files is really great and useful. It's far from "completely nonsensical" as he proclaims in the video.
great Q and A
What do you do the papers after the video ? do you throw them away or reuse them.?
"Hey, hey, MPJ, how many trees did you kill today?"
Seriously - get a handheld whiteboard! Every time you toss one of those A3 white cards over your shoulder I shudder! ;)
On topic - this has given me lots to think about. Thanks for the video
+Jackson Bates this comment is so common that I have to make a video about my thoughts on efficiency. ;) please understand videos (at least these ones) are seen by tens of thousands of people and you have to divide the cost of props by the number of people watching to get the actual cost.
+Jackson Bates as for a handheld whiteboard - those things have glare + I cannot put stickers on it + I cannot throw them around. Also, I would bet that the energy cost to produce one whiteboard is that of 10000+ papers.
funfunfunction I understand the logic of that, but I disagree. You could also argue that thousands of people are witnessing you waste paper, when you could alternatively be setting a better example to those same thousands :)
But, hey, it's not like I'm gonna unsub or anything...you be you, you wonderful bugger
[serious] Where does this idea that people in public can't ever do anything anyone might perceive as wasteful come from? Did you even consider the benefits of what he's doing, or just criticize it because you consider it wasteful?
The way he throws them around and quickly writes on them adds energy to the show. It's adding to the entertainment factor of the show while informing the audience and as far as I can tell adds a unique "thing". I'm going to remember that FunFunFunction is the guy with the cards he throws around.
I understand the reasoning behind this comment, but I think FFF pointed out very well that the paper is not underutilised (many people watch these videos). We cannot reduce our resource consumption to zero without making extreme and unpractical changes (like bringing 10 glass jars with you to supermarket), but we can decrease it where it is unnecessary. What is the ratio of resource to value for a pizza box? How about using metal cutlery instead of plastic ones in food courts in supermarkets?
Using the 80-20 Pareto principle I do not think these papers in the videos are the 20% we should focus on.
Hey @MPJ, thanks for the video and the insights! Just wanted to comment on this from my experience. I'm a fan of React and it really makes sense to me to put HTML and JS together. As for the CSS, I'm still not convinced. I haven't really tried it a lot myself but from what I saw so far, I think it ends up generating code (styles) duplication. It's also a bit harder and counter intuitive to reuse styles. I've been using sass with BEM and some ideas from SMACSS (on how to separate things) for a while and I think that works really well with React. Now, I get the idea of modules that need to be distributed (think of packages on NPM) and for these cases, putting CSS on our Javascript makes a lot more sense but, right now, that's pretty much the only case I would consider it. Am I missing something?
+Rafael Bitencourt Im not completely convinced either, but I also think we've been dealing with the backsides of CSS files for so long that we just don't see the problems anymore. I mean, SASS is an entirely new transpiled language that we're introducing! You say that it's harder to re-use styles with react - have you actually tried giving it the same benefit you give CSS files?
Hey @mpjme I really like your videos and the way you explain things, keep it up!! :)
A thing, that I, as a guy that's kind of new to programming, would like to see explained is Dispatcher/dispatching. Why and for what do you need it?
I agree, css/html/js can be together. That's a consensus now a days, I think.
Webcomponents are here for that. You now create a component (natively) with it's html/css/js content isolated.
BUT I highly disagree that the React/JSX/REDUX approach is the right one. I prefer the exactly opposite. Instead of using JSX to insert HTML into JavaScript, it's better to put the javascript and css together in the html page, just like Polymer does, for instance.
That's something I would love to hear your opinion: the Polymer framework.
I am totally with you in the matter that HTML/CSS/JS might not be a separation of concerns. Still separating each (HTML/CSS/JS) improves code readability and maintainability. For example, If i had a color or layout issue 80% of the time it is a CSS typo or something related and i would definitely, definitely, definitely prefer browsing my CSS files instead of JS which is, to me, a language that HURTS the eyes. (Might be the reason you have a thick glasses though, no offense ;) )
Whilst I agree that separating JS/CSS/HTML in the traditional way is old fashioned and possibly even obsolete, I feel that your not understanding the reasons we did that back in the day. It wasn't arbitrary, and saying that it was indeed worth doing and was separation of concerns is not 'bullshit'.
Imagine if you will you've got a job working on a legacy enterprise web site in the year 1998.
The site is 400 pages in total, and each and every page is littered with font-tags, b tags, i tags, nested table heirarchies and so on.
The bosses have asked you to change the colour scheme of the site because the company has rebranded it's corporate image.
Without a cascading style sheets, you have to edit each and every one of the site's 400 pages.
With them you just change a handful of values in the CSS.
Same goes with any javascript snippets. They were a lot less prevalent back then, but they were in use. One site I worked on had a mouseover effect on it's navigation system, and it was required to be removed, the result being the same tedious editing of code, and me as a junior programmer at the time complaining to my boss about wishing that JS was in a seperate file. The boss said we could do that in the next version but for now I just needed to get typing.
To make a long story boring, seperating out HTML CSS and JS was a massive timesaver compared to the way things were before we did that. Sure it means you might have some problems which span the seperation gaps, and you might have to flip between several files sometimes to find and fix problems, but believe me that is a way preferable situation.
As I said at the start, I'm willing to believe that such an approach is now obsolete, I've see many things come and go in my time and I've found in my later programming years that I don't have the effort to study any new concepts until I'm sold on really needing them. As you can gather from the fact that I'm here, I'm currently levelling up my Modern day Javascript skills, and you're videos have been most helpful, so Thank you!
I wonder, if there is a webpack plugin that would extract copy-pasted js from html files into js file... and bower plugin for css... that would be great. Something like tree shaking but more of cherry picking. :)
Oh man I don't even know what to tell you. I don't think you understand what's 'component' until you really create a tool yourself. What 'component' does nowadays has no conflict with you are wishing to have, but actually better.
The only reason to put a hard limit on function length is to search matching brackets (or indentation for Python). When a function spans more than one page it's hard to find a matching bracket when it's broken. Otherwise, functions should just be simple enough.
Hi nice video,
Without judging which one is good or bad, I think that separating CSS/HTML/JS is just another way of separating concerns: styling, composing HTML, logic. And React learned from previous experience and defined it's own way of separating concerns that groups CSS/HTML/JS under a single concern: rendering.
So I hope this video is mad about the inappropriate use of Separation of Concerns and of the people that follows it blindly, not to the Separation of Concerns itself.
React is not alone with this; web components also support this bundling of code of different languages in one file representing a concern. Polymer is a big advocate of this and I like it. It has great effect on the way you can reason about the code.
There is still a lot to sort out in that regard and I'm sure we're not at the end of this development, though. But the direction is good.
Re seperation of concerns in JS only: a lot of people (including myself) seem to be caught in the trap of the chapterization when thinking and working object oriented. A *lot* of code depends on the programmer invoking the API in the correct order to subsequently build up an object representing a state that has to be built up before it can do its actual job. This is bad. Encountering such code I usually end up rewriting that piece of code with a function, inlining most of the functionality and maybe even externalizing the creation of the state data.
doing things the old way was enjoyable. doing things the new way is soul crushing. that's all you need to know.
Thank You, Really good video
I think you are better in explaining programming design and concepts like this video
than doing tutorials on coding
Hi MPJ, first, congrats for the very nice video! I don't like to put any business logic inside a file with html and js, but I use to build components or plugins where I put some html inside of javascript file, do you think that's not a good idea too?
Long functions are just code SMELLS. You don't have to try to hide it, but to think, if something is stinky or not about this function. That was my explanation.
awesome!
MPJ I love your videos! Please try out the Aurelia framework and give your opinions as to it's support for Separation of Concerns when compared to React.
Also, please do a show on what you think is the best way to save state in a SPA
Thanks!
Al;
Hello MPJ, I have question on your opinion about separating the function into part1, part2, part3, is just a visual artifact and doesn't help to reason about...But wouldn't it help when the purpose of function separation is for ease of testing?, unit testing for instance.
What's your opinion on where to place that "capitalise the first word" function? I know some people would put it into "utils/string_ops.js" or "common.js" or even "shared_lib.js". Should it be moved all the way to the top of the project since it's not component specific? Should it share a file with other string functions (which were used by different components), or just have whole file to itself?
I like your drawing of a carrot. Very artistic.
@mpj what I learned from books is that, we spilt HTML css and js into files so we can reuse them.
Great info! One question I do have is if this approach is possible if you are "progressively enhancing" a website? For instance, a screen reader wouldn't be able to run JavaScript so how could you avoid separating your code out by HTML, CSS, and JS if you need to be accessible to those types of devices?
I should write on this video, just write something. Thanks MPJ!
This was entertaining and you make some valid points. But what you should probably look into is why this was/is really done this way. People were/are not stupid to do this.
Some really good insight for me. It is hard to know what is "right" and "wrong" when you have more than one camp of seasoned developers telling you things :P
+colin ”Chozandrias” swenson-healey there is a lot of religion in the field, and we are constantly reinventing what is best practice. We learn and evolve.
In every form of study, there will always be people who cling to old ways.
+colin ”Chozandrias” swenson-healey yep. And I think that makes sense. We need conservatives and progressives to fight a little bit for their respective positions. Sometimes the new stuff is worse, and sometimes it is the opposite. Change must be able to withstand being challenged.
Can you explain what sckockets really are? it seems to me that i don't understand it clearly. I'm especially interested in websockets and socket.io.
Breaking a large function down into non-reusable smaller functions for the sake of keeping that larger function more concise isn't entirely bad. It does have the merit that you are now breaking a larger problem down into smaller ones (eating the elephant?), but more importantly it helps keep those small problems as separate units so that they don't become too intertwined which, IMO, also makes for very difficult to reason about code. It also promotes test-ability of those smaller problems. I'd say this is a bit of a grey area because MPJ also has valid points.
There was another video with a similar rant that mentions that future programmers won't know where these smaller non-reusable functions are used and won't know if they're safe to change or delete. I'd say if that's your worry, then you have a bigger problem with not being able to scope things properly.
I've had this exact conversation before (sans the React context)
Where's the comment about problems?
nice rant
Html is about view, css is about view and react is about view. So this all is about the same concern.
I thought your point on HTML, JS, and CSS separation of concerns was excellent.
Do you have any examples of how to combine the three? Any libraries you'd recommend for the task? Lastly does it have any negative impacts on responsive page design?
Hi love your videos, but you should mention the music and give attribution to the artists you use in your videos. It's like using open source code you have to follow the rules even (or especially) if the music is under cc license! Cheers
+Jürgen Klapmesser I buy the music.
ownd