These are chat archives for jescalan/roots
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.
_pathissue above, thx!
_paththing today I'll get back to you guys
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.
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.
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)
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.
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.
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:
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.
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.
.staff--leftthough. and that it is different than
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).
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.
@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