use the following search parameters to narrow your results:
e.g. subreddit:aww site:imgur.com dog
subreddit:aww site:imgur.com dog
詳しくは検索FAQを参照
高度な検索: 投稿者や、subredditで……
783 現在のここのユーザー
/r/programming is a reddit for discussion and news about computer programming
Guidelines
Please try to keep submissions on topic and of high quality.
Just because it has a computer in it doesn't make it programming.
Memes and image macros are not acceptable forms of content.
If there is no code in your link, it probably doesn't belong here.
App demos should include code and/or architecture discussion.
Please follow proper reddiquette.
Info
Do you have a question? Check out /r/learnprogramming, /r/cscareerquestions, or stackoverflow.
Do you have something funny to share with fellow programmers? Please take it to /r/ProgrammerHumor/.
For posting job listings, please visit /r/forhire or /r/jobbit.
Check out our faq. It could use some updating.
If you're an all-star hacker (or even just beginning), why not join the discussion at /r/redditdev and steal our reddit code!
Related reddits
/r/technology
/r/learnprogramming
/r/coding
/r/compsci
/r/dailyprogrammer
/r/netsec
/r/webdev
/r/web_design
/r/gamedev
/r/cscareerquestions
/r/reverseengineering
/r/startups
/r/techsupport
Specific languages
You have ruined HTML (blog.dantup.com)
dannytuppeny が 3 日 前 投稿
残りのコメントをみる →
[–]bkv 44 ポイント45 ポイント46 ポイント 3 日 前 (32子コメント)
You either have expressions in your markup, or markup in your code. I'll take the former as it's a far better separation of concerns. If your expressions become too complicated, it's an indication that the logic needs into its own method in the controller, and then your complex expression becomes a simple method call.
stop trying to crowbar non-standard binding expressions into it.
What's non-standard about putting arbitrary expressions into data-* attribute? HTML5 introduced data attributes specifically for this kind of extensibility.
[–]serpent 10 ポイント11 ポイント12 ポイント 3 日 前 (31子コメント)
You either have expressions in your markup, or markup in your code.
False dichotomy. You can have logic that generates a data structure, and a simple translation from that data structure to markup, separating concerns even better than putting expressions in your markup.
[–]sphinx80 26 ポイント27 ポイント28 ポイント 3 日 前 (8子コメント)
A.K.A markup in your code.
[–]danredux 0 ポイント1 ポイント2 ポイント 3 日 前 (3子コメント)
But full separation of concerns. HTML for pre-generated content, a JS middle-man for converting data to dynamically generated HTML, and JS for logic. That's 3 clear sections, each with their own space. IMO, this beats mixing dynamic and static HTML together.
[–]Rezistik 2 ポイント3 ポイント4 ポイント 3 日 前 (2子コメント)
Isn't that what these templating libraries do? Create a JS middleman for the dynamic and static html?
[–]danredux 1 ポイント2 ポイント3 ポイント 2 日 前 (1子コメント)
Yes, a middleman that forces you to mix your static and dynamic HTML. It would be better if they remained separate.
[–]Rezistik -1 ポイント0 ポイント1 ポイント 2 日 前 (0子コメント)
Are we talking about working with documents, or programs? Because when working with programs I think Angular/Ember MVVM system works amazingly.
I guess my question is, what is your alternative?
We have the templating system used by Angular/Ember/Backbone, the progmatic approach seen in ReactJS, then plain old JS or jQuery spaghetti.
Or are you looking for something more similar to programming GUI's for native clients?
Because looking into that...the options seem far far worse. I've only ever done Web Dev so I haven't used any native GUI toolkits but a quick look for the most popular isn't promising.
qT and ruby Shoes for instance both mix the appearance and the logic significantly more.
[–]serpent 0 ポイント1 ポイント2 ポイント 1 日 前 (0子コメント)
Nope, not at all.
[–]makis 0 ポイント1 ポイント2 ポイント 3 日 前 (2子コメント)
nope. a representation of your markup, or better, a tree representing the data you want to render when you have a data structure and a renderer that can understand it, you can easily generate HTML5, HTML4, XHTML, XML, Haml, Json, PDF, binary, whatever you want
[–]zoomzoom83 1 ポイント2 ポイント3 ポイント 3 日 前 (1子コメント)
a tree representing the data you want to render
So.... a view-model then?
[–]makis 0 ポイント1 ポイント2 ポイント 2 日 前* (0子コメント)
I'm gonna say something incredible, but you can do it without views and models model is not data, is that area of the MVC graph that deals with data. views are only one of the many way of rendering data.
EDIT: I expand a little bit: when we have a language independent representation of the data, we don't need to embed HTML in the rendering code. We can generate it through code, using the DOM API, or we could use of the many languages that compile down to javascript, and build a beautiful DSL to actually just translate the data into code that generates HTML. Looks better to me than abusing of html attributes.
[+]bkv スコアが基準値未満のコメント-7 ポイント-6 ポイント-5 ポイント 3 日 前 (21子コメント)
Anything can be a false dichotomy if we're going to introduce wacky, unrealistic middle-grounds. Front-end folks work in HTML and CSS, programmers work in code. Adding a layer of indirection will not make anyone's life easier.
[–]drysart 7 ポイント8 ポイント9 ポイント 3 日 前 (19子コメント)
Embedding your HTML in your Javascript, as you do with the author's suggested pet framework React, isn't going to make your front-end folks' life any either, either.
If you set up good view models so that you don't need to have expressions in the markup, the data binding friction on the front-end side can at least be minimal; especially when someone is suggesting with a straight face that it's a better alternative is to be asking your designers to pull open JS files and edit the render method of a class rather than make use of their tools for creating HTML.
[–]bkv 2 ポイント3 ポイント4 ポイント 3 日 前 (4子コメント)
If you set up good view models so that you don't need to have expressions in the markup, the data binding friction on the front-end side can at least be minimal
How do you generate markup without any kind of expression? We have the "old" templatating way (razor, for example):
@foreach(var person in model.People){ <li>@person.Name</li> }
or you have something like angular, where the markup is 100% valid HTML5:
<li data-ng-repeat="person in people">{{person.name}}</li>
I'm not sure what the view model has to do with anything in the context of this discussion. We're talking about the means with which we're injecting/binding data within a template. Where that data comes from is irrelevant.
[–]drysart 1 ポイント2 ポイント3 ポイント 3 日 前 (3子コメント)
Part of the article is dogging on the idea of having 'complicated messes' of code logic in the HTML. That's exactly what the view model is supposed to be preventing. If you create your view model correctly, the strongest argument the author presented against data binding ("Simple tags are never simple") is completely moot.
[+]dannytuppeny[S] スコアが基準値未満のコメント-8 ポイント-7 ポイント-6 ポイント 3 日 前 (1子コメント)
If it was moot, that would make it not the strongest argument ;)
Tooling support is my biggest issue; no breakpoints, poor errors, inability to know it's correct until runtime.
[–]Valchris -1 ポイント0 ポイント1 ポイント 3 日 前 (0子コメント)
You can breakpoint JavaScript just fine, the errors are more then informative if they are actually JS errors. If they aren't JS errors it's trivial to find out why a string displayed nothing in a framework like angular and is most certainly a dev error, not a framework issue. It sounds like you need to take a class, read a book or stop writing web apps.
[–]dannytuppeny[S] -5 ポイント-4 ポイント-3 ポイント 3 日 前 (13子コメント)
How many real world web applications views are being built be designers/non-coders? Are your non-coders going to understand {{ this junk }}? Are they going to be able to debug when their content disappears?
[–]drysart 14 ポイント15 ポイント16 ポイント 3 日 前 (7子コメント)
You seem to be under the mistaken impression that your developers and your designers are the same people. That's simply not true for many websites, especially public-facing websites.
Your designers don't have to understand what {{this junk}} means, nor do they have to debug it. That's the developer's job. The designers simply take the magic words the developers give them and insert them into their designs where they want pieces of data to appear. If you've been following good MVC/MVVM design, you'll have plenty of mock data models they can view their designs against that cover all your bases (because you do unit test, right?).
[+]dannytuppeny[S] スコアが基準値未満のコメント-10 ポイント-9 ポイント-8 ポイント 3 日 前 (6子コメント)
No, I don't at all. But I'm yet to see any real web apps where non-coders are building views. It sounds great in theory, but I just don't believe it happens anywhere near as much as developers building them.
[–]cryonine 1 ポイント2 ポイント3 ポイント 3 日 前 (0子コメント)
My current job and the last two before that were literally this. It's surprisingly common, especially when you start scaling up to larger teams and/or work with agencies.
[–]jayfehr 0 ポイント1 ポイント2 ポイント 3 日 前 (4子コメント)
You just posted a huge rant about coding best practices and then admit that you don't do any testing. Wow, what a way to lose all credibility. Maybe stop leaning on your dev tools so much and actually develop a good development methodology that will work regardless of which tools you choose to develop with.
[–]dannytuppeny[S] -3 ポイント-2 ポイント-1 ポイント 3 日 前 (3子コメント)
You just posted a huge rant about coding best practices and then admit that you don't do any testing.
Uh, sorry, I must've missed the bit where I admitted I didn't do any testing?
[–]jayfehr 1 ポイント2 ポイント3 ポイント 2 日 前 (2子コメント)
you do unit test, right? No, I don't at all
you do unit test, right?
No, I don't at all
[–]bkv 3 ポイント4 ポイント5 ポイント 3 日 前 (4子コメント)
How many real world web applications views are being built be designers/non-coders?
Are you joking?
[+]dannytuppeny[S] スコアが基準値未満のコメント-7 ポイント-6 ポイント-5 ポイント 3 日 前 (3子コメント)
Well if Facebook and Instagram have gone down the React route; clearly their views are being done by coders. They're pretty big real world web apps, no?
[–]bkv 1 ポイント2 ポイント3 ポイント 3 日 前 (2子コメント)
While Facebook and Instagram most certainly have UX folks designing their front-end, even if it weren't the case, two websites represent a very small fraction of all real world web applications.
They're the only ones I can say for sure must have coders doing views. Using HTML binding expressions (eg Google with Angular) doesn't mean the inverse.
I have no idea what the numbers are, but I suspect far more companies have coders doing the HTML than not.
[–]zoomzoom83 0 ポイント1 ポイント2 ポイント 3 日 前 (0子コメント)
I'm pretty sure React has JSX for specifically that reason (Non-coders writing views).
[–]huyvanbin 1 ポイント2 ポイント3 ポイント 3 日 前 (0子コメント)
Everything is either a false dichotomy or it isn't ;)
必要なのはユーザ名とパスワードだけ
for more information, see our privacy policy.
アカウントを作る
ソンナニカンタン? チョットタメシテミナイ?
アカウントがあるなら後はログインするだけ
ログイン
π Rendered by PID 3451 on app-22 at 2014-08-29 17:15:23.109666+00:00 running 86bd09d country code: JP.
残りのコメントをみる →
[–]bkv 44 ポイント45 ポイント46 ポイント (32子コメント)
[–]serpent 10 ポイント11 ポイント12 ポイント (31子コメント)
[–]sphinx80 26 ポイント27 ポイント28 ポイント (8子コメント)
[–]danredux 0 ポイント1 ポイント2 ポイント (3子コメント)
[–]Rezistik 2 ポイント3 ポイント4 ポイント (2子コメント)
[–]danredux 1 ポイント2 ポイント3 ポイント (1子コメント)
[–]Rezistik -1 ポイント0 ポイント1 ポイント (0子コメント)
[–]serpent 0 ポイント1 ポイント2 ポイント (0子コメント)
[–]makis 0 ポイント1 ポイント2 ポイント (2子コメント)
[–]zoomzoom83 1 ポイント2 ポイント3 ポイント (1子コメント)
[–]makis 0 ポイント1 ポイント2 ポイント (0子コメント)
[+]bkv スコアが基準値未満のコメント-7 ポイント-6 ポイント-5 ポイント (21子コメント)
[–]drysart 7 ポイント8 ポイント9 ポイント (19子コメント)
[–]bkv 2 ポイント3 ポイント4 ポイント (4子コメント)
[–]drysart 1 ポイント2 ポイント3 ポイント (3子コメント)
[+]dannytuppeny[S] スコアが基準値未満のコメント-8 ポイント-7 ポイント-6 ポイント (1子コメント)
[–]Valchris -1 ポイント0 ポイント1 ポイント (0子コメント)
[–]dannytuppeny[S] -5 ポイント-4 ポイント-3 ポイント (13子コメント)
[–]drysart 14 ポイント15 ポイント16 ポイント (7子コメント)
[+]dannytuppeny[S] スコアが基準値未満のコメント-10 ポイント-9 ポイント-8 ポイント (6子コメント)
[–]cryonine 1 ポイント2 ポイント3 ポイント (0子コメント)
[–]jayfehr 0 ポイント1 ポイント2 ポイント (4子コメント)
[–]dannytuppeny[S] -3 ポイント-2 ポイント-1 ポイント (3子コメント)
[–]jayfehr 1 ポイント2 ポイント3 ポイント (2子コメント)
[–]bkv 3 ポイント4 ポイント5 ポイント (4子コメント)
[+]dannytuppeny[S] スコアが基準値未満のコメント-7 ポイント-6 ポイント-5 ポイント (3子コメント)
[–]bkv 1 ポイント2 ポイント3 ポイント (2子コメント)
[+]dannytuppeny[S] スコアが基準値未満のコメント-8 ポイント-7 ポイント-6 ポイント (1子コメント)
[–]zoomzoom83 0 ポイント1 ポイント2 ポイント (0子コメント)
[–]huyvanbin 1 ポイント2 ポイント3 ポイント (0子コメント)