Live data from Hacker News

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

twitter.com

61–70 of 177 posts

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

#61
post #30

Earlier quoted context omitted.

> I guess that's what happens when you don't hire anyone over 30 It's comments like these while people don't hire anyone over 30. Rather than provide thoughtful critique of the platform the response is "This looks like something I saw 20 years ago and it didn't work then so it won't work now, I'm not even going to look at it!" Speaking as someone who is over 30... before you criticize something, understand it. For ex…

The critique is in the title. There are good reasons presentation and logic are separated.

And how often are the presentation and logic changed in isolation of each other... they aren't separate concerns at many levels. The concern is sepearated in React at a component level... how a component is rendered is just as important as how it raises/accepts changes outside of itself, and often interacts.

Also, having JSX in my JS is much easier to deal with than remembering some abstract DSL for how to iterate through children in a template language. It's no more goofy.

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

#62
post #36

Earlier quoted context omitted.

Bitter over 30 year-old? (I'm 43 btw so not trying to be ageist, just asking what seems like an obvious question) It does look similar but it is night and day different beyond the superficial appearance. Are you actually trying to say that the in-browser experience in web apps from 15 years ago were in the same ballpark as even simple single page javascript apps from today? That is laughable. So something must be dif…

> Bitter over 30 year-old? Yes I'm bitter that the same errors we made with desktop apps in the 90's (and possibly earlier) are being repeated. > Are you actually trying to say that the in-browser experience in web apps from 15 years ago were in the same ballpark as even simple single page javascript apps from today? Yes. The biggest difference is the amount of postbacks, the state handling has moved client side.

But are they really the same... a common prescription for state management with react is to use something like flux or redux. State management solutions that have worked out well for gaming platforms to this day. Not the MVC patterns that bring a lot of complexities that make cross cutting concerns that much more difficult.

This is emphatically NOT the same as the desktop apps in the 90's.

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

#63

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…

Tbh how is the one concern not the Fact they use 'let'. Gross.

Fun fact: types, line numbers, and BS keywords like 'let' 'var' and * *&uint32, are only constructs of the language authors mind... a visualization of how he thinks. And are completely optional to a language (given a slightly more flexible parsercompiler)

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

#64
post #2

It is amazing how much react resembles php and classic asp from 15 years ago. I guess that's what happens when you don't hire anyone over 30.

The same thing lures people in every time. You sit down, open a single file and type for 5 minutes and you've got a baby web app. Whee! The pain comes later. So much pain. Its like the payday loan of technical debt.

Where does the debt come in?

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

#65
post #11
post #2

It is amazing how much react resembles php and classic asp from 15 years ago. I guess that's what happens when you don't hire anyone over 30.

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 docs for an API is usually easier to reason with than any of the boatloads of cruft that came along with XML. Not to mention the much larger transmission size.

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

#66
post #60

Earlier quoted context omitted.

> shittiness of Tim Berners-Lee's overly-verbose and unmaintainable HyperText Markup Language A bit too strong. Imagine Markdown becomes wildly popular and the majority of the Internet's content is now available in Markdown. As more content becomes available, we expand Markdown to include forms to get bidirectional communication. There are some layouts and styles that can't be done in markdown, so we add stylesheets.…

We're all geniuses when we have 30 years of retrospect.

Only if you take the time to look back

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

#67
I've been using preact with tsx and inline styles. Every component Is a es6 module that declares it's imports and exports. I have a theme.ts containing my theme variables. There are watchable models. Only views contain tsx and css as js. Views import a controller and mediate events to them. Controllers know nothing about the view and they are the only ones that can modify the model.

My application contains a single index.html with entry point to my js bundle, empty body tag and no css.

Everything is loaded as needed, encapsulated as modules. The simplicity is just amazing .

The way I think about it is react like thinking offers me the most semantic compression in my code.

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

#68
post #2

It is amazing how much react resembles php and classic asp from 15 years ago. I guess that's what happens when you don't hire anyone over 30.

I started my career "professionally" with Cold Fusion 3 or 4 about 16ish years ago, and left it behind for PHP4, and so on, once I had to start paying for my own hosting.

I realized a couple months ago how incredibly similar JSX is to Cold Fusion - At least CF4. It's nearly identical in some respects.

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

#70

This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong . Separation of concerns refers to responsibilities, not languages. If you're building a static website, sure, you probably don't need R…

>This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong.

We didn't. And React doesn't change that either. React components are not logic code, they are UI code, and that has always went with view concerns (loop this times, show this button or that button depending on state, etc).

In the Desktop GUI space, where they don't have our HTML madness, do you think their UI components are not using code? Buttons, drop-downs, etc are not appearing by magic, they are created by code that does things like: draw a line of x length and y color, then another perpendicular to that, etc, then loop and draw some stripes, etc. That's the case even in Smalltalk, where MVC was invented. That still matches with "separation of concerns" -- which is about not mixing your BUSINESS logic with your UI code, not about not having code in your UI rendering.

In fact, compared to the classical way (foreach and other kinds of template instructions embedded in template strings, from PHP's Twig to Angular) it's even cleaner, because even though JSX looks like HTML it's actually compiled to Javascript instructions it's not just some ad-hoc language hidden in template tags to be interpreted at runtime.

And separation of concerns also applies to UI elements (encapsulation, re-use, etc) something which "logic free" templates like Mustache and so also miss (or, well, make harder -- of course if you try hard enough you can always fit a square peg in a round hole).

Post reply on HN