Live data from Hacker News

15 years trying to make everyone separate HTML, JavaScript, CSS – and then

twitter.com

161–170 of 177 posts

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#161
post #11

Earlier quoted context omitted.

Agreed. Take the example of people hating XML and trying to reinvent everything good XML already had with JSON and JSON Schema. http://json-schema.org/

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…

> there's no concrete way to represent a piece of XML in code

unless you are using some lisp-2 dialect

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#162

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…

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 running program, as XML, but what's the point?

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#163
post #146

Reading the comments I'm wondering if I'm the only one who noticed that this example does NOT intermingle CSS. This is a view component that keeps track of it's own state. It is 100% encapsulated and by building in events and data bindings it can be composed into more complicated applications. It is in fact separation of concerns. This is only one concern. The UI of a single component. In a full React app the busines…

As an aside, is anyone else a a bit worried about is the massive use of destructuring assignment and rest operators and whatnot? I see it a more in React/Redux code than anywhere else. I really like how it can reduce a number of tasks to less code, but it's the most common thing that trips me up when I read React or 'ESNext' codebases. It feels like ternary operators on steroids, with all advantages and disadvantages…

It's a comfort thing, for sure. I've only started writing more with destructuring assignment recently (it's part of our code style guide at my new company), and it's doing things like forcing me not to use a different variable name for something that's already been defined. It's also forcing me to do more FP (since our stylguide also forces usage of `const`), which has actually made my code my more readable and maintainable (consistent naming, single-responsibility in functions, etc). Once you get used to the new syntax, it's a breeze to read and understand.

Well, once you understand a statement like this anyway:

`store => next => action => next(action);`

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#164
post #28

Earlier quoted context omitted.

Why react specifically? My general experience tells me that mixing presentation and logic ends badly, as well as the collective experience of the industry. We've been down this path with just about every GUI technology before but it seems we have to learn it again.

Why react specifically? My general experience tells me that mixing presentation and logic ends badly If you’re talking about the `todos` list in the tweeted example, I’m afraid you’ve been successfully trolled. In non-toy code, you’d typically hold the underlying state in a separate part of your system rather than the rendering React component, as with any other sanely designed UI. That data would be passed into the…

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 components that hold their own data? What is the way in react?

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#165

Earlier quoted context omitted.

Why react specifically? My general experience tells me that mixing presentation and logic ends badly If you’re talking about the `todos` list in the tweeted example, I’m afraid you’ve been successfully trolled. In non-toy code, you’d typically hold the underlying state in a separate part of your system rather than the rendering React component, as with any other sanely designed UI. That data would be passed into the…

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 greatest strengths, but you don't need any bells and whistles like Redux or Immutable or MobX or whatever other state management libraries you’ve come across.

One thing I would recommend right from the start is storing your application state somewhere outside your React components, even if it’s just in plain JavaScript objects. When you’re ready to render a DOM tree, pass that data into the top-level React component via props. Have that top-level component in turn pass any relevant part(s) of its input data to any child component(s) that need that data for their own rendering.

Likewise, I would recommend defining the functions to handle any interesting events outside your React components. You can then pass any callbacks you might need in via props on your components as well.

If you try that sort of design out a few times with non-trivial apps, you’ll soon start to see common patterns where introducing other tools might be helpful, and at that point you’ll have a better understanding of what some of those other libraries do and which combinations of related libraries might be useful for your particular needs.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#166
post #157

Earlier quoted context omitted.

>No attempt at dialogue To be fair, there has never been any effective dialogue on Twitter. 140 characters and out-of-context replies make it impossible.

Not true. I read through twitter arguments/debates multiple times a week.

And would you say the experience is pleasant? Is it a format that you would choose above all other formats? Rhetoric condensed to 140 characters and displayed in whatever order Twitter felt like showing it in?

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#167
I think he's oversimplifying by assuming separation of html, css, js is 'The way to go'. It's a way, not the way. Building views by composing functions is actually really interesting and should not be discarded that quickly. He would probably die if he looked how you build interfaces with OM.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#168
post #114

Earlier quoted context omitted.

This. I can't comprehend the very idea of "template languages". Especially in PHP, because PHP itself is a decent template language by design. But even outside - they always evolve the same. They start as a "lightweight" way to avoid putting code into view templates, but then they slowly accrue conditionals, loops, local variables, half-assed tools for defining functions, and before you know, your "no code allowed" t…

And after you replicated PHP you come to the conclusion the templating language is as slow as hell. So you think: maybe we would need a compiler so we can cache the templates. The question ofcourse is: why would people rather use: {for item in list} {item.name} {end for} instead of: ' . $item['name'] . ' '; } ?> And I think this goes deep. People are looking for more human ways to express themselves. And PHP is not a…

I've never understood why people use templating engines in PHP. I've been an on again off again user of PHP for atleast 7 years now, and I've never understood it for exactly the reasons you outlined.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#169

Earlier quoted context omitted.

What is 'build = (): string => {' ? Or specifically ():, I know arrow functions.

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){...}

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#170
post #146

Earlier quoted context omitted.

As an aside, is anyone else a a bit worried about is the massive use of destructuring assignment and rest operators and whatnot? I see it a more in React/Redux code than anywhere else. I really like how it can reduce a number of tasks to less code, but it's the most common thing that trips me up when I read React or 'ESNext' codebases. It feels like ternary operators on steroids, with all advantages and disadvantages…

It's a comfort thing, for sure. I've only started writing more with destructuring assignment recently (it's part of our code style guide at my new company), and it's doing things like forcing me not to use a different variable name for something that's already been defined. It's also forcing me to do more FP (since our stylguide also forces usage of `const`), which has actually made my code my more readable and maint…

That's good to know. It does feel like a powerful feature that's worth mastering.

I mean, despite the risk of making things complicated, I use ternary operators all over the place...

Post reply on HN