Bad sign for me. There's many valid reasons to have a markup available for we applications. Embedding layout this deep into code is just messy for me. The best acceptable way (for me) so far is React.
You mention react but it's does the same thing does it not? JSX is transformed into stuff like React.DOM.li('text', {/options/}) (<- I've only played with react and only written JSX so IDK if that's even right) which looks very similar to what is shown here.
Not entirely the same. React forces the template into a single render function. In this case the whole code is about element rendering. Presentation layer generating code can be anywhere, that's why I think it's messy.
I don't disagree with your premise but let's not lose our shit over a demo page with mixed content. In fact HN is linking to the HTTP version which (obviously) doesn't display this warning and now even the HTTPS version is working. This was not a slight by the developer just an oversight probably left over from developing the landing page locally (which was quickly fixed).
I never like to criticize when someone creates something new. But decades of professional experience (having seen this concept come and go repeatedly over the years), taught me that HTML is your friend. I inherited a project that uses this concept, and there is no maintenance. Not because it's stable, but because it's more delicate than a faberge egg, so we never ever ever touch it.
I'm sure for some small projects with very infrequent layout changes, this could be nice to work with. But for any app of sufficient complexity, keep your markup out of your code be it through DOM construction or in string HTML. (React being the one implementation that MAY prove to be the exception to prove the rule, though it's too early to tell at this point).
I've had this criticism many times in the past, but after doing exclusively JS rendered DOM for about 5 years now, I personally could never go back.
I write large-scale web front-ends as my day-job, they used a number of tools, but the one thing in common is the HTML-free approach. It creates much more manageable codebases, encourages reusability, allows for easy composition, and massive flexibility.
You mention that you "don't touch it" due to decades of experience. Have a look at the example app (https://github.com/KoryNunn/fastn/blob/gh-pages/example/) as an example of app structure. Yes, it's a trivial example, but it's not really that different to the non-trivial apps I build at work.
I think it's great that you created something that you find useful and works for you, and continue to create it after receiving negative criticism. I also think it's great that you're putting it out there, and wish you well with it. I'll end with that, as I don't want to be harsh or overly critical.
> But for any app of sufficient complexity, keep your markup out of your code
I'd rather divide the app into components, each one with its own HTML, CSS and JS, plus the AJAX handlers on the server.
Simply separating HTML from JS is not enough. I remember having to hunt a lot from file to file when I was using jQuery to build websites, because the HTML was in one file, the JS was in completely other file. It wasn't efficient.
I think the declarative approach here, which seems inspired from ReactJS is the nicest. I don't ever want to write direct HTML any more. I prefer to use a fully developed language to declare the page. In such a language you can use repetition, functions and variables to express your markup in a smarter way.
This might be classified as a "nailgun" rather than a "framework" if the only thing I'm nailing is paper to cardboard. The whole "Nothin to see here! Check out index.js" indicates to me that this is the precise opposite of a solution to the problem of more and more sites relying exclusively on piles and piles of Javascript with zero regard for accessibility, privacy (by making the site useless for those who disable Javascript to that effect), performance, etc.
I'm quite stumped at the backlash against only rendering into the DOM and not sending down rendered HTML... Also, as for people who disable JS... Very bluntly: fuck them.
Are there security concerns at running JS? Sure, but you can't take away a HUGE building block of the web and expect everything to just work. It would be like taking away C from your computer, the whole thing comes crashing down. This and frameworks like this are normally for building interactive interfaces and/or full web apps which (let's all say this together) ARE NOT POSSIBLE WITHOUT JAVASCRIPT. PERIOD. The web is a constantly moving target and if frameworks like this break accessibility then maybe accessibility tools need to be re-written/updated to handle client-side rendering (which is where the web is largely going, optionally with an initial render on the server side).
If we are talking about a blog then sure, needing JS is just stupid, my blog works just fine with or without JS but if I'm building a web app there is no way I can reasonably deliver both a cutting edge JS web app AND a static, submit-the-page-to-do-anything app. If you think that's an easy thing to do then you've either never done it or the web app your were working on didn't deserve to be called a web app. I hear this shit from people all the time about how you "don't need JS"... Sure you don't need JS just like you don't need users which is where you will be if you deliver a shitty non-interactive website.
TL;DR: People not using JS are simply not worth the effort to support and if screen readers can't handle JS client-side rendering it's the readers then need to change not the web. It's simply unreasonable to expect all web developers to account for every single edge case. Taking away JS is taking away one of the building blocks of the web and is a BAD idea.
When a web site takes over 10 seconds to load and elements are jumping all over the place as things are rendered, the first thing I'll try is disable Javascript. Next I just say hell with it and not visit the site.
The situation you describe is not one I experience in web APPS. I DO experience it on blogs/news ALL THE TIME and it's normally due to ads being injected. I'm sorry but that's a completely different example then what I'm talking about and rarely due to a framework. I even said:
> If we are talking about a blog then sure, needing JS is just stupid, my blog works just fine with or without JS but if I'm building a web app there is no way I can reasonably deliver both a cutting edge JS web app AND a static, submit-the-page-to-do-anything app.
Not off the top of my head; my only reaction when encountering such "apps" is to immediately close the tab. Why should I keep those in memory? To have myself an argument with some other HN reader? Please.
I'd say that a hefty chunk (if not a majority) of "Show HNs" involving Javascript-heavy anything are riddled with bugs, among said bugs being elements moving around as others load. It's just like web pages in the 90's; for every excellent and well-known app, there tend to be several mangled ones.
EDIT: come to think of it, DuckDuckGo (which I otherwise absolutely love) is a good example of what's being referred to; some elements (particularly for instant answers and "sponsored" results) take longer to load than the search results, and I've found myself frequently clicking the wrong link because of my intended link shifting down without warning. This was especially prevalent prior to the recent redesign (nowadays it seems to be less of a problem).
While maybe this doesn't fit your definition of "web app", it's still relatively JS-heavy by default (though DDG is also an excellent example of progressive enhancement / graceful degradation) and is a decent demonstration of web-app-like concepts (and, in my belief, fits the actual definition of "interactive web app" quite well).
This library is clearly intended to create dynamic and interactive interfaces, too. If you've got JS disabled, whatever you build with it wouldn't work if you built it with literally any other JS framework or library anyways.
There's no more reason for people to get angry over this JS library than there is to get angry over jQuery, Angular, React, or anything else people have been using to build fully functional products on the internet for years.
In my opinion, most sites should at least maintain a core subset of functionality that can work without JS. Sites existed before JS that let people read news and engage in commerce, there's no reason we should lose all that.
Also, as we now enter a future where billions of people who never used a desktop computer begin mobile banking, being able to conduct business without JS might be one avenue to combat fraud.
While I agree in concept in reality this is normally not possible. For a company like Google? Sure but for most companies out there they just aren't going to have the developer and QA resources to continuously test both JS and no-JS flows. For banks? Yes they can probably support both but honestly banks will probably move to MORE js to thwart fraud as in making sure you are a real person based on our mouse movements or other things. As for news sites, 10000% they should work without JS, the printed word is their bread and butter (even with some place coming up with more interactive news stories) so they should have no trouble supporting no-js browsers. There is a fear that they may just say "fuck you" to non-js people though if it significantly affects their advertizing (Lack of tracking or dynamic ad injection).
There's a good article on progressive enhancement (which is, alongside / in addition to graceful degredation, what's usually referred to when one talks about JS/non-JS hybrid flows) that addresses the cited pain points and "myths". [0] The claim that PE is "twice the effort" is directly addressed; basically, it's not twice the effort at all if one actually designs one's app to support PE/GD from the start (or otherwise starts with bare server-generated HTML and adds on layers of interactivity from there).
> If you think that's an easy thing to do then you've either never done it or the web app your were working on didn't deserve to be called a web app.
I actually do this on a daily basis as my dayjob. If you're using a proper server-side framework, this is quite trivial.
Of course, I already expect you'll retort with some half-assed no-true-Scotsman ("well your web apps aren't real web apps!"), in which case I'd likely ask for your definition of "web app", why said definition is unattainable without creating some Javascript-only monstrosity, and why said monstrosity isn't implemented instead as a native application if it really does go beyond what a more sane use of HTML/CSS/JS/some-server-side-scripting can offer.
> if screen readers can't handle JS client-side rendering it's the readers then need to change not the web.
And how would you go about implementing that? A text-to-speech interface isn't like a visible webpage, where you can easily scroll around and jump from thing to thing and notice that some random DOM element has changed. Perhaps the screenreader could read newly-created DOM elements, but that'll become really annoying for elements that frequently change/disappear/reappear, as is often the case for web apps of the variety that you advocate.
This isn't to mention that not all screenreaders are auditory. Quite a few blind computer users use braille displays. How will your web app work with such displays? How will it work with a keyboard and no mouse (since what good is a mouse pointer if you can't see the pointer on the screen)? Or is your answer to just say "fuck them"?
> It would be like taking away C from your computer, the whole thing comes crashing down.
That's not quite true (and, in fact, is rather amusing in this day and age of C-ABI-compatible languages like Rust being the latest hot shit). Plenty of operating systems are written in languages other than C, and it's very much possible to have a computer without any C code at all. Hell, even with C, removing C won't do a whole lot; the computer is executing compiled machine code, not trying to run C directly.
---
In my opinion, rendering into the DOM exclusively is just as much an affront to the concept of a "semantic" web as using HTML tables for creating a page layout. Save the Javascript for things that actually need interaction; for everything else, plain HTML is not only sufficient, but even superior, since it's less likely to break on some confounding variable like whether I'm using Chrome or Firefox (or, god forbid, Internet Explorer) or whether I'm blind and my screen reader doesn't readily handle elements flying in and out of existence at arbitrary points in time.
That's the point of the "semantic" web, after all: HTML for content, CSS for presentation, Javascript for interaction. Just because breaking away from that is popular doesn't mean it's a smart thing to do.
This isn't to say that such behavior is always unacceptable, of course; there are web apps that do JS-only things rather well (Trello, for example). That tends to be the case when a JS-only approach is absolutely necessary. 99% of the time, however, HTML would be more than sufficient, with maybe some Javascript here and there to make things prettier. For the remaining 1%, a public API would do wonders for those seeking to build more accessible clients, in which case the web app being JS-only wouldn't be quite as much of a problem.
Of course, at least Trello has a warning in <noscript>...</noscript> tags telling users to enable Javascript. The bit of HTML my comment responded to didn't even have that courtesy.
Your viewpoint would be more acceptable if Javascript weren't the sluggish and fragile pile of shit it currently is and has been thro...
>> If you think that's an easy thing to do then you've either never done it or the web app your were working on didn't deserve to be called a web app.
> I actually do this on a daily basis as my dayjob. If you're using a proper server-side framework, this is quite trivial.
> Of course, I already expect you'll retort with some half-assed no-true-Scotsman ("well your web apps aren't real web apps!"), in which case I'd likely ask for your definition of "web app", why said definition is unattainable without creating some Javascript-only monstrosity, and why said monstrosity isn't implemented instead as a native application if it really does go beyond what a more sane use of HTML/CSS/JS/some-server-side-scripting can offer.
What framework are you using that allows you to design interactive web apps without JS?
>> if screen readers can't handle JS client-side rendering it's the readers then need to change not the web.
> And how would you go about implementing that? A text-to-speech interface isn't like a visible webpage, where you can easily scroll around and jump from thing to thing and notice that some random DOM element has changed. Perhaps the screenreader could read newly-created DOM elements, but that'll become really annoying for elements that frequently change/disappear/reappear, as is often the case for web apps of the variety that you advocate.
> This isn't to mention that not all screenreaders are auditory. Quite a few blind computer users use braille displays. How will your web app work with such displays? How will it work with a keyboard and no mouse (since what good is a mouse pointer if you can't see the pointer on the screen)? Or is your answer to just say "fuck them"?
So how do screenreaders handle jQuery? Because at the end of the day React and jQuery manipulate the DOM in the same way. React renders to a virtual DOM then diff's that with it's representation of the real DOM and applies only that diff in the same way you might do $('#myElement').css('color', 'red); Some frameworks like angular even have modules specially for screenreaders (https://docs.angularjs.org/api/ngAria).
>> It would be like taking away C from your computer, the whole thing comes crashing down.
> That's not quite true (and, in fact, is rather amusing in this day and age of C-ABI-compatible languages like Rust being the latest hot shit). Plenty of operating systems are written in languages other than C, and it's very much possible to have a computer without any C code at all. Hell, even with C, removing C won't do a whole lot; the computer is executing compiled machine code, not trying to run C directly.
When I saw "C" I just meant "basic building block" of which rust is. JS is the only "language" of the web other than something like NPAPI which google is phasing out. Now there is P/NaCL but that's not widely used AFAIK or at least it's not used for building something like a web app, it's more for games. Pretty much: yes you can get by without C but it's because you can always fall back to assembly, the same is not true for the web.
----
Trello is a perfect example of what I would consider a "web app", it's simply not possible to recreate without JS. This is what I'm advocating JS framework use for. As for a blog/news it's fine if they use a JS framework as long as they can fall back to a non-js page or render the js page on the server side (this only works for non-interactive sites).
Just to give you an idea of where I'm coming from, at my $dayJob I work on a large non-public web app that uses popups, sortable tables, live-updating tables of data, interactive google maps, interactive calendars, and more. For this it'...
> What framework are you using that allows you to design interactive web apps without JS?
This is a Rails consultancy, so... Rails. We use Foundation for most things view-side (which, admittedly, involves some Javascript, but only for certain parts; said parts aren't used very often), but pretty much all the heavy lifting is done controller-side. We do like using AJAX here and there, mind you, but only when actually necessary.
Sure, it ain't Trello with its drag-and-drop doodads and such, but we've built plenty of rather excellent web apps without such gizmos. That degree of interactivity isn't strictly necessary, and - in fact - can often be a distraction.
For my personal projects, I've mostly been using Elixir lately (with the Sugar framework), and Pure instead of Foundation for CSS-related things.
> So how do screenreaders handle jQuery? Because at the end of the day React and jQuery manipulate the DOM in the same way. React renders to a virtual DOM then diff's that with it's representation of the real DOM and applies only that diff in the same way you might do $('#myElement').css('color', 'red); Some frameworks like angular even have modules specially for screenreaders (https://docs.angularjs.org/api/ngAria).
Not as well as you'd think.
Screenreaders do read the DOM rather than directly from HTML documents, so a JS-only site that's otherwise static wouldn't have very many problems in all likelihood. The problems arise when the DOM is manipulated; screenreaders (including Aria) have tended to have rather pessimal behavior when encountering things like JQuery popups (for example), whether that means failing to read the popup entirely, reading only part of it, reading only an "OK" button, reading it but then reading everything after it even if said everything has already been read, etc. I mentioned these things in another comment on this thread [0].
This isn't to mention that JS-only apps tend to be very mouse and touch heavy. This is a non-starter for most blind users, who AFAIK tend to be very keyboard-centric.
> Trello is a perfect example of what I would consider a "web app", it's simply not possible to recreate without JS.
Maybe not exactly, but all its functionality is arguably possible without any Javascript whatsoever.
Let's start with moving cards between lists. Currently, one has to drag-and-drop. There's little reason why that can't instead be implemented as left/right arrow buttons on each card, each resulting in a POST to the server telling it to move the card with the specified ID to the next list in whichever direction. The server then updates the card on its end and sends back the updated HTML.
Then, there's the reordering of cards. Again, totally possible; just put up/down arrow buttons on each card. Same deal as before; server performs the reorder and sends back the result.
For adding cards to lists (and adding new lists to boards), there are already links present to do those things; making them do the same thing as above (leave all the processing to the server, which then sends back the updated HTML) would work quite alright.
You then have the side menu. The pop-out would indeed be impossible without Javascript, but its functionality wouldn't; the "Add Members..." button could point to a separate member add page (or be replaced with the current result of clicking that button, which is simply a text box prompting for an email address to search for), while the member list and the activity feed can easily be rendered server-side.
Same story for the individual list menus; the pop-out requires Javascript, but the rest is trivial to render server-side as part of the list's div.
Then we have the card screen, which can easily be its own page. Like above, pretty much everything here can be do...
While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was. I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost? I could, given time, recreate the entire platform I code on every day to be js-free but I'd be fired for pissing off clients. I could probably even reimplement our google map that you can draw a polygon on without JS but it would take a LOT more time and it would be so painful to use that it wouldn't matter.
I don't want to say people who rely on screen readers don't matter and I think it can be fixed for them. However people who disable JS really shouldn't matter to you unless you are Facebook, Google, Apple, Amazon, etc. Even then some of those sites don't work without JS which could (Like google drive). It's simply not worth the resources to support a small group of people who have knocked out the foundation of a house and are expecting it to stand up just fine. "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
When it comes to the web you need to optimise for the 98% not the 2% (I'm being generous with that 2% number BTW) especially when that 2% CHOOSE to create this problem for themselves.
> While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was.
I disagree. Very little (if any) actual functionality would be lost. The differences would be more-or-less cosmetic and (to a limited extent, though I think this would be positive rather than negative in many cases) ergonomic.
> I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost?
None if you design your app with progressive enhancement in mind. Drag-and-drop and other forms of "interactivity" could be added onto the non-JS version rather easily.
> It's simply not worth the resources
It costs resources if it's not something you consider right from the get-go.
In other words, it only looks like it would use more resources because you're coming at this from the perspective of "okay, here's a JS-heavy app; how do we make it JS-free?" instead of the more efficient perspective of "okay, here's an app solely in HTML, CSS, and Rails; what JavaScript should we add to make this cooler?". The former is like trying to learn how to ride a motorcycle before learning how to ride a bicycle.
> "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
I agree with this. That doesn't mean that the existence of Javascript can always be assumed.
Javascript in and of itself isn't a detriment, but many of its uses are. That's not FUD, that's reality. If we're going to charge right into this Web 2.0 future of Javascript-only doodads, then there are a multitude of things which need to be considered, like "will a screen reader properly handle my JQuery popups?" [0] or "will a screen reader properly identify a DOM update and read it? [1] or "will a screen reader handle my password dialog in a secure manner?" [2]. And these are all with basic, HTML + bits-of-JS pages, let alone a full-on JS-only web app.
That second article makes an excellent point, by the way: that the concept of "interactivity" usually sought after might very well be a biased view of what an ideal interface should look like. Interactivity means different things to different users, and in the same vein can be either a blessing or a curse; it isn't a magical universal solution to all the world's problems.
Accessibility: Screen readers read DOM, not HTML. As long as you produce good DOM, screen readers will work fine.
Privacy (JS off): You can't make a complex web-app without JavaScript, and statistically speaking, everyone has it on always.
Performance: This can be measured in may ways.
- Server time: fastn is just static files, so server time is negligible.
- Transport time: fastn apps are often smaller than the DOM they produce, so server-side rendering the content first would only slow down load times. The trivial example app is 31KB, a large AWS-like application at work is about 40KB.
- Initialisation time: fastn is very fast. On my old slow work PC, the homepage loads 165ms after page ready, and its about a 700ms wait from hitting the refresh button, to everything being shown.
But then, judging by your "paper to cardboard" comment, you aren't here to discuss pros 'n cons :)
Also, the next issue people usually have is SEO. Here is the google result for the fastn homepage, which has absolutely no HTML in the body: http://imgur.com/tZBSau8
Search engine traversal of JS-only sites is still imperfect; the problem of crawling a site that's dynamically generated from Javascript alone is probably Turing-complete :)
> Accessibility: Screen readers read DOM, not HTML. As long as you produce good DOM, screen readers will work fine.
I'm aware of that. My point was more about DOM changes, which is typically the reason why someone would write a JS-only web app in the first place. That's something that screen readers still handle rather poorly, as I indicated in another comment in this thread. [0]
Of course, if you've managed to address those things in fastn, then I'd be pleasantly surprised.
> You can't make a complex web-app without JavaScript
Sure you can. It might not be quite as "interactive" as you'd like, but interactivity isn't really a requirement.
Really, though, my preference is something like progressive enhancement, where the app degrades gracefully should something be missing (like Javascript). In such a context, perhaps fastn would indeed be a good fit as part of that final layer of Javascript.
> everyone has it on always.
Not true. Plenty of corporate environments block Javascript for security reasons.
Of course, it's easy to think that way. "My site is only loaded by people who have Javascript enabled, so everyone must use Javascript; never mind that my sample size might be small, or that I'm not properly logging connections where my JS blobs didn't get to run".
This isn't to mention that not all JS runtimes are equal. Safari's different from Chrome, which is different from Firefox, which is different from Opera, which is different from Internet Explorer, which is (supposedly) different from Spartan, etc.
At this point, I should note that neither of the two previous points had anything to do with the privacy rationale for turning Javascript off.
> fastn is just static files, so server time is negligible.
This assumes that there aren't delays from having to load additional files, which is an issue with HTTP/1.x (though not with HTTP/2, IIRC).
> fastn apps are often smaller than the DOM they produce, so server-side rendering the content first would only slow down load times.
Yes, but that would be offset by having to actually produce the DOM client-side, would it not? It would also be offset by the performance penalty of having a bunch of Javascript running, though I admittedly haven't tested fastn on slower machines yet, so perhaps you've solved that particular problem that other JS-heavy things tend to have.
It's like saying I can download a Ruby script faster than a C source file and citing it as an example of how Ruby performs better than C.
> Initialisation time
That's not what I especially care about, since that's reasonable. My concern is with long-term performance; a Javascript-heavy page or app can easily end up pegging a CPU core or gobble memory or lock up a browser session or tab. Have you benchmarked that sort of thing and verified that fastn is consistently fast? Have you verified fastn's CPU and memory footprints?
Remember that the point of server-side things is to reduce the workload on the client. Said workload doesn't go away after initialization.
Meanwhile...
> On my old slow work PC
Define "old" and "slow". Would it be older or slower than a midrange laptop? How about a Chromebook or some other netbook-derivative? A budget smartphone or tablet (or perhaps one that was top-of-the-line two years ago)? Or perhaps one of those cheap Celeron-based desktops that the likes of Staples and Wal-Mart sell for pennies?
These categories of hardware are abundant, and yet tend to be hit the hardest with even the slightest Javascript-related performance issue.
> But then, judging by your "paper to cardboard" comment, you aren't here to discuss pros 'n cons :)
Nah, that's just me being a bit abrasive to make a point.
Don't get me wrong; fastn looks pretty cool, and I'd definitely be inclined to use it. It's just the "...
- Most screen readers handle DOM updates just fine.
- I'm defining a web-app as something that feels like an application, not a website. If you are making a news site, fastn probably isn't the way to render everything. You can however just use fastn enhanced functionality, since it isn't a framework, just a tool to make chunks of UI.
- on average, 99% of users have JavaScript installed. As above, if your target audience is `literally everyone`, sure, fastn probably isn't the way to go. Having been a library developer for nearly a decade now, I am intimately aware that different browsers have differences. Fastn should work the same on all modern browsers, and if you find any bugs, let me know and I'll fix them :).
- Delays from loading additional files will be negligible. Not sure how to back that statement up tho ¯\_(ツ)_/¯
- As mentioned, rendering a fastn app on the client is very fast, faster than serving an equivalent page from ASP.net for example, even in a 1:1 race. The issue with server-side templating is that there is one server rendering N requests, whereas with client-side rendering, the N clients are doing the heavy (actually pretty light) lifting.
- I spend an enormous chunk of my time doing performance analysis and improvements. Have a look at recent commits to fastn or enti (the databinding module) and you will see quite a few commits with "performance" in them. We have non-trivial applications using fastn that perform at extremely acceptable speed (hundreds of fields, with live validation, across multiple tabs, renders in around 150ms)
- My work PC is only a few times faster than my Nexus 5. Btw, the homepage renders in 1.2s(~500ms JS) on my phone.
I hope you do give it a go. Fastn isn't a tool for every job, that's the point, it's just a tool. It's up to the developer to decide if it is appropriate.
It has been developed mostly with cordova apps in mind (and yes, they have been made with it, and are quite snappy), where abandoning HTML is actually really nice. It makes writing apps more like how you would do it native, in code, not a markup language.
> - Most screen readers handle DOM updates just fine.
You sure about that? Because last I checked (and as I indicated in the linked comment), that's not actually true (at least not without some serious consideration from the app developer's side of things).
The rest of your comment, pleasantly-surprisingly, is good to hear (though I'm concerned that lower-end devices aren't getting enough attention; I know firsthand (from witnessing it with my coworkers and even with myself) how easy it is to assume that everyone has wonderful hardware and accidentally create something that readily bogs down hardware with even the slightest amount of age), and I do wish you the best of luck with this.
39 comments
[ 3.5 ms ] story [ 106 ms ] threadill try this out :)
Bad sign for me. There's many valid reasons to have a markup available for we applications. Embedding layout this deep into code is just messy for me. The best acceptable way (for me) so far is React.
Of course some might like it for some use cases.
Can we stopped with the mixed content and go full HTTPS already?
I'm sure for some small projects with very infrequent layout changes, this could be nice to work with. But for any app of sufficient complexity, keep your markup out of your code be it through DOM construction or in string HTML. (React being the one implementation that MAY prove to be the exception to prove the rule, though it's too early to tell at this point).
I write large-scale web front-ends as my day-job, they used a number of tools, but the one thing in common is the HTML-free approach. It creates much more manageable codebases, encourages reusability, allows for easy composition, and massive flexibility.
You mention that you "don't touch it" due to decades of experience. Have a look at the example app (https://github.com/KoryNunn/fastn/blob/gh-pages/example/) as an example of app structure. Yes, it's a trivial example, but it's not really that different to the non-trivial apps I build at work.
Maybe it's time to give it a go again?
I'd rather divide the app into components, each one with its own HTML, CSS and JS, plus the AJAX handlers on the server.
Simply separating HTML from JS is not enough. I remember having to hunt a lot from file to file when I was using jQuery to build websites, because the HTML was in one file, the JS was in completely other file. It wasn't efficient.
I think the declarative approach here, which seems inspired from ReactJS is the nicest. I don't ever want to write direct HTML any more. I prefer to use a fully developed language to declare the page. In such a language you can use repetition, functions and variables to express your markup in a smarter way.
Are there security concerns at running JS? Sure, but you can't take away a HUGE building block of the web and expect everything to just work. It would be like taking away C from your computer, the whole thing comes crashing down. This and frameworks like this are normally for building interactive interfaces and/or full web apps which (let's all say this together) ARE NOT POSSIBLE WITHOUT JAVASCRIPT. PERIOD. The web is a constantly moving target and if frameworks like this break accessibility then maybe accessibility tools need to be re-written/updated to handle client-side rendering (which is where the web is largely going, optionally with an initial render on the server side).
If we are talking about a blog then sure, needing JS is just stupid, my blog works just fine with or without JS but if I'm building a web app there is no way I can reasonably deliver both a cutting edge JS web app AND a static, submit-the-page-to-do-anything app. If you think that's an easy thing to do then you've either never done it or the web app your were working on didn't deserve to be called a web app. I hear this shit from people all the time about how you "don't need JS"... Sure you don't need JS just like you don't need users which is where you will be if you deliver a shitty non-interactive website.
TL;DR: People not using JS are simply not worth the effort to support and if screen readers can't handle JS client-side rendering it's the readers then need to change not the web. It's simply unreasonable to expect all web developers to account for every single edge case. Taking away JS is taking away one of the building blocks of the web and is a BAD idea.
So... fuck you.
> If we are talking about a blog then sure, needing JS is just stupid, my blog works just fine with or without JS but if I'm building a web app there is no way I can reasonably deliver both a cutting edge JS web app AND a static, submit-the-page-to-do-anything app.
You clearly haven't used very many of these "web APPS" you champion, then.
I'd say that a hefty chunk (if not a majority) of "Show HNs" involving Javascript-heavy anything are riddled with bugs, among said bugs being elements moving around as others load. It's just like web pages in the 90's; for every excellent and well-known app, there tend to be several mangled ones.
EDIT: come to think of it, DuckDuckGo (which I otherwise absolutely love) is a good example of what's being referred to; some elements (particularly for instant answers and "sponsored" results) take longer to load than the search results, and I've found myself frequently clicking the wrong link because of my intended link shifting down without warning. This was especially prevalent prior to the recent redesign (nowadays it seems to be less of a problem).
While maybe this doesn't fit your definition of "web app", it's still relatively JS-heavy by default (though DDG is also an excellent example of progressive enhancement / graceful degradation) and is a decent demonstration of web-app-like concepts (and, in my belief, fits the actual definition of "interactive web app" quite well).
There's no more reason for people to get angry over this JS library than there is to get angry over jQuery, Angular, React, or anything else people have been using to build fully functional products on the internet for years.
Also, as we now enter a future where billions of people who never used a desktop computer begin mobile banking, being able to conduct business without JS might be one avenue to combat fraud.
[0]: http://www.sitepoint.com/javascript-dependency-backlash-myth...
I actually do this on a daily basis as my dayjob. If you're using a proper server-side framework, this is quite trivial.
Of course, I already expect you'll retort with some half-assed no-true-Scotsman ("well your web apps aren't real web apps!"), in which case I'd likely ask for your definition of "web app", why said definition is unattainable without creating some Javascript-only monstrosity, and why said monstrosity isn't implemented instead as a native application if it really does go beyond what a more sane use of HTML/CSS/JS/some-server-side-scripting can offer.
> if screen readers can't handle JS client-side rendering it's the readers then need to change not the web.
And how would you go about implementing that? A text-to-speech interface isn't like a visible webpage, where you can easily scroll around and jump from thing to thing and notice that some random DOM element has changed. Perhaps the screenreader could read newly-created DOM elements, but that'll become really annoying for elements that frequently change/disappear/reappear, as is often the case for web apps of the variety that you advocate.
This isn't to mention that not all screenreaders are auditory. Quite a few blind computer users use braille displays. How will your web app work with such displays? How will it work with a keyboard and no mouse (since what good is a mouse pointer if you can't see the pointer on the screen)? Or is your answer to just say "fuck them"?
> It would be like taking away C from your computer, the whole thing comes crashing down.
That's not quite true (and, in fact, is rather amusing in this day and age of C-ABI-compatible languages like Rust being the latest hot shit). Plenty of operating systems are written in languages other than C, and it's very much possible to have a computer without any C code at all. Hell, even with C, removing C won't do a whole lot; the computer is executing compiled machine code, not trying to run C directly.
---
In my opinion, rendering into the DOM exclusively is just as much an affront to the concept of a "semantic" web as using HTML tables for creating a page layout. Save the Javascript for things that actually need interaction; for everything else, plain HTML is not only sufficient, but even superior, since it's less likely to break on some confounding variable like whether I'm using Chrome or Firefox (or, god forbid, Internet Explorer) or whether I'm blind and my screen reader doesn't readily handle elements flying in and out of existence at arbitrary points in time.
That's the point of the "semantic" web, after all: HTML for content, CSS for presentation, Javascript for interaction. Just because breaking away from that is popular doesn't mean it's a smart thing to do.
This isn't to say that such behavior is always unacceptable, of course; there are web apps that do JS-only things rather well (Trello, for example). That tends to be the case when a JS-only approach is absolutely necessary. 99% of the time, however, HTML would be more than sufficient, with maybe some Javascript here and there to make things prettier. For the remaining 1%, a public API would do wonders for those seeking to build more accessible clients, in which case the web app being JS-only wouldn't be quite as much of a problem.
Of course, at least Trello has a warning in <noscript>...</noscript> tags telling users to enable Javascript. The bit of HTML my comment responded to didn't even have that courtesy.
Your viewpoint would be more acceptable if Javascript weren't the sluggish and fragile pile of shit it currently is and has been thro...
What framework are you using that allows you to design interactive web apps without JS?
>> if screen readers can't handle JS client-side rendering it's the readers then need to change not the web. > And how would you go about implementing that? A text-to-speech interface isn't like a visible webpage, where you can easily scroll around and jump from thing to thing and notice that some random DOM element has changed. Perhaps the screenreader could read newly-created DOM elements, but that'll become really annoying for elements that frequently change/disappear/reappear, as is often the case for web apps of the variety that you advocate. > This isn't to mention that not all screenreaders are auditory. Quite a few blind computer users use braille displays. How will your web app work with such displays? How will it work with a keyboard and no mouse (since what good is a mouse pointer if you can't see the pointer on the screen)? Or is your answer to just say "fuck them"?
So how do screenreaders handle jQuery? Because at the end of the day React and jQuery manipulate the DOM in the same way. React renders to a virtual DOM then diff's that with it's representation of the real DOM and applies only that diff in the same way you might do $('#myElement').css('color', 'red); Some frameworks like angular even have modules specially for screenreaders (https://docs.angularjs.org/api/ngAria).
>> It would be like taking away C from your computer, the whole thing comes crashing down. > That's not quite true (and, in fact, is rather amusing in this day and age of C-ABI-compatible languages like Rust being the latest hot shit). Plenty of operating systems are written in languages other than C, and it's very much possible to have a computer without any C code at all. Hell, even with C, removing C won't do a whole lot; the computer is executing compiled machine code, not trying to run C directly.
When I saw "C" I just meant "basic building block" of which rust is. JS is the only "language" of the web other than something like NPAPI which google is phasing out. Now there is P/NaCL but that's not widely used AFAIK or at least it's not used for building something like a web app, it's more for games. Pretty much: yes you can get by without C but it's because you can always fall back to assembly, the same is not true for the web.
----
Trello is a perfect example of what I would consider a "web app", it's simply not possible to recreate without JS. This is what I'm advocating JS framework use for. As for a blog/news it's fine if they use a JS framework as long as they can fall back to a non-js page or render the js page on the server side (this only works for non-interactive sites).
Just to give you an idea of where I'm coming from, at my $dayJob I work on a large non-public web app that uses popups, sortable tables, live-updating tables of data, interactive google maps, interactive calendars, and more. For this it'...
This is a Rails consultancy, so... Rails. We use Foundation for most things view-side (which, admittedly, involves some Javascript, but only for certain parts; said parts aren't used very often), but pretty much all the heavy lifting is done controller-side. We do like using AJAX here and there, mind you, but only when actually necessary.
Sure, it ain't Trello with its drag-and-drop doodads and such, but we've built plenty of rather excellent web apps without such gizmos. That degree of interactivity isn't strictly necessary, and - in fact - can often be a distraction.
For my personal projects, I've mostly been using Elixir lately (with the Sugar framework), and Pure instead of Foundation for CSS-related things.
> So how do screenreaders handle jQuery? Because at the end of the day React and jQuery manipulate the DOM in the same way. React renders to a virtual DOM then diff's that with it's representation of the real DOM and applies only that diff in the same way you might do $('#myElement').css('color', 'red); Some frameworks like angular even have modules specially for screenreaders (https://docs.angularjs.org/api/ngAria).
Not as well as you'd think.
Screenreaders do read the DOM rather than directly from HTML documents, so a JS-only site that's otherwise static wouldn't have very many problems in all likelihood. The problems arise when the DOM is manipulated; screenreaders (including Aria) have tended to have rather pessimal behavior when encountering things like JQuery popups (for example), whether that means failing to read the popup entirely, reading only part of it, reading only an "OK" button, reading it but then reading everything after it even if said everything has already been read, etc. I mentioned these things in another comment on this thread [0].
This isn't to mention that JS-only apps tend to be very mouse and touch heavy. This is a non-starter for most blind users, who AFAIK tend to be very keyboard-centric.
> Trello is a perfect example of what I would consider a "web app", it's simply not possible to recreate without JS.
Maybe not exactly, but all its functionality is arguably possible without any Javascript whatsoever.
Let's start with moving cards between lists. Currently, one has to drag-and-drop. There's little reason why that can't instead be implemented as left/right arrow buttons on each card, each resulting in a POST to the server telling it to move the card with the specified ID to the next list in whichever direction. The server then updates the card on its end and sends back the updated HTML.
Then, there's the reordering of cards. Again, totally possible; just put up/down arrow buttons on each card. Same deal as before; server performs the reorder and sends back the result.
For adding cards to lists (and adding new lists to boards), there are already links present to do those things; making them do the same thing as above (leave all the processing to the server, which then sends back the updated HTML) would work quite alright.
You then have the side menu. The pop-out would indeed be impossible without Javascript, but its functionality wouldn't; the "Add Members..." button could point to a separate member add page (or be replaced with the current result of clicking that button, which is simply a text box prompting for an email address to search for), while the member list and the activity feed can easily be rendered server-side.
Same story for the individual list menus; the pop-out requires Javascript, but the rest is trivial to render server-side as part of the list's div.
Then we have the card screen, which can easily be its own page. Like above, pretty much everything here can be do...
I don't want to say people who rely on screen readers don't matter and I think it can be fixed for them. However people who disable JS really shouldn't matter to you unless you are Facebook, Google, Apple, Amazon, etc. Even then some of those sites don't work without JS which could (Like google drive). It's simply not worth the resources to support a small group of people who have knocked out the foundation of a house and are expecting it to stand up just fine. "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
When it comes to the web you need to optimise for the 98% not the 2% (I'm being generous with that 2% number BTW) especially when that 2% CHOOSE to create this problem for themselves.
I disagree. Very little (if any) actual functionality would be lost. The differences would be more-or-less cosmetic and (to a limited extent, though I think this would be positive rather than negative in many cases) ergonomic.
> I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost?
None if you design your app with progressive enhancement in mind. Drag-and-drop and other forms of "interactivity" could be added onto the non-JS version rather easily.
> It's simply not worth the resources
It costs resources if it's not something you consider right from the get-go.
In other words, it only looks like it would use more resources because you're coming at this from the perspective of "okay, here's a JS-heavy app; how do we make it JS-free?" instead of the more efficient perspective of "okay, here's an app solely in HTML, CSS, and Rails; what JavaScript should we add to make this cooler?". The former is like trying to learn how to ride a motorcycle before learning how to ride a bicycle.
> "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
I agree with this. That doesn't mean that the existence of Javascript can always be assumed.
That second article makes an excellent point, by the way: that the concept of "interactivity" usually sought after might very well be a biased view of what an ideal interface should look like. Interactivity means different things to different users, and in the same vein can be either a blessing or a curse; it isn't a magical universal solution to all the world's problems.
[0]: http://stackoverflow.com/questions/18475332/screen-reader-jq...
[1]: http://www.sitepoint.com/ajax-screenreaders-work/
[2]: http://www.sitepoint.com/show-password-javascript-accessibil...
Privacy (JS off): You can't make a complex web-app without JavaScript, and statistically speaking, everyone has it on always.
Performance: This can be measured in may ways.
- Server time: fastn is just static files, so server time is negligible.
- Transport time: fastn apps are often smaller than the DOM they produce, so server-side rendering the content first would only slow down load times. The trivial example app is 31KB, a large AWS-like application at work is about 40KB.
- Initialisation time: fastn is very fast. On my old slow work PC, the homepage loads 165ms after page ready, and its about a 700ms wait from hitting the refresh button, to everything being shown.
But then, judging by your "paper to cardboard" comment, you aren't here to discuss pros 'n cons :)
I'm aware of that. My point was more about DOM changes, which is typically the reason why someone would write a JS-only web app in the first place. That's something that screen readers still handle rather poorly, as I indicated in another comment in this thread. [0]
Of course, if you've managed to address those things in fastn, then I'd be pleasantly surprised.
> You can't make a complex web-app without JavaScript
Sure you can. It might not be quite as "interactive" as you'd like, but interactivity isn't really a requirement.
Really, though, my preference is something like progressive enhancement, where the app degrades gracefully should something be missing (like Javascript). In such a context, perhaps fastn would indeed be a good fit as part of that final layer of Javascript.
> everyone has it on always.
Not true. Plenty of corporate environments block Javascript for security reasons.
Of course, it's easy to think that way. "My site is only loaded by people who have Javascript enabled, so everyone must use Javascript; never mind that my sample size might be small, or that I'm not properly logging connections where my JS blobs didn't get to run".
This isn't to mention that not all JS runtimes are equal. Safari's different from Chrome, which is different from Firefox, which is different from Opera, which is different from Internet Explorer, which is (supposedly) different from Spartan, etc.
At this point, I should note that neither of the two previous points had anything to do with the privacy rationale for turning Javascript off.
> fastn is just static files, so server time is negligible.
This assumes that there aren't delays from having to load additional files, which is an issue with HTTP/1.x (though not with HTTP/2, IIRC).
> fastn apps are often smaller than the DOM they produce, so server-side rendering the content first would only slow down load times.
Yes, but that would be offset by having to actually produce the DOM client-side, would it not? It would also be offset by the performance penalty of having a bunch of Javascript running, though I admittedly haven't tested fastn on slower machines yet, so perhaps you've solved that particular problem that other JS-heavy things tend to have.
It's like saying I can download a Ruby script faster than a C source file and citing it as an example of how Ruby performs better than C.
> Initialisation time
That's not what I especially care about, since that's reasonable. My concern is with long-term performance; a Javascript-heavy page or app can easily end up pegging a CPU core or gobble memory or lock up a browser session or tab. Have you benchmarked that sort of thing and verified that fastn is consistently fast? Have you verified fastn's CPU and memory footprints?
Remember that the point of server-side things is to reduce the workload on the client. Said workload doesn't go away after initialization.
Meanwhile...
> On my old slow work PC
Define "old" and "slow". Would it be older or slower than a midrange laptop? How about a Chromebook or some other netbook-derivative? A budget smartphone or tablet (or perhaps one that was top-of-the-line two years ago)? Or perhaps one of those cheap Celeron-based desktops that the likes of Staples and Wal-Mart sell for pennies?
These categories of hardware are abundant, and yet tend to be hit the hardest with even the slightest Javascript-related performance issue.
> But then, judging by your "paper to cardboard" comment, you aren't here to discuss pros 'n cons :)
Nah, that's just me being a bit abrasive to make a point.
Don't get me wrong; fastn looks pretty cool, and I'd definitely be inclined to use it. It's just the "...
- I'm defining a web-app as something that feels like an application, not a website. If you are making a news site, fastn probably isn't the way to render everything. You can however just use fastn enhanced functionality, since it isn't a framework, just a tool to make chunks of UI.
- on average, 99% of users have JavaScript installed. As above, if your target audience is `literally everyone`, sure, fastn probably isn't the way to go. Having been a library developer for nearly a decade now, I am intimately aware that different browsers have differences. Fastn should work the same on all modern browsers, and if you find any bugs, let me know and I'll fix them :).
- Delays from loading additional files will be negligible. Not sure how to back that statement up tho ¯\_(ツ)_/¯
- As mentioned, rendering a fastn app on the client is very fast, faster than serving an equivalent page from ASP.net for example, even in a 1:1 race. The issue with server-side templating is that there is one server rendering N requests, whereas with client-side rendering, the N clients are doing the heavy (actually pretty light) lifting.
- I spend an enormous chunk of my time doing performance analysis and improvements. Have a look at recent commits to fastn or enti (the databinding module) and you will see quite a few commits with "performance" in them. We have non-trivial applications using fastn that perform at extremely acceptable speed (hundreds of fields, with live validation, across multiple tabs, renders in around 150ms)
- My work PC is only a few times faster than my Nexus 5. Btw, the homepage renders in 1.2s(~500ms JS) on my phone.
I hope you do give it a go. Fastn isn't a tool for every job, that's the point, it's just a tool. It's up to the developer to decide if it is appropriate.
It has been developed mostly with cordova apps in mind (and yes, they have been made with it, and are quite snappy), where abandoning HTML is actually really nice. It makes writing apps more like how you would do it native, in code, not a markup language.
You sure about that? Because last I checked (and as I indicated in the linked comment), that's not actually true (at least not without some serious consideration from the app developer's side of things).
The rest of your comment, pleasantly-surprisingly, is good to hear (though I'm concerned that lower-end devices aren't getting enough attention; I know firsthand (from witnessing it with my coworkers and even with myself) how easy it is to assume that everyone has wonderful hardware and accidentally create something that readily bogs down hardware with even the slightest amount of age), and I do wish you the best of luck with this.
What are the advantages in comparison to virtual DOM based frameworks out there?