Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML First

html-first.com

Post reply on HN
Print view View original

141–150 of 551 posts

Re: HTML First

#141

Post by zelda-mazzy »

In theory these principles are really good concepts from an education standpoint. Where I teach, we teach students vanilla javascript and HTML as much as possible before moving on to frameworks that make things easier.

Some of these points I'm a bit confused on... is the point behind "Where possible, maintain the right-click-view-source affordance" supposed to be to make the learning barrier lower? While I understand the sentiment behind this, tools like React or Angular have significantly lowered the barrier to entry in their own ways.

Re: HTML First

#142

Post by corethree »

cphoover wrote: post #128
corethree wrote: post #94

Earlier quoted context omitted.

React was designed as an abstraction layer on top of the source. Why? Because the source was too complex. Now we want to expose the source and get rid of the abstraction... Why? Because the abstraction is too complex. Recurse and repeat.

Yes, I remember when Microsoft FrontPage was the go to wysiwyg editor for web development along with Dreamweaver most styles were added inline. At some point wysiwyg editors fell out of favor as they generated both unmaintainable styles and markup. Style sheets took hold and the insanity that was inline styles were dropped in favor of external style sheets. Today we have tailwinds.css and inline styles are coming bac…

There's no theory behind program design and organization. We have no formal definition about whether one design is better than the other.

Thus, History is doomed to repeat itself as software technology moves horizontally forever, with practitioners never knowing if the current abstraction was better than the previous one.

Re: HTML First

#143

Post by mock-possum »

1shooner wrote: post #45
ricardobeat wrote: post #2

“Locality of behaviour” is such a poorly defined rule. It’s just an invented name for going against separation of concerns. Calling CSS “spooky action at a distance” is a massive stretch too. Good principles here but the arguments are quite weak and could be much simpler.

Tailwind is a build step with just as much 'spooky action at a distance'. If it wasn't, we'd just use inline CSS. With Tailwind you're trusting a 3rd party library to abstract the CSS spec for you, and for that abstracted quasi-spec to be followed by your build configuration.

It’s hard for me not to see Tailwind as using the class attribute to reproduce the style attribute - burying your html tags under a pile of css classes doesn’t feel that much different than defining those styles inline.

Re: HTML First

#144

Post by max_ »

zelda-mazzy wrote: post #141

In theory these principles are really good concepts from an education standpoint. Where I teach, we teach students vanilla javascript and HTML as much as possible before moving on to frameworks that make things easier. Some of these points I'm a bit confused on... is the point behind "Where possible, maintain the right-click-view-source affordance" supposed to be to make the learning barrier lower? While I understand…

Have you used HTMX?

I am yet to find a reason for using frameworks like React instead of HTMX.

Re: HTML First

#145

Post by tabacitu »

codeptualize wrote: post #89

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I…

Why? Why does it need to be good for big projects in order to be good practice?

I’m genuinely asking. I never understood this argument that people bring.

In my view, the web is 95% small to medium projects. Most technologies should be focused on that - simple solutions for simple projectS. Add complexity later.

Re: HTML First

#146

Post by corethree »

evantbyrne wrote: post #140
corethree wrote: post #134

Earlier quoted context omitted.

No you agree. You're just not understanding. The purpose of react was to simplify the complexities of front end web development. Just like the purpose of the DOM was to do the same thing. Now this article is pointing to going back to the DOM for a similar purpose. The cycle on the great circle of life occurs because we are repeatedly attempting and failing to fulfill the singular purpose of building a clean API for u…

> The dom was a failure, react was a failure. What do you think going back to the DOM will do? It'll give me that extra 50% effort back. Although I've used React for years, I have never been on the bandwagon. Having built many React SPAs with different teams at this point I'm confident it has always been a step backwards.

Yeah but react was designed to address a problem. I don't know if you recall but people were complaining a lot back then. There were tons of frameworks attempting to solve the issue. Only react came out in top.

By stepping back we are just going back to the same problem.

The next abstraction will attempt to solve the same problem again. Very likely in a similar way react failed, the next abstraction will introduce new issues and there will be another trend to go backwards again.

Re: HTML First

#147

Post by infamia »

corethree wrote: post #92
robinhood wrote: post #21

Earlier quoted context omitted.

No, it was designed to address problems that were not solvable by the then-current state of simple technologies.

All the things React does is doable with plain javascript. There aren't any extra features added. React was designed to address complexities. It is an abstraction. Now we want to go backwards. Getting rid of the abstraction to get rid of complexities. But getting rid of complexities was the whole point of react.

I think this is because HTML, CSS, vanilla JS, browser DOM implementations, and networks have all gotten better. Whereas the complexity/churn around JS tooling (and to a lesser extent React) has grown. Additionally, the overuse and abuse of React, to the point people are making largely static sites with React, which is largely a total waste of time. This has caused people to take a second look at their options, which should be viewed as totally natural.

I don't think of it as "going backwards", so much as reassessing and questioning the tools we are using and using the best one at hand. I don't know of anyone who suggests using hypermedia for all applications, just use it where appropriate and use React when simpler technology falls short.

Re: HTML First

#148

Post by alfonsodev »

The main feature that introduces the need of a build step is having a template engine in order to reuse blocks of code, like footer, header, menu, etc..

I think Dreamweaver MX introduced something like template files, and it would make a "build" step that would copy the files from template to actual html files. Then it started to get complex, with data sources and generating pages in the backend. (php, asp, cold fusion?)

Re: HTML First

#149

Post by hinkley »

codeptualize wrote: post #89

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I…

We have forgotten the old lessons. Backend first was a defense mechanism against people who believe their eyes and not the experts.

When you make a product that looks like it works but doesn’t, they don’t understand. They put you on a path to overpromise and underdeliver.

One of the lesser known features of unit tests are that they give the code that management can’t see more QA prior to being wired up. They narrow that awkward window from first paint to shipping.

Re: HTML First

#150

Post by danielovichdk »

m-a-r-c-e-l wrote: post #30

I love the idea! In my current company we started with HTML and embedded JavaScript at the bottom and Styles at the top. Everything in one file, very easy to find and understand. It was "a little bit" slower. Pagespeed Insights didn't like it. Now we are "modern" with CSS and JS in a build process. And nobody knows which file to look at... My new Projects will start with HTML first, again. My credibility: 45 years, c…

Well. This was how we did web development before it turned into so many abstractions that most comments either is too young to know or simply not understanding that adding more abstraction is not ideal.

People here say "show me this on a big project" well how about they showed us how the thing they are doing on a big project has turned out.

The cleanliness of HTML and CSS is astonishing. That's a quality mark in my view. If you to move away from that you miss out on certain aspects imo.

Post reply on HN