It can quickly become a pretty big pain in the ass to maintain multiple long-running branches. But I think its a reasonable way to go in your case, and the pain is more an inherent property of maintaining different versions of the same code base.

Why not babel?

I agree @jjshabado, was just checking if I'm missing some other obvious play.

@grue I'm babeling it but the codebase has to be rewritten to be ES6. It's working fine as ES5 right now and causing no harm.
Updating the codebase from ES5->ES6 (+adding babelify to package.json and updating Grunt to use it) is what the branch is for.

I might even merge some of it over quickly. First step will be rewriting for "import". If that is fairly painless I might not even keep the ES5 and merge right away.

has anyone here used/learned flexbox yet? looks like only ie11 has full support which will probably hold it back for quite a bit longer.

How is rest supposed to deal with duplicate-named resources? i.e. in a todo list there's 2 entries that are identical, you click on delete on one of them, rest would say send a DELETE to /api/(resource name) and then um all hell breaks loose I'd assume.

Use display names and unique TODO IDs.

I feel like the only appropriate response to that is fire the DBA for not knowing what a primary key is, fire the backend dev for being a moron and not selecting table.id, fire front end dev for not knowing what a hidden form element is, and fire the security expert for being a dote.

Then offshore all your dev work because it is easier to say that these happen because of language barriers.

I feel like putting a unique id on a dom element using a data dash attribute is an anti-pattern but I guess I can't think of a way around it. Obv I know very little about back end and database management so I'm just making it up as I go along. This is just a learning tool for me as I've somehow gotten this far without really knowing much at all about databases other than "data comes from here durr".

Why is that an anti-pattern? Either way, you are sending some elements to the database on form submit. Whether or not those are put in by the user, or if that element is clickable or visible, is irrelevant.

Why are you allowing the same thing to show twice? Wouldn't the end-users generally prefer to edit what they already have?

You have to get some identifier for each element. A serial PK generated by the database is the easiest and best way in the situation you are describing.

????

There's been a million articles about how the dom shouldn't store state data. I agree with them. You should store state data outside of your presentation layer.

Something like a todo list should not disallow an entry from being duplicated. Therefore you cannot rely on that entry's name being unique and referenceable.

What is 4 question mark material in the above statements?

RE: The MySql hate

http://blog.scalac.io/2015/01/27/rou...ith-slick.html

Just not sure if I'm either misunderstanding or if I am totally wrong. Like, I don't know everything...

Maybe I'm confused, but when you generate your form elements, are you doing this?

instead of this?
Then pass resource id instead of resource name.

I'm not sure what you mean by state data. My first thinking is cookies, but I'm not sure if I'm understand this now.

Each option in an HTML select form element has a Name and and an ID. Can you use an HTML select and re-style it? If not I see no problem with creating some kind of similar structure.

But yeah something like Dave posted with hidden form elements with IDs indexed by number to correspond to the row would work.

Also this is one of those things where it feels like you're approaching it all wrong if your RESTful API can't handle either a) multiple items with the same name, but actually referenced by ID or b) a lookup/action based on name which could return/act-on more than one item.

or

Which would you rather write and reason.

Second one not even close. For us Jade keeps our HTML files much smaller, more readable and provides a level of validation as well.

If you go look at our old JSPs sometimes they are a gigantic horrible mess and are a gigantic mess to debug if you get stray or missing closing div tags.

resources have unique identitifiers.

in that example, you are confusing a todo item's title/name with the todo item's identity. but the name is an attribute of the todo item, most likely along with "is_completed" and whatever else is relevant in your app. it's analogous to people sharing names -- it works fine and they maintain separate identities.

separately from that issue, you'd want to decide for your particular app how you want to deal with todo items that have the same name: disallow it, allow it, allow it but instead of two separate items you have one item that has a "count" property that gets incremented, etc. this is pure domain problem, though, and no matter how you solve it you need the concepts of identity and attributes to be separate.

Don't get me started on YAML-style anything.

I'd most rather write something like this:

What kind of editors are people using that doesn't auto-close HTML tags, code brackets, or other balancing features?

And what kind of editor are people using that doesn't generate all this stuff with snippets and have features to auto-fill id and class names?

There are very few things that have cost me more debugging time than YAML. I'm surprised people would rather donk around trying to line up whitespace than use decent tools or write functions that aren't so pedantic, full of invisible errors.

I got started...

<? ?> is easier to type than < />

these php donks might have gotten something right

and jade is super annoying.

Yet it is more comfortable to type the jade version than that.
I like the look of what you wrote more but I wonder what designers prefer, when they don't come from a coding background. The spaces is really just hitting tab but i'm interested in both sides of the debate because if something is better, i'll tend to switch to what makes the most sense in the end.

I just can't get past the time I spent debugging YAML to ever think it was a good idea. You called me exacting, and even I think YAML is way overkill. I could think of a million better ways to generate HTML.

Regardless, I think we are beyond the world of static HTML now. Everything is dynamically generated, so it is up to the programmers to generate HTML.

I liked how it was done in Clojure, using hiccup. I haven't used it in a long time now, but my recollection:

I'd rather see something like this for a non-developer:

We can't stupify it to nothing at all. I just don't think using significant whitespace is a good idea, at least not to the nitty extreme of YAML. For example, if you have a trailing whitespace, or an extra space after a colon, then the whole system crashes over a misonfig.

Yet, somehow people who aren't using an editor without snippets is all of a sudden going to have an editor that doesn't mix tabs and spaces and can magically delete trailing whitespace?

I'm guessing Jade isn't that bad.

I don't know anyone who's used Jade for a while and wanted to go back to straight HTML templating.

Thanks this was helpful.

I've never felt the need to use an html templating engine. Biggest reason is that you'll be debugging in html anyways. Jade in particular doesn't seem to fit the JS/front end model especially in regards to whitespace. IDK I could be convinced but it seems like more abstraction for not a lot of benefit.

Could someone who knows express take a quick look at my todo list app(50 lines, no update yet)? Like I said I'm totally going by the seat of my pants here and would love some feedback but hey it works mostly. Usual front end ajax stuff. link

I think you might be thinking about this from the wrong perspective. This is a backend/data problem. Elements should have a unique id (primary key) and that's how you should identify and address them. You can map whatever display name you want but underneath it's one unique id per element.
So basically...your situation cannot happen if the database is used normally.

dave can correct the SQL if it's wrong :P

TODOS (frontend view):
Walk the dog
Wash the dishes
Learn Haskell
Walk the dog

TODOS (backend view):
44
45
46
47

Quick, everyone turn off your Javas!