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

511–520 of 551 posts

Re: HTML First

#511

Post by David-Guillot »

robertoandred wrote: post #291
David-Guillot wrote: post #229

Earlier quoted context omitted.

Cost. React will require you to hire a React dev to handle all the complexity. htmx will be mastered by your "back-end" devs (who actually are web devs) in less than a week.

What kind of web dev can't handle React? Meanwhile, htmx uses clunky, non-standard attributes that rely on logic and templates that are split up in a million different places. Plus it requires a context switch to do anything client side.

I know so-called "senior frontend engineers" whose speciality is React, and who can't handle React. So all others...

This thing (and others like Vue, let me be clear) adds many layers of complexity over the web platform (client-side routing, data fetching, state management, rendering, etc.) and many third-party JS libs that you have to constantly update. You just can't say that it's standard/base web development.

Re: HTML First

#513

Post by RunSet »

xgb84j wrote: post #160
tabacitu wrote: post #145

Earlier quoted context omitted.

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.

Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects. Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all. I personally…

> If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all.

> I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks.

I wonder whether they ever pay off. First, I don't believe the frameworks you mention really, as you suggest, enable the last 5% of functionality that would otherwise be impossible. No, those frameworks are written in the same language they work in, which means that strictly speaking they do not enable any new functionality.

Second, whatever ease / speed of development you use must be weighed against the additional cost borne by the project's users. The time you save (that you might otherwise spend learning to achieve the same result without the framework) could be less than the time spent collectively by users waiting for the framework to load.

Re: HTML First

#514

Post by evantbyrne »

corethree wrote: post #451
evantbyrne wrote: post #420

Earlier quoted context omitted.

I dunno man, I don't consider browser APIs to be a failure. In fact, it's probably the most popular UI toolkit in existence by a wide margin. It being a collection of evolving standards doesn't count against it in my book.

Many bad things are popular. Java, C++, JavaScript. Popularity doesn't preclude something from being shit. The front end UI isn't a collection of evolving standards. It's the same standard with more and more cruft added on top. HTML wasn't designed for what we are doing with it now. Each additional layer... css, JavaScript, the dom, typescript, react, is a new layer over an old thing. It's like never buying a new car…

There's a difference between being popular, and being the most popular thing in a category ever and keeping that title for decades with no serious challengers. The browser as we know it with the DOM is the latter. Maybe that will change with new APIs that hook into the canvas, but we're still a ways off from that and I suspect the DOM will remain in the picture even then.

Re: HTML First

#515

Post by RunSet »

wheresmycraisin wrote: post #323
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…

> 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. Not everything has be a Large Enterprise Application.

Perhaps, but can you name even one successful, big, bloated institutional project that operates primarily on the principles of HTML First?

Re: HTML First

#517

Post by [deleted] »

ssss11 wrote: post #265
c-fe wrote: post #246

Earlier quoted context omitted.

Quick thought regarding date pickers, specifically: > Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.) Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1…

Yes but companies don’t think that way. Companies have a style that they want to apply to their product regardless of which browser renders it.

[deleted]

Re: HTML First

#518

Post by assimpleaspossi »

Izkata wrote: post #432
zlg_codes wrote: post #292

Earlier quoted context omitted.

I'm adding context to this because you're only telling part of the story: self-closing tags are necessary for void elements in XML and XHTML, both technologies that are still supported on the Web. Since XHTML processes HTML as XML, it forces it to be well-formed. Unlike HTML, which has all sorts of tag-soup and quirks modes and other things, because it's lax in its syntax. Void elements lacking the need for a closing…

> Void elements lacking the need for a closing tag or closing slash is one of the weird edge cases in HTML. While it's not in the HTML spec It's explicitly in the HTML5 spec as allowed, but not required.

They are allowed due to the big push for XHTML in the past and making them invalid might cause problems for a ton of sites built that way.

However, the slash carries no meaning. It does nothing. And browsers are instructed to ignore it. If anything, it can only cause problems: https://github.com/validator/validator/wiki/Markup-%C2%BB-Vo...

Re: HTML First

#519

Post by nvm0n2 »

docmars wrote: post #402
zztop44 wrote: post #284

Earlier quoted context omitted.

But very often it is software development. And there isn’t always some bright line between them. Like it or not, the web is an excellent platform for delivering software applications to users, especially one-off or infrequently used applications. Let’s use software development tools, rather than web publishing tools, to develop that software.

It's worth mentioning that the friction to deploy a web app is nearly zero these days, depending on how complex it is. As an example, shipping a macOS or iOS app, via official means, requires a lengthy review & approval process, upfront costs, buy-in into native languages with little to no use outside of these platforms, a limited selection of tools, and hard decisions about which version of the OS to support based o…

Shipping a macOS app doesn't require view of any kind, beyond notarization, which is just an automated malware scan and takes only a few seconds.

Re: HTML First

#520

Post by David-Guillot »

mostlylurks wrote: post #258
David-Guillot wrote: post #229

Earlier quoted context omitted.

Cost. React will require you to hire a React dev to handle all the complexity. htmx will be mastered by your "back-end" devs (who actually are web devs) in less than a week.

React is so simple to use that you definitely don't need to hire a "react dev" to "handle all the complexity". Like >95% of the effort is just understanding the basics of standard front end technologies (HTML, JS, and CSS), something that "back-end" devs (especially ones that label themselves as such) are by no means guaranteed to understand, which is an issue, since you'll have to understand these things even when w…

My feeling as an old-time "web developer" who has been bullied into becoming a "back-end dev" is: thank you, I think I know quite well the basics of standard front-end technologies, but suddenly some people started yelling at me "you're a grandpa, now you can't send HTML from the server anymore, it's lame, you have to send to the browser a JS app that will manipulate the DOM live instead". This new (in 2015) approach has flooded our brains with a deluge of libs, frameworks, tools, concepts, problems, etc. which are a lot more than 5% of the effort of bootstrapping a React app, let alone optimizing it and maintaining it. I know people who's main job is creating React apps and who are overwhelmed with the complexity of the stack. If you don't hire someone dedicated, the rest of your product (domain rules, database optimization, infrastructure, devops, etc.) will suffer.
Post reply on HN