lsdafjklsd

Actually 100% 17 days still going

My wife's last day was the 10th but I had tried to get them to stop earlier, basically put my foot down. We actually left the city that Saturday, now we are dealing with driving around northern New Hampshire with NY plates. Locals are starting to take more notice.

I think it's really people's experience. I'm in your camp, I write functional javascript, I learned clojure, I think about writing software in a way where react-redux (and re-frame) fit the paradigm and get out of the way. Vue seems like Backbone v2 after drawing inspiration from Ember and Angular

I really don't get the love around vue... I always read the glowing sentiment and go, "Ok, I'm missing something, let me go back to the vue.js docs and see what's good"

Things that are a deal breaker for me:

Template language... You can call it 'separation of concerns' all you want, but just let me generate templates using the language I already know, JSX is great

State management... I cut my teeth with Ember professionally for a few years, and really loved it up until I built a data intensive app. Having state spread across different controllers is great when you have many different routes and pages, but if one page turns in to a photoshop like app, controllers make a terrible state management tool. It doesn't seem overly complicated to me to use redux along with react-redux's connect function to connect regular functions returning JSX to your state object. Looking at Vue.js, it seems like I need to learn Ember-lite + Angular (custom directives).

Yea basically this. Built a 'big data app' using Ember, which was all well and fine until some of the routes essentially became their own apps, that were more akin to apps like photoshop. MVC really broke down for us here, and it wasn't until we introduced react / redux and slowly refactored the application until things got more manageable and sane.

In the apps that I've built, having many components manage their own private state makes it hard to coordinate said components, because all of the application state is stuffed inside different jars that you can't easily peak into.

It's been much easier to pull all app state into a central, db like structure, and allow components to connect and query that structure for whatever data they need. It makes making changes to components in the future easier, because all of my data is normalized in a structure, and it's all possibly available to any component in the app.

I've found that with MVC, if you design the private state a certain way, and in the future need largeish independent components to coordinate, well, you're going to have a bad time.

So redux or not, I'm definitely a fan managing state as it's own separate thing, and having components able to query and connect to that data structure, without having to pipe props down a tree of components, which leads to an app that's hard to change.

There weren't really 'legions' of front end devs when node came out. People were just learning backbone.js and the idea of SPA's being viable was still forming. It was not easy to pick up if you were coming from something like rails, because it had no well documented complete framework solution. The people that were doing node in the early days were legit back end folks. I am now a front end developer, but I learned on rails and I remember having a hard time 'learning' node. It had no debugger (I was used to something like pry) and was generally a collection of 'low level' libraries.

my dad is a fox news republican, a few years back we were driving for 5 hours and were listening to npr. he was basically waiting for the overt liberal bias, but instead we listened to a bunch of fascinating stories and interesting shows about a variety of topics. I read somewhere that npr isn't liberally biased, but their fan base is mostly liberal, because liberals tend to prefer news that has no bias. It's also not loud and obnoxious, which they like.

Yup, front end development is light years ahead of JS. sad

Parinfer is a huge game changer. Everyone afraid of writing lisp needs to try again using parinfer.

The issue is more that I have to add, and use an immutable library vs it being just baked in to the language. I have to convert from and to JS. Worry about setting a deep value that is regular JS. It's janky is all.

> with not very nice tooling

The tooling is the best. Figwheel is hot reload that never goes down, devcards is revolutionary, and a browser repl for live in editor evaluation...

> significantly different from the existing javascript code base you already have

It actually isn't. Clojurescript is basically javascript that's immutable first, has underscore in it's core library, and then a bunch of other awesome language constructs. The libraries use the same patterns, re-frame is a nicer, more succinct abstraction over react-redux.

> poor interop to the existing js ecosystem

The interop might be the best out there. Seriously you can write javascript in clojurescript. you can straight up import es6 jsx javascript into your clojurescript code. (thanks Google Closure)

> For javascript, that crowd of alternatives is so much larger

I mean, what are the options? Clojurescript's benefits are so much more than the language. The real pluses for clojurescript are the Google Closure compiler, hot reload, browser repl, devcards, front end libraries. The language is the cherry on top. There are no alternatives that have a comparable platform not completely alien to JS developers.

but the OO api is a bummer, give us the Clojure Atom api!!! vamos reframe!

At work we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything. It's been a huge boon.

PS Ramda it eats lo-dash and its imperative API for lunch. It's for power users, everything curried, higher levels of abstractions. Pick it up and learn it, it'll make you a better programmer.

Next stop Clojurescript. Om next is a library where you can get a feel for a Falcor + Relay stack in like 70 lines of code all without the specific tech bloat. David Nolen is a UI profit, just follow him.

Reminds me of an episode of Bones:

a: These are what are known as "Guidos.

b: (chuckles) Yeah, Sweetie, I don't think they actually like to be called that.

a: But they do.

a: That's what they call themselves, although interestingly, not all Guidos are of Italian descent.

b: Really?

a: While the styles and mannerisms are based on Italian-American tropes, the Guidos can be of any ethnic background.

a: They gather at the Jersey Shore.

a: The male bonding is near homoerotic.

a: The friends or "bros" are more important to them than family.

b: Right.

b: And how do you know all of this?

a: I stumbled across a compelling documentary about them.

a: The anthropologist in me was fascinated.

As an artist the apple pencil has been a complete game changer for me. I don't find tablets particularly useful for much other than drawing, and the apple pencil delivers the most realistic experience to date. It used to be the case that working digitally meant you needed to learn how to apply your skills to the digital environment, but now when I draw / paint on the iPad I'm just doing what I'd normally do; it looks the same.

In short that's up to the developer. It would be like asking how does Redux handle security? Well it doesn't, it just dispatches an action object to functions, the functions you wrote.

Om.next takes code you writes and makes it go.

It seems that moving html into javascript versus moving javascript into html has been the winning choice. Like the clojurescript counter parts, I want to write code.

I'm basically saying this. At work we've started to move from Ember to React over a year and a half ago, directly because of the work David Nolen has done in the space. And now we have Redux wrapping an Immutable.js map, and are trying to piece together the rest of the stack that is om.next. It would be wayyyyyyy easier and better and less hacky to just write clojurescript. Getting people on board is sadly super difficult

I think the problem is that the people using React see the grand architecture in Relay / Falcor / Om.next, and are trying to recreate those API's using current libs. There are still a lot of parts missing when you try to build an app with the same abstractions as the aforementioned libraries, and I think the author is correct about 2016 being a year where those gaps are filled.

What we really need is a translation of om.next to javascript. That library summarizes all the good ideas from Netflix and Facebook into a small library for every day use. The fact that it's in Clojurescript makes it a non-starter for others, too bad because it's a really great eco-system.

edit, list technologies: React + Redux is a good start, but we need composable queries and a router (falcor) or reconciler (om.next) that manages data fetching / caching. JLongster has done some experimentation here with datascript integration https://github.com/jlongster/redux-experiments/blob/master/s...

Working for me

Yea SUITCSS is a great solution and it's completely cleared up so many CSS issues my team has had in the past. Looking at rscss I kind of cringe because it doesn't make it easy to reason about where classes are in the markup. Like .search-form is affecting .submit, but looking at the template I have no idea, and I also don't even know which file to look in.

The no nesting thing is huge! We refactored a lot of CSS earlier this year and that was one of the biggest pain points. Coupling the structure of your template to your CSS makes changing things very painful. Nesting also creates ambiguous classes that have no obvious connection, consider the following:

.my-component {

    .header {
 
        ...
  
    }  

}

You would just see header floating around in the markup, unsure of where it's namespaced.

Also I disagree that you shouldn't modularize your CSS. We now create a CSS file who's name corresponds with the class name.

/styles

  /components
  
    my-component.css

and in the markup

<div class=".MyComponent-wrap">

  <div class=".MyComponent-title">  
    ...  

  </div>  

</div>

With CSS like that you always know where a style is declared, and the order of the classes do not matter.

More on the issue: http://nicolasgallagher.com/about-html-semantics-front-end-a...

I think it's the best ORM for Node. That said it makes me really miss Active Record, which is just... sigh the best.

Yea I bought a Nexus 6 when I signed up. I thought that was the only supported device though.

edit: I also had no previous Google Voice account to transfer FWIW

This does not match my experience. I've had Fi for a few months now and I have 0 complaints. I'm in NYC and switched from AT&T, but even when visiting New Hampshire I haven't been affected by dropped calls or bad service.

Sorry if it wasn't apparent but I agree / advocate strongly for what you mention, and we use that model at my company. If you look at how Om evolved though, it started out with that simple model of passing the state object down to child components. Then cursors were implemented to make it easier to pass around parts of your global state without having components needing to know everything.

GraphQL doesn't mean moving to stateful components, it's just a nicer way to have a singleton data store because instead of chunking and passing a map around, components can declare which data they need. In that system components are still read only, and dispatch to external pure functions.

David Nolen does a great job talking about the trade offs and the evolution of everything in this talk https://www.youtube.com/watch?v=ByNs9TG30E8& I highly recommend it!

I use Clojurescript and love it, and also really like Elm. I think the difference is that the Clojurescript community is really on the leading edge of web application development techniques. Elm does it all right, in a similar way, but more basic. In Elm you're also encouraged to develop UI's with no private state and a single Immutable app data structure, but that strategy only gets you so far. Om has the concept of cursors to deal with this, and Om Next will have the evolution of that in a GraphQL type solution which I think is the future.

So basically I'd do any serious development with Clojurescript. Elm is a really cool thing with a small community that's fun to mess around with.

Yes, I came to recommend this book. It's a fantastic read, one of my favorites.

This music is amazing! Is it from one playlist on soundcloud?