These are chat archives for jescalan/roots

9th
Jun 2016
Tom Kraak
@tkraak
Jun 09 2016 00:10
@hajzso congrats!
Perry Kibler
@javaporter
Jun 09 2016 00:38

body(class=_path) is fine, but obviously, class='/index.html' isn't ideal : )

On a side note, thanks everyone for the help. I got contentful working fine, better than MM even, Roots is sooooooo fast, all the other complicated stuff is working, it's now the silly stuff where I'm spending an embarrassing amount of time.

Tom Kraak
@tkraak
Jun 09 2016 00:45
@javaporter what kind of stuff are you pulling from contentful?
Perry Kibler
@javaporter
Jun 09 2016 00:48
@tkraak quite a bit eventually, I'm moving this site from MM and right now I'm just doing images and text as proof of concept, but eventually I'll be pulling pretty much everything I can, including filters and sorting and stuff. I'm getting a lot better at Contentful integration if you run into any sticky spots.
I will say that, so far, there are a lot of advantages to the way roots_contentful works vs middleman_contentful
not bagging on MM, it's a great project and I've used it a ton, just saying
Tom Kraak
@tkraak
Jun 09 2016 01:25
@javaporter thx for the details! I'm pretty much in the same boat except I'm coming from Jekyll :)
Máté Hajzsó
@hajzso
Jun 09 2016 01:57
does anyone have experience with margin collapse with jeet? :S
oh there is a jeet gitter! sorry :)
it's not active so maybe someone can help me here
I have a #main element with col(1/2) and #aside with col(1/2), when I add a border or a padding to #main, my #aside jumps under #main :/
Máté Hajzsó
@hajzso
Jun 09 2016 02:04
okay adding border-box to * solved it :D
Tom Kraak
@tkraak
Jun 09 2016 02:05
that will do :)
Tom Kraak
@tkraak
Jun 09 2016 13:33
I would really appriciate if someone could shed some more light on our _path issue above, thx!
Jeff Escalante
@jescalan
Jun 09 2016 14:03
yeah middleman is a great project, the only reason i made roots instead of using it was javascript
the future of front-end tooling is not ruby
yeah let me take a look into the _path thing today I'll get back to you guys
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:04
If anything the future of tooling is C.
Jeff Escalante
@jescalan
Jun 09 2016 14:04
haha the future of nothing is C
but the past was!
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:04
I think libsass brings that into question, genuinely.
Jeff Escalante
@jescalan
Jun 09 2016 14:05
considering that its the only front-end tooling library that uses C, and postcss is significantly better, I would doubt that
accessibility is just as important as speed. if you want a successful oss project, you need people to be able to contribute
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:06
C works because everything else binds to it pretty well. Once you step outside the node.js ecosystem, sass is currently winning by a stretch due to it's C bindings.
Jeff Escalante
@jescalan
Jun 09 2016 14:06
think about it this way
the people who contribute to open source projects tend to be the ones using them
the people using front-end tooling are people writing front-end code
100% of these people know javascript
I'd assume that < 1% of these people know C
Daniel Box
@dbox
Jun 09 2016 14:07
I'm the 1% that doesn't even know JavaScript.
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:07
But not all of them can/want to use node.js.
Jeff Escalante
@jescalan
Jun 09 2016 14:07
it's a million percent more likely than that they want to use C
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:08
But because libsass bindings exist for <myfavouritelanguage>, and they don't need to write C, it becomes the path of least resistance.
Jeff Escalante
@jescalan
Jun 09 2016 14:08
I understand the technical advantages of C
I'm just saying that in reality, it is not what front-end tooling is going to be written in for the most part
And javascript is not going away as the only language you can use in a browser for a long time
Which means that people building websites are going to have to know javascript, which means that tools made to build websites will be written in javascript
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:10

Perhaps we'll end up at another language which can provide C-bindings.

Sure. But writing js != including the node.js stack. That would be seen as mutiny where I work :p.

So we use the libsass bindings in java. Works really well.
Jeff Escalante
@jescalan
Jun 09 2016 14:10
how so? node is javascript
node uses the same engine as the browser does
I mean if you are using a language other than javascript to run your front-end stack then I see the advantages of having a C library available
but the fact is most people are not, and most popular front-end tooling is written in javascript
and there's no particular reason not to use it
and it makes hiring developers easier since it's a widely known and accessible language among people who build websites
and you have less conginitive dissonance when switching back and forth between different tools and projects if they are in the same language
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:13

Installing node.js, managing it's further dependencies (outside those for the rest of your project), teaching people to use it, is madness over running a C library.

Yeah, I see your point about ease of writing tooling controlling the tooling created. But I think long-term, the projects that thrive, will be those that can be consumed from the most places.

Jeff Escalante
@jescalan
Jun 09 2016 14:13
it's infinitely more likely that a developer you hire to work on web projects will know javascript than any other language, so I don't see the issue with training
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:13
More with npm stuff than js stuff.
Jeff Escalante
@jescalan
Jun 09 2016 14:14
what issues are you having with npm?
seems like a very straightforward package manager to me, and installed by a universal binary, extremely actively maintained
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:14
Personally? None. But we already have a build/dependency management tool. Running 2 or 3 is too many.
I mean, I don't get the cognitive dissonance argument here. You hire a developer to hack on the sass, I've not once had to go to libsass and make changes there.
Jeff Escalante
@jescalan
Jun 09 2016 14:15
Haha right, so the solution is to use npm and javascript for all your web-related tooling
which is really super easy to do, and supported by large numbers of extremely stable and popular libraries
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:15
But when you build your backend/frontend in parallel, in the same project, how do you control multiple package managers?
Jeff Escalante
@jescalan
Jun 09 2016 14:16
That is the issue
API and front-end should not be in the same project
It's a recipe for disaster
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:17

API

You're assuming that it's all JSON/HTTP. I still like server-side rendering. I also don't think it is a recipe for disaster, the code sharing capabilities for us are huge (we do clojurescript)

Jeff Escalante
@jescalan
Jun 09 2016 14:19
There's nothing you can do with a single monolith project that you can't with an API/client split project
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:21

I see where you're coming from with the tooling. But I think that the users of these languages: https://github.com/sass/libsass/blob/master/docs/implementations.md surpasses the number of js developers. People want their RoR to just work with sass, and django people want sass period.

Monolith vs split is an architectural decision that I'm not sure how will play out yet.

Jeff Escalante
@jescalan
Jun 09 2016 14:22
Yeah I guess I'm just of the opinion that ror and django are dying
and will be completely dead other than applications that have to use them bc legacy
i say this from a company that used to be a rails only shop, and now does only api/client split, and saw a massive increase in productivity and quality as a result
the advantages of split api/client are so enormous
especially so in the mobile age, where you might need to make a mobile app in one or more languages
and if you do, you can just consume your own API without issue
i mean for starting a company today, I feel like it would be an extremely poor decision to lock in to a monolith system like rails or django
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:25

Me too. But even if you use flask or sinatra, you want a dead simple way to compile your coffeescript and sass, without fiddling with manage.py on top of everything else.

Admittedly, I'm not speaking of applications.

Jeff Escalante
@jescalan
Jun 09 2016 14:25
if you use flask or sinatra you should not be dealing with coffee or sass at all, they should just expose a json api
then in your client you can deal with coffee and sass if you want
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:27

Yeah, we hate monolith frameworks, https://juxt.pro/blog/posts/yada-1.html my company has just released this, a new way to look at web frameworks.

It's all part of a build process though. I don't think I'd send those down raw to a client, and tell them to compile it. As part of my build process I want to:

  • Build coffeescript, sass
  • Launch application
Jeff Escalante
@jescalan
Jun 09 2016 14:28
try it haha
it works quite well
expose the raw data to the client
client consumes and builds the site, making eveything that can be static as such
anything that cannot be static is consumed by the client-side js
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:29
Where's the advantage though?
Jeff Escalante
@jescalan
Jun 09 2016 14:29
api and client are 100% disconnected
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:29
It sounds interesting. But it would need to solve a problem.
Jeff Escalante
@jescalan
Jun 09 2016 14:29
you can use any language for the API that you want
you can hire a assembly developer to work on the API
and the project will still work smoothly
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:29
We don't have much of an api. We're not building an application.
Jeff Escalante
@jescalan
Jun 09 2016 14:29
you can work on both projects at once in parallel
as long as api docs are maintained, which are in english
so everyone can handle that
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:30
Jeff Escalante
@jescalan
Jun 09 2016 14:30
carrot.is is a split site
static front-end, cms as a backend that produces an API
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:30
Sure, it can be done. But are the big values still there?
Jeff Escalante
@jescalan
Jun 09 2016 14:30
huge
i promise, we have been experimenting with this for years
we're an agency, we make a shitload of sites
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:31
Have you any blog posts and such on the advantages? I think I need something long-form to understand better.
Jeff Escalante
@jescalan
Jun 09 2016 14:31
you know, we dont
i'll write one this week
i kind of took it for granted because we are in this little bubble within the company
haha
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:32
Please ping me when you do!
Yeah. I mean, leaving the node.js has been a huge culture shock to me.
Jeff Escalante
@jescalan
Jun 09 2016 14:32
i would be happy to move to a different language that's better than javascript dont get me wrong
but javascript is the most accessible language
Perry Kibler
@javaporter
Jun 09 2016 14:33

same here, I'm 100% on board with what you're saying @jescalan

One request, can you write it in a way that is friendly to people not in our industry? I'd love to send clients to it.

Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:33
It's why I love libsass currently, and can see other firms like ours using it.
Jeff Escalante
@jescalan
Jun 09 2016 14:33
if you are not using javascript, you need to evaluate whether the potential productivity boost from now using JS is worth the hiring impact of finding people familiar with whatever language you are using, but also know javascript haha
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:33
@javaporter I think there's a line to balance between marketing, and informing developers. Sometimes that is two posts, sometimes that is dragging along one of those 2 parties.
Jeff Escalante
@jescalan
Jun 09 2016 14:33
i do actually have a post on this
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:34
We don't use javascript. The company I work for specializes in a single language, which is our selling point.
Jeff Escalante
@jescalan
Jun 09 2016 14:34
right, but by making that decision you are limiting your hiring pool
someone presumably made that decision and decided that they would be willing to take the hit in exchange for using X language
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:35
Yep!
Jeff Escalante
@jescalan
Jun 09 2016 14:35
If they have strong justification for that, then that is entirely cool
But then they can't complain about the fact that all the good web tooling is not in that language and is in js haha
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:35
@jescalan If you ever get a chance to use clojure(script), it is entirely cool
Jeff Escalante
@jescalan
Jun 09 2016 14:36
I would like to, but would need a use case for it
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:36
It's just delightful to work in before anything else.
Simple > Easy.
Jeff Escalante
@jescalan
Jun 09 2016 14:37
I enjoy working with js, and am quite experienced with it
thats not quite enough
needs some practical benefits
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:39

Well, we get sass, because of libsass. And I think that there's more value in sticking to a single stack, and just consuming libsass, than there is in trying to manage bundler/rake for sass and npm for coffeescript. Being able to consume those all from one language, particularly from my server-side non-split world, is significantly simpler for me to mentally manage.

I like the flexibility.

Jeff Escalante
@jescalan
Jun 09 2016 14:39
better still is just using postcss
then you can use it through node, and it's more flexible than sass significantly
and you can get just about the same syntax if you want, or swap up pieces that you don't like, or add in optimizations you want
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:41
I totally think postcss is better. But I can consume libsass from my existing build tool.
Plus I think the secret to better css, is more about following http://cssguidelin.es/ than using sass. Postcss would probably shine in this area above sass, because I could enforce just enough structure.
I do have an evil plan to consume postcss using java's built-in javascript interpreter and browserify, but that's another story.
Jeff Escalante
@jescalan
Jun 09 2016 14:43
you might be able to not make it look ugly as hell using harry roberts' stuff using postcss as well
or you could use this: https://github.com/jescalan/mpg
;)
haha imagine a world where you dont need to hack you way into library compatibility and can just use it without issue
that is the world of node :sparkles:
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:44
I've come to hugely value understandable code over aesthetic code. I'll even type more ,if it makes it clearer. A trade-off not enough people are willing to make.
I'm currently fighting something that is a little big mpg-y at the moment. Inevitably, .left means something different to one part of the site than the other, this makes it hard to reason about the css.
My brain knows the scope of .staff--left though. and that it is different than .profile--left.
I'm not saying mpg is bad, I haven't read it properly, you probably have safeguards for this. But just in general.
I'm essentially saying I'm not smart enough to do any nesting. Code is clearest with dashes and underscores to me. I'll duplicate classes across pages, because it's easier to update and understand a page in isolation. Less to fit in my head.
Jeff Escalante
@jescalan
Jun 09 2016 14:49
yeah that comment doesnt apply really to mpg, if you read it you shall see
it's extremely clear
based on organization
i will make sacrifices for clarity as well, no question
really i'll sacrifice almost anything for it
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:50
Yep. Brains are small.
Jeff Escalante
@jescalan
Jun 09 2016 14:51
especially mine haha
too many projects, i cant remember all this shit
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:52

Yeah, I read a bit deeper. ids are essentially local-scope.

Pssht. The smartest people know how small their brains are. Sooner you realise that, the sooner you can externalize all the shit you don't need to esoterically balance, and just focus on simple (over easy).

Jeff Escalante
@jescalan
Jun 09 2016 14:52
its all about scope
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:52
This is why I like clojure and functional programming. It's REALLY simple.
Jeff Escalante
@jescalan
Jun 09 2016 14:52
i find functional programming to be quite difficult
it require a large shift in the way you think about programming
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:53
What kind of functional programming have you tried?
Jeff Escalante
@jescalan
Jun 09 2016 14:53
the functional kind
Tom Kraak
@tkraak
Jun 09 2016 14:53
:)
Jeff Escalante
@jescalan
Jun 09 2016 14:53
haha are there multiple kinds?
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:53
As in, where from? Haskell? Underscore, etc.
Jeff Escalante
@jescalan
Jun 09 2016 14:53
you can write functional code in any language that supports first class funcitons
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:54
Yes. This is of course true.
Jeff Escalante
@jescalan
Jun 09 2016 14:54
i do really enjoy the function signature documentation style
i forget the formal name for it
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:54
But, if you're doing it in js, and most things are mutable, it becomes confusing.
Jeff Escalante
@jescalan
Jun 09 2016 14:54
sure, but writing functional code means not using mutable things
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:55
I didn't "get" functional programming until I tried clojure. Which nails the balance.
Jeff Escalante
@jescalan
Jun 09 2016 14:55
you can also freeze objects and such if you really want to be strict about it
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:55
Immutable by default. Constructs for mutability on the outskirts.
Jeff Escalante
@jescalan
Jun 09 2016 14:55
i took a dive into functional and i think it's super cool, but unfortunately i think the accessibility hit is too large. most programmers dont know functional programming, therefore it would make my open source work and our company's hiring significantly more restricted
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:55
So you get all the simplicity benefits of functional programming. But you live in the real world where mutability has to happen.
Jeff Escalante
@jescalan
Jun 09 2016 14:57
it sounds super interesting for sure
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 14:57
My company will gladly supply you developers ;) Depends on your needs. If you want to learn something because it's interesting, you should try it. If you're constrained by hiring significantly, perhaps not. We've had no problems hiring for clojure though.
Jeff Escalante
@jescalan
Jun 09 2016 14:57
i feel like i would need to work for a shop that uses it in order for it to be practical for me though
and im still not sold on clojure haha
i would just run functional js
because js is :crown:
but i should try it before i knock it to be fair
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 15:00

http://shaffner.us/cs/papers/tarpit.pdf you should read this. and as many of these talks as possible: https://github.com/tallesl/Rich-Hickey-fanclub#talks mostly the keynotes, and the ones from ~'09. Simple made easy is a VERY popular one, for a good reason.

js is surprisingly complex in hindsight. I can't imagine using state/mutation anymore. How can I reason about it!

React is a good place to try practical immutability and functional programming.

Jeff Escalante
@jescalan
Jun 09 2016 15:01
we use vue :/
i just like vue a lot better than react
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 15:01
vue.js is just as good. Same principles.
I don't like react hugely. I like the ideas. Particularly flux/redux. Elm's architecture is good to look at for functional programming in components.
https://changelog.com/rich-hickeys-greatest-hits/ I probably should have linked you here for talks to watch. He wrote clojure, but these talks aren't about clojure, just good programming. Which happens to be clarity, simplicity and such.
Jeff Escalante
@jescalan
Jun 09 2016 15:11
checked out elm too, it looks like a great language but too incessible once again
will check out those talks for sure!
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 15:13

@jescalan Yeah, elm is just a good place to steal ideas from. Which is what redux and flux basically did.

They align quite well with your view on the world from what I remember of your medium posts. They'll organize your brain in some way, which is what I always enjoy :p

Jeff Escalante
@jescalan
Jun 09 2016 15:13
haha sounds good
Dominic Monroe
@SevereOverfl0w
Jun 09 2016 15:17

:point_up: June 9, 2016 3:33 PM

Do you have a link to it?

Tom Kraak
@tkraak
Jun 09 2016 15:23
@jescalan what do you mean by elm is “too inaccessible”?
Jeff Escalante
@jescalan
Jun 09 2016 17:55
@tkraak the number of people that are familiar with it is too low
@SevereOverfl0w i havent posted it yet, but i will and will send it here :D
so if you want to work with someone on an elm project chances are you will have a hard time finding someone
Tom Kraak
@tkraak
Jun 09 2016 18:16
isn't that the case for any young technology?
Jeff Escalante
@jescalan
Jun 09 2016 19:36
yep
haha which is why i dont adopt young technology unless it's for an experiment
Tom Kraak
@tkraak
Jun 09 2016 21:01
same here :)