HTTP is the web, not HTML.
HTML is the Web
261–270 of 341 posts
Re: HTML is the Web
#262I feel like many people here are misreading the OP as anti-framework and I didn’t read it that way at all. Sure, there is an element of, “you don’t need to immediately grab the nearest framework as the solution to _every_ problem”, and that’s something I personally agree with. But the point I think the author is trying to make is that whether you do or don’t use a framework, you need to understand the fundamentals. T…
Yes! It’s about semantic HTML. For example, starting a Vue component with a or as root element.
Re: HTML is the Web
#263The biggest takeaway is that HTML was originally designed to degrade gracefully. If your browser didn't support the intended graphical layout, it would still be able to extract the hierarchy and display a usable web page, even if you were using pure text (e.g. lynx). This kept the web accessible no matter what you were using. These days, none of that occurs. Just try switching off Javascript (I use NoScript heavily t…
> The biggest takeaway is that HTML was originally designed to degrade gracefully. ... These days, none of that occurs. This can be directly attributed to the fact that the purpose of the average webpage is no longer to convey information, but to display ads. I frequently see people say that if a site doesn't allow people with an ad blocker to read their content, they immediately bounce off the site, and that site lo…
I hadn't considered this angle, but it does make a lot of sense. If a bouncer wasn't going to give a site ad revenue, the site doesn't want that bouncer in the first place.
This is a horrible state to be in. I mean, I get that advertising is the only way to make regular money on the web, but dear god, we are in a sad situation where people who don't want to be blasted with advertising aren't made welcome.
Re: HTML is the Web
#264I always chime into these articles with the exact same sentiment: this is a business problem, not a developer problem.
Developers love simplicity and semantics. But when a UI gets to a certain level of complexity (I say 10 interactions per page) then semantics get hard to maintain or translate.
I'm building a recommendation engine for a client right now. Lots of wooshes, whirring and moving parts, a good amount of items don't directly translate to semantic HTML elements. It's not clear if my app should have tags, tags or tags.
And again, when a developer has to manage that much complexity, then it's a-ok to breakdown or lose semantics in exchange for comprehensibility. Pretty much any trade-off is ok for comprehensibility. And making my users pay the 500kb React tax is a-ok with me, because I'm not superman and it's only 500kb. One un-optimized image can be that size. It's worth it for the project to be maintainable and reasonable by the next person.
And one day when the business stakeholder decides that people on your education site don't need badges, or that quality content matters more than gamification, then we can dial these interactions back and make the web sane again.
Re: HTML is the Web
#265The biggest takeaway is that HTML was originally designed to degrade gracefully. If your browser didn't support the intended graphical layout, it would still be able to extract the hierarchy and display a usable web page, even if you were using pure text (e.g. lynx). This kept the web accessible no matter what you were using. These days, none of that occurs. Just try switching off Javascript (I use NoScript heavily t…
I feel like I'm going to be in a huge minority here but I am one of those developers that builds websites that won't load without js. Hear me out though. I primarily work with ecom, and we build highly dynamic sites in an increasingly rapid arms race for engaging design. Before vue I worked with jQuery like everyone else, controlling the dom manually to react to changes in application state. Those were dark days. Now…
Also before someone mentions it, I am using SSR where possible so at least something displays, it doesn't make one of these websites function well without js though.
Re: HTML is the Web
#266Unpopular opinion... but I think this is a too limited view of the web. My contrary opinion is that the actually important feature of the web is the URL, and the important feature of the browser is that it provides a sandboxed platform for running untrusted code without a builtin "walled garden moral police". It would be nice if operating systems would be exactly that, but for some reason "commercial" OS vendors are…
ChromeOS is pretty close to what you are talking about... yeah, it's still an App store, but IIRC, you can add an "app" from any URL. It would be nice to see a more open version of what Adobe AIR tried to do, but with node/electron at the core. Unfortunately $VERSIONS makes it difficult to support well with a common runtime, but would still be well worth seeing.
I don't mind Electron too much, current (for 5+ years or so) desktops support running a handful of them without issue (provided at least 8gb ram).
I think that once a few quirks are worked out, we may well see a "one runtime to rule them all" with WebAssembly. WASM + Sandboxed FS + Canvas/WebGL could go a VERY long way towards a lot of application use cases. There's been a lot of work underway for this type of thing and it could be very interesting to say the least. I do think we'll wind up with an XML based markup for UI over the top, maybe a ReactNative-like syntax for WebAssembly+Canvas or WebGL would be very cool.
Re: HTML is the Web
#267A Web page is a document. No it's not. It never was. Even a long time ago when websites were static things rendered by the browser once and then left alone there was always a tree of nodes underlying everything. The only thing that's changed in the past three decades is that now when we make websites and web apps we often ship a little JS application that lets the user modify the underlying tree. That's what the web…
This seems to be a matter of definition : IMHO single-page applications are definitely NOT the Web, but a different subset of the Internet instead (even if you can access them via HTTP).
Re: HTML is the Web
#268The biggest takeaway is that HTML was originally designed to degrade gracefully. If your browser didn't support the intended graphical layout, it would still be able to extract the hierarchy and display a usable web page, even if you were using pure text (e.g. lynx). This kept the web accessible no matter what you were using. These days, none of that occurs. Just try switching off Javascript (I use NoScript heavily t…
I feel like I'm going to be in a huge minority here but I am one of those developers that builds websites that won't load without js. Hear me out though. I primarily work with ecom, and we build highly dynamic sites in an increasingly rapid arms race for engaging design. Before vue I worked with jQuery like everyone else, controlling the dom manually to react to changes in application state. Those were dark days. Now…
I am not protesting the idea that a site should work without JS - quite the opposite, I accept that active content and user interaction requires JS (as much as I loathe the language).
What I am protesting, however, is that graceful degredation doesn't happen. The entire site either breaks or blocks you from viewing static content unless you enable JS. Why am I prevented from viewing a product's information page before I decide whether or not I want to add it to the cart? Why does a news article render as 3 columns of disjointed text that are unreadable until they're assembled? Why don't images load at all unless I permit a CDN to shove a load of JS into my browser for fancy slideshows, zooming, whatever, rather than just placing a small static image there so I can decide if I want to zoom into the dynamic larger image?
The worst ones are those that pop up a banner or overlay that darkens the page with the loaded article until I enable JS. Like, you have literally proved your page works without JS. There is literally no reason for me to enable it, except for you to load several different analytics modules that chew up my CPU and siphon as much identifiable data as they can get their hands on.
Re: HTML is the Web
#269Earlier quoted context omitted.
I feel like this gives an overly rosy picture of the past— The need to serve Paradigm 2 existed all over the place in the plain html days. It’s just instead of having standards-based languages for Paradigm 2, we used to embed janky Flash SWFs and Java applets, were dependent on single vendors to patch zero-days in closed source code, and had to pay hundreds of dollars for licenses for developer tools. Today’s Paradig…
Absolutely agree with this. The Internet-as-appplication-platform has never been better, from a developer's perspective. From a user's perspective, it's maybe a bit more nuanced... I'm tired of websites trying to get around my adblocker, and everyone attempting to enable desktop notifications, for example. If I'm trying to read someone's document they've published, I'd like it to just be a document, thanks. But, incr…
The "notifications" request REALLY pisses me off to no end. A simple "Subscribe" button (if the notifications API is present) would be enough to trigger the request. I wish I could just turn it off all around in the browser... Looking now... Nope, at least in chrome, cannot just disable the feature.
Also agreed, many web apps these days are as good or better than desktop. I actually have worked and am working on applications that replace their desktop counterparts. They're practically easier to scale, tend to have tooling to handle window sizes better, customization is easier and imho just nicer to write against. Better still if you don't have to support legacy browsers. Most browsers today are supporting modules and async import. Still using Webpack and Babel for JSX, but really close to a point where I'd just assume write for esm and have a server-side translation for JSX on demand (cached).
Re: HTML is the Web
#270Earlier quoted context omitted.
I'm inclined to disagree, but I guess the real problem is that webpages on the internet are being forced to serve both purposes. Paradigm 1 - interconnected, hyperlinked web of text-and-content-based documents: open, accessible, amenable to indexing and tooling and so forth. Paradigm 2 - delivery vehicle for cross-platform, full-featured, somewhat-security-sandboxed, applications. I agree with the article that it's s…
I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some po…
Well, the behavior is a bit awkward, and older browsers don't even work right. Of course, some older browsers that shall not be named, you couldn't disable certain styling attributes of buttons, which means an anchor may have been more appropriate back then.
I tend to prefer semantic tags most of the time. I do wish there was a CSS declaration, or maybe an attribute to start off with absolutely NO styling, so that it all comes up from what's in the CSS only. Various resets suck or don't work well, or are really big for various reasons. For that matter, being able to reset everything under a given element that way so that in-browser rules aren't applied would be really nice for WebComponents.
My own weakest point is probably on CSS these days, I just haven't really kept up since 2.x as I haven't really needed to, and can usually google when I need more. I feel the flexbox stuff is more complex than it should be.