6 ms·
Yes, the ability to write code once that runs on either your server or the client is amazing, something Fog Creek implemented in Wasabi. But as JavaScript matu
by jonnytran 18y ago
Yes, the ability to write code once that runs on either your server or the client is amazing, something Fog Creek implemented in Wasabi. But as JavaScript matures, it makes you start to wonder why you even bother with HTML at all; you can simply dynamically generate DOM nodes in JavaScript. And once you start doing this, most of the things you wanted to do running code on both client and server disappear.
- jshen 18y ago"But as JavaScript matures, it makes you start to wonder why you even bother with HTML at all; you can simply dynamically generate DOM nodes in JavaScript." SEO
- jerf 18y agoOh! So that's why Google is developing a speedy JS interpreter... they want to be able to see JS-based pages! They can load a page into a browser-with-no-graphics, and give the JS a certain amount of time to run before freezing the page and then reading off the DOM nodes instead of reading HTML. If they don't like the results, they can just use the HTML like they used to. (Reading off the DOM nodes also gives them a fresh crack at some more semantic analysis that used to be really hard, since it involved emulating a browser... did you use <span class="some_header"> instead of <h1>? They can make a better heuristic guess at that if they are "inside" a browser and thus capable of seeing that the size is twenty points higher than the surrounding text, no matter how you implemented that.) To really pull this off, you need a browser engine that enough people are using that site designers need to account for it, and it needs to be designed with the goal of running just the engine as quickly as possible on the backend, with the ability to cut it off after a certain amount of time. So... has anybody dug deeply enough into Chrome to have an opinion on the feasibility of running the browser without a UI?
- jshen 18y agoI'm not sure what your point is. Is your point that we shouldn't worry about rendering pages with JS because someday in the future google will be able to index it equally well? If so your livelyhood clearly doesn't depend on SEO. I'm not gambling mine on what is currently vaporware. Btw, people made this exact point about flash a few years ago and your pages will not rank nearly as well if you do them in flash.
- jerf 18y agoI think my point was pretty adequately captured by "So that's why Google is developing a speedy JS interpreter", although I have done you the favor of re-emphasizing the subject for you. I don't care about SEO. I think Google wants to see into those sites, and I don't think they much care about SEO either.
- jshen 18y agoI still don't see what your point is. Something like, "google doesn't care about SEO therefore site s that do should use javascript frameworks instead of static html" or something?
- jonnytran 18y agoShould the ability of search engines to index something determine whether or not you do it? I understand SEO is a practical necessity, but in the grand scheme of things, it sounds like putting the cart before the horse.
- jshen 18y ago"Should the ability of search engines to index something determine whether or not you do it?" If your goal is to make money then yes it should if organic search traffic is a big piece of your marketing puzzle. It's not the cart before the horse if your intention is to run a business on the internet. I've been a big part of a few successful businesses that depended on SEO. Without it they would not have succeeded.
- lacker 18y agoI like the strategy of ditching HTML for Javascript. But it doesn't replace running code on both client and server. Consider writing something like Gmail, or even just its chat client. You are going to need lots of code that handles connections, communicating when they are unavailable, taking a connection as an argument to some sort of function, et cetera. Wouldn't it be convenient if all of that communication code was the same for client and server? If you're still using javascript and a separate server-side language, you have to write two sets of code to handle any data structure you want to pass between client and server.
- jonnytran 18y agoIt doesn't replace running all code on both client and server, but for certain use cases it does. For example, you have a blog post with comments and a form that allows you to post new comments. When a person visits the page, the HTML of all current comments is loaded. The code to generate that HTML is on the server. But say that you want the interface to be very responsive, and when someone posts a new comment, you want to be able to display that comment in the list with others w/o waiting for the response from the server. Ideally the same code that generated the HTML for the original list can be used to generate the HTML for this new comment -- but on the client. (Of course, to actually store the new comment, you need server side code, which I'm not saying it will eliminate at all.)