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

131–140 of 551 posts

Re: HTML First

#131

Post by corethree »

pphysch wrote: post #126
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.

There won't be a repeat. WASM is a clearly better compilation target than JS, and browsers have greatly improved the "vanilla" DX. TypeScript ecosystem is the Enterprise Java of this decade, except it's built on shakier foundations, i.e. you can run some ancient JVM, but good luck relying on an ancient browser version & node dependencies. There will probably still be tons of job-security in the next couple decades, b…

Building a language and a framework on top of wasm is just another abstraction.

Ironically you mention the jvm which further proves the existence of the flat circle.

We've done it before... We will do it again.

Re: HTML First

#132

Post by anon23432343 »

I'm not a big fan of JSX...

But that trend to put everything back into HTML were possible is also wrong...

Yeah this may work for static websites with some forms but I don't see Discord being build like that or any other bigger app.

Its like people want back the HTML version of Gmail. Its a nice experience when a big part of your screen flashes /s

What about i18n? or a10y? The examples of the form don't support any of that.

Have fun writing the right input every time without a well abstracted text input that does the hard and annoying stuff for you.

We switched to components for a reason but it seams like people forgot.

And yes not every blog or form needs to be writen in nuxt or some other big framework.

Re: HTML First

#133

Post by [deleted] »

anon23432343 wrote: post #132

I'm not a big fan of JSX... But that trend to put everything back into HTML were possible is also wrong... Yeah this may work for static websites with some forms but I don't see Discord being build like that or any other bigger app. Its like people want back the HTML version of Gmail. Its a nice experience when a big part of your screen flashes /s What about i18n? or a10y? The examples of the form don't support any o…

[deleted]

Re: HTML First

#134

Post by corethree »

evantbyrne wrote: post #129
corethree wrote: post #92

Earlier quoted context omitted.

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.

Agree to disagree. Building a React frontend is extremely complicated compared to server rendering HTML with progressive enhancement. It introduces state management to the frontend for even the most basic tasks, which is not something most web applications benefit from. When I built my CI/CD platform (Beaker Studio), the React portion probably added a solid 50% extra time to the project and really did nothing for it…

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 ui construction.

The dom was a failure, react was a failure. What do you think going back to the DOM will do?

Re: HTML First

#135

Post by [deleted] »

tonyennis wrote: post #95

OP Here. This got more engagement than expected, some of the bits I've picked up in discussion: "Recommends skipping build step then mentions Tailwind": We use static-tailwind, a version with no build step, in development. "Recommends hyperscript, a new non-js syntax" - Agree this isn't perfect & would prefer something which uses js. Was going to use Alpine but also have found that to be quite brittle in production.…

[deleted]

Re: HTML First

#137

Post by codeptualize »

wheelerof4te wrote: post #121
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…

"I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives." Well, what are the objectives? If they are complex, so should the code be complex. That's the nature of our job. By adding an advanced framework you up the complexity by default. Instead of adding more code, you add more build dependencies. This is especially wasteful on websites. In…

In some sense I agree, I am very mindful of the dependencies I add and I am not afraid to write something custom if that better fits the situation.

But this article is not showing me how to do that and the things listed are not going to have an impact on the complexity of my projects as these basic things are solved quite well.

> By adding an advanced framework you up the complexity by default

If you know your project will remain simple then by all means. That's often not how it works though and then you end up writing a framework yourself once the scope gets increased and features are added.

Adding to that that using a framework gives you so many things for free. There are so many aspects to a good website and leaning on a group of people specialising in all those things is often a smart move with better outcomes.

I think the initial complexity might be a little bit higher, but there often is a big return on investment later on, and also immediately in terms of productivity.

I'm not going to stop you from not using a framework, I think it's great to experience it, have been there many times before, got burned (badly), and now make different decisions.

Re: HTML First

#138

Post by mock-possum »

anon23432343 wrote: post #132

I'm not a big fan of JSX... But that trend to put everything back into HTML were possible is also wrong... Yeah this may work for static websites with some forms but I don't see Discord being build like that or any other bigger app. Its like people want back the HTML version of Gmail. Its a nice experience when a big part of your screen flashes /s What about i18n? or a10y? The examples of the form don't support any o…

Also not a fan of JSX. VUE’s component definitions are slightly better - at least it’s using actually HRML tags and s. Personally, my favorite is Lit’s approach, writing HTML in tagged template literals. It’s still mixing your HTML with your JavaScript, but it feels much cleaner, closer to the vanilla experience of marking up content.

Re: HTML First

#139

Post by mock-possum »

jackblemming wrote: post #111
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…

[flagged]

> wow all of this is too complex and stupid

Not that they were necessarily wrong, I also tend to reach this conclusion on most big web projects I work on.

Re: HTML First

#140

Post by evantbyrne »

corethree wrote: post #134
evantbyrne wrote: post #129

Earlier quoted context omitted.

Agree to disagree. Building a React frontend is extremely complicated compared to server rendering HTML with progressive enhancement. It introduces state management to the frontend for even the most basic tasks, which is not something most web applications benefit from. When I built my CI/CD platform (Beaker Studio), the React portion probably added a solid 50% extra time to the project and really did nothing for it…

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.

Post reply on HN