For me, old school programmer, we are almost back from where we started. Keep it simple and keep yous shit seperated. You dont really need oops, you dont really need react. Dont pretend you have 15M visitors on a page and it has to be optimized for that.
15 years trying to make everyone separate HTML, JavaScript, CSS – and then
91–100 of 177 posts
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#92It 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.
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…
The problem is that while true web apps experience might have improved, the web as the whole degraded a lot since everyone is treating everyting as the app, whn in reality majority should be just a static content sites. Now you download 4MB of crap just to see 2KB of text.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#93Separation of concern or technology? A well structured React application is much easier to understand than something where you need to keep 3 files in your mind at once.
It used to be a separation of conterns. HTML for structure, CSS for presentation, JS for some bells and whistles.
Now, when everyone forgot what the web was about and see it just and app platform that does not really apply.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#94Separation of concerns == totally valid
However, "Separation of concerns" doesn't always mean the separation of programming languages. Its completely reasonable to have one file that concerns itself with one thing, yet is comprised of different languages.
Bash programmers know this to be true.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#95Earlier 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.
This has been going on forever. 3-tier client-server code bases had problems separating "presentation logic" and "business logic" because often they're very very closely connected.
React runs on the client. It runs the logic needed on the client. And there has always been some logic required on the client, otherwise you end up refreshing the screen for every.single.validation. which is a total PITA.
Given that there's some logic running on the client, then maybe running more of it there would be a good thing. This is the principle behind SPA's after all, and they've turned out to be a Good Thing generally. Not suitable for every use case, mind. So do we then need a separate Logic Layer for logic that isn't to do with Presentation? Where do we draw that line given that the whole thing is running on the client? How do we keep the thing clean and stop bits of logic being run on random button events?
React makes perfect sense when you look at it as an answer to the problem of "how do I add logic to my presentation layer and not end up in a mess of spaghetti code?"
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#96React is popular because of Facebook just like Angular was popular because of Google. Both are bad ideas. Why programmers insist on running off a cliff every few years like a bunch of lemmings, I don't know.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#97The thing about Fuchs is that he's a very smart guy, who is deeply embedded in the modern JS world, and is absolutely aware of what that code is doing, why it looks the way it does, why the trend in frameworks has moved the way it has, just how many times the argument he's using has been advanced already, and how thoroughly it's been trashed over the years. He knows that what he's said has been said a thousand times…
how thoroughly it's been trashed over the years
So often a phrase like this is repeated on HN.
React only got released 3 years ago. How could it be "trashed over the years"? Over what years? It barely qualifies for the plural.
I seriously wonder sometimes if javascript programmers live in dog years.
React apps haven't been in production long, we're only just entering the maintenance phase, now is exactly when we will start seeing the problems with mingling code + UI as the code gets forgotten, opened again, modified, added to and bloats.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#98React is popular because of Facebook just like Angular was popular because of Google. Both are bad ideas. Why programmers insist on running off a cliff every few years like a bunch of lemmings, I don't know.
Why do you think they are bad ideas?
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#99The thing about Fuchs is that he's a very smart guy, who is deeply embedded in the modern JS world, and is absolutely aware of what that code is doing, why it looks the way it does, why the trend in frameworks has moved the way it has, just how many times the argument he's using has been advanced already, and how thoroughly it's been trashed over the years. He knows that what he's said has been said a thousand times…
how thoroughly it's been trashed over the years So often a phrase like this is repeated on HN. React only got released 3 years ago . How could it be "trashed over the years"? Over what years? It barely qualifies for the plural. I seriously wonder sometimes if javascript programmers live in dog years. React apps haven't been in production long, we're only just entering the maintenance phase, now is exactly when we wil…
How many years do you need to come up with a counter-argument, or adress the issues claimed for the alternatives (by the React authors and community)? Three years might not be old for a technology, but it seems like a lot of time to actually respond and flesh out this argument. If that really was the author's interest.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#100Earlier quoted context omitted.
Curious on your take; for a component, why do I need the virtual dom diffing? If I'm working on a component level, it's already granular enough where I can easily understand the changes that need to be made and I can just update those DOM elements myself (e.g. Oh, I should add this class here and update my shopping cart total). The DOM diffing for small components seems so... heavy handed. "Don't worry React, I got t…
ReactJS is currently the fastest, most scalable frontend solution available so compared to all that has come before it, it can seem heavy handed. But if you want to build highly scalable apps like Facebook, Instagram, Pinterest, Reddit and Twitter mobile, then losing easy speed gains with every one of the hundreds to thousands of components you build is unacceptable.
The problem is that 99.99% of developers aren't (writing Twitter etc) but they still apply techniques used by unicorns to handle their own very exceptional needs.
We should always be wary of applying skyscraper building techniques when building a house or a shed.
I honestly bet that 99.99% of people who read Hacker News could write their applications with a drop of jQuery and some basic ES6 code.
I have nothing bad to say about these frameworks, more caution that we don't apply techniques needed at scale to small scale products.