171–177 of 177 posts
Earlier quoted context omitted.
Looks like build is the function and it returns a string. I think without the typing it would just be build = () => {
var build = function(){...} //return a string Rather than some other commenters, and I would have thought given arrow functions; var build = function(string){...}
Earlier quoted context omitted.
Note than in PHP you can also rewrite it as: Or with shortened PHP tags and alternative control structure syntax: Which at this point just differs in delimiters ( instead of { and }) from the template language. I don't have an opinion on this "more human way" to express oneself, but it seems that it would connect this case with the reason people seem to prefer curly braces to parenthesis in code too.
And then, to avoid XSS, you'd need to replace that by: Which is, IMO, the main problem with using PHP (or any other from of plain string concatenation) as a templating language. Escaping everything (and security in general) should be the default, not something that you have to opt into at every turn.
Earlier quoted context omitted.
My biggest peeve with XML is there's no concrete way to represent a piece of XML in code, it's in my opinion TOO flexible. You can express something as an attribute, a child, multiple children of the same element, a value of a child, etc. It doesn't translate cleanly to any kind of object structure in terms of code. And it goes in reverse too. Now, there are standards like SOAP, etc... In the end, JSON and some clear…
> It doesn't translate cleanly to any kind of object structure in terms of code. XML translates great to an object tree in many object oriented language. Hello new foo(new yo(), "hello", bar = 1) Which is why it's so great to describe documents and static UIs. I agree though that it's not a great choice for a REST API.
1
Hello
Earlier quoted context omitted.
Your point here is one of my biggest struggles in trying to adopt react. I have looked at many of the toy examples and haven't seen a clean implementation of a non-toy. I've built a couple small things with it and haven't seen a clear path to how I'd implement something in my day job that I currently do in a Backbone app. I don't really feel like I need something like redux, so what am I to do? Continue building comp…
Those are all fair questions. If you want to experiment, my advice would be to start by just using React as a template-rendering system that lets you conveniently build larger and more complex components by composing smaller and simpler ones and that can automatically change whatever is already in your DOM to whatever new DOM content you come up with when rerendering. At this stage, you can take advantage of React’s…
Earlier quoted context omitted.
Why do you think they are bad ideas?
IMHO Angular is a bad idea because you're doing rendering in the client side. Maybe your building an HTML5 image editor or something that requires client rendering. But most CRUD apps doesn't really need client side rendering. There is also a hype of SPA (single page apps) which is usually harder to implement than server-rendered apps. It is harder because you have to avoid the browser refreshing the page and keeping…
The browser does the rendering anyway. Or do you mean assembling the HTML to be rendered?
Single Page Apps are very good. GMail is possible because you don't have to reload the whole page and the images every time you click.
It's the "autocomplete" on steroids turned to 11. And it's much easier to implement, because you have state on the client side, and you can implement a simple REST API, which is much easier than maintaining sessions on the backend and implementing a thousand /?q= endpoints. (And can be consumed easily by other clients.)
And these frontend frameworks solve the "browser refreshing" thing for you.
Introducing changes to Angular 1 apps was a bit hard, yes. But compared to the previous jQuery hell, I think the structure that the evil Angular cult forced on people was worth it. And TypeScript and ES6 modules are finally making those things pleasant.
Earlier quoted context omitted.
That's because originally SGML/HTML/XML attributes were for (mostly) presentational details, but this role was shifted to CSS. The resulting combination does indeed look arbitrary, especially with CSS's total lack of mental discipline (but let's not be too harsh here). In judging whether something should be represented as element text or as attribute, ask yourself whether that something is content or metadata . In a…
Looking at the other comments, I realize you're looking for object/XML mapping. My opinion is that this is pointless (and I'm guilty of applying it back in the SOAP days, too), because objects are co-inductive data structures based on the types of programming languages, whereas XML is based on grammars eg. a description of a class of sequences of content tokens. Sure you can represent objects, ie. a memory dump of a…
Earlier quoted context omitted.
> It doesn't translate cleanly to any kind of object structure in terms of code. XML translates great to an object tree in many object oriented language. Hello new foo(new yo(), "hello", bar = 1) Which is why it's so great to describe documents and static UIs. I agree though that it's not a great choice for a REST API.
But that's not concrete without another definition in place 1 Hello Could represent the same object structure, for example. JSON is a pretty clean mapping to objects/properties/arrays, with less chance of confusion, or alternate interpretations.
Whether something is inside an element or is a property of said element has important semantical meaning. But not just that, with XML you can implicitly represent ordering, whitespace and type information with much less boilerplate.
So the argument for JSON is basically boils down to: "Javascript has horrible type support and doesn't support OOP. JSON models that experience better."