5 ms·
For a while I worked on and made use of a very lightweight JS framework that would essentially do two things: * Intercept link clicks and form submissions and
by Smudge 10y ago
For a while I worked on and made use of a very lightweight JS framework that would essentially do two things:
* Intercept link clicks and form submissions and perform the exact same request asynchronously (AJAX)
* Wait for the server to respond with the parts of the page that need to be swapped-out (a JSON map of section IDs to plain HTML content) and, as expected, swap out those parts of the page.
This works REALLY well for, like, 80% of my use cases. With a little extra flavor functionality (such as automatic loading indicators and event listeners) I can enable like 90% of interactivity. The remaining 10% consists of things that affect only temporary state and don't require a server round-trip (e.g. a "select all" checkbox), and those I would handle with more traditional jQuery DOM manipulation.
For the most part, once I had this basic system in place, I could rely on the server to render (and re-render) all of the HTML and rarely had to write any custom Javascript. I was essentially relying on the behavior of vanilla links and forms. The site would even continue to function if you disabled Javascript, because the server would see that it wasn't AJAX and just render the whole page instead. The downside was that preserving local state (e.g. partially completed form fields) was tricky whenever I had to make a change to one of its parent containers.
Everything I learned about this approach eventually led me to appreciate what React.js is doing. I've been using it and I may not like all of its API or how heavy it feels overall, but the cycle of rendering and re-rendering different parts of the page feels very natural and is far easier to debug than most JS-heavy front-ends.
- gkya 10y agoWhy just don't let the hyperlinks do what they are supposed to do, which is what you do at the end of the day anyways, then? When I approach a link, I hover, see the href on the status bar, think and decide, and click. Thereafter, I expect it to take me somewhere else, while the browser pushes the url of the page I left into a stack, the history. This implemented and working in my browser already, why redo it with JS? To lower the load time? Then don't make the page multi-meg already, no? The ugly thing is govt websites and such are adopting a similar style of web app design, relying upon wizardy and tricks and hacks, for example, I sweat blood when I use my uni's web pages because I'll hit a bug in the js for an already-there popup or a button and it'll hurt my educational career.
- TeMPOraL 10y agoThe truth is, it's all because most websites are really ads, and they have to follow the fashion - otherwise you risk sending a message that your company or project is bad in some way. Web is a fashion-driven industry and any usability or ergonomics is not even a secondary consideration.
- gkya 10y agoI made a website for my uncle's tile business. Real, international business with an office in the UK. I made it with ~180 lines of CSS, ~30 lines of JS ~20 lines of GNU (1) m4, and 60 lines of make. Got positive impressions from everybody he works with and probably improved our sales. External JS included, the WHOLE website source weighs in at 150 kb without images, with multiple pages, a gallery with a lightbox and on a proper grid (github.com/ThisIsDallas/simplegrid), a custom Google Maps map via the API, a carousel, and a consistent colour scheme, all done in an afternoon. And once compiled, the product weighs less than the source. I guess the problem is nowadays the designer folk gets to say too much on the development of websites and web standards. There is no prerequisite to become one. If you didn't study CS in depth, at the uni or by yourself, you can't do embedded, OS dev, etc., but mashing together some stuff from Github you become a web designer, no qualifications needed. Here we have a website that talks about bloat and lists nine or ten tools that have well established, better, more generic counterparts. Generating a file from another via a filter program (minifier, m4, awk, coffeescript compiler...) is what make excells at. Replacing strings is what m4, awk and sed do since 1980's. We don't expect from the designer folk to know anything about the basics of computing. And they spend their time duplicating and triplicating and quadruplicating effort spent decades ago to end up doing the same thing, only worse, and when it comes to actual work, all they do is mix and match some libraries and add bloat after bloat, instead of looking to see what needs to be done, and doing it, using the tools already available and fit. (1) Otherwise I'd have to implement a foreach macro, which would take some 10 lines more.
- Keats 10y agoI'm not sure I understand why designers should know CS. Most of them spend their time in Photoshop/Sketch, not programming. Unless I misunderstand. Also from your other comment you would like Ajax to not be used in websites?
- davidjnelson 10y agoSounds like you are describing pjax. Ya, that's the big idea with react, single page apps with the mental model of "render everything all at once", like we did with old school late 90s/early 2000s web apps.
- xaduha 10y agoEarly 2000s I believe, late 90s - nope.
- davidjnelson 10y agoOh, I didn't mean pjax was used in the late 90's if that's what you thought I meant. I meant that we did all rendering server side, because there was no xhr :-)
- kingkool68 10y agoGood job Smudge. I found a similar technique quite helpful. The only difference is instead of asking the server for a partial I just download the entire HTML source and query it for the parts I need and inject those parts into the DOM. Super helpful for zippy photo galleries or infinite scroll.
- triskweline 10y agoThe framework you're subscribing sounds a little like Unpoly [1]. [1]: http://unpoly.com/ http://unpoly.com/
- aregsarkissian 10y agoIntercoolerjs is another framework that does similar things