4 ms·

Yes, we thought this in early 2005 and created NOLOH (http://www.noloh.com http://www.noloh.com) as a solution. You write your app in a single tier, rather than

by asnyder 16y ago

Yes, we thought this in early 2005 and created NOLOH (http://www.noloh.com http://www.noloh.com) as a solution. You write your app in a single tier, rather than having to worry about all the plumbing (Cross-browser issues, AJAX, client-server interaction, Comet, etc). You can even use your existing HTML, JS, CSS, if you like, and NOLOH then renders a version of your app targeted specifically towards the end user, whether it's IE, Chrome, Mac, Windows, etc. or a search engine robot, in a "lightweight" (only the correct and highly optimized code is loaded for a specific user) and "On-demand" (only loads the resources that are absolutely necessary at a given point) manner, thus allowing for rich web apps like gmail, to load instantly, and as needed, rather than a traditional web fat-client. Every few months someone will write a post like this, and I wince. We've written several extensive articles for php|architect magazine and have presented NOLOH at several major web development conferences around the world. The fact of the matter is that tools like NOLOH exist, there are others, and they can be used now. Today, web development doesn't need to suck. If you're interested in the specifics of the above stated "lightweight" and "On-demand", specifics can be found in the article "Lightweight, On-demand, and Beyond" in http://www.phparch.com/magazine/2010-2/november/ http://www.phparch.com/magazine/2010-2/november/. [edit] Link to free December issue of php|architect article "NOLOH's Notables" so that you can more easily see what I mean without the November issue paywall. http://beta.phparch.com/wp-content/uploads/2010/12/PHPA-DEC-12-noloh.pdf http://beta.phparch.com/wp-content/uploads/2010/12/PHPA-DEC-... Disclaimer: I'm a co-founder of NOLOH

klochner 16y ago
Your site doesn't work with javascript disabled.
- asnyder 16y ago
  It does, but it's not ideal. Remember, it's important to separate noloh.com, from NOLOH the tool's capabilities. The decisions we made regarding noloh.com, in no way reflects the capabilities of NOLOH. In a NOLOH application or website, you decide to what extent your content will display without JavaScript, granted we should enable more options, but without JavaScript the site and content still loads and those users can still peruse your content, but not perfectly. However, if you pretend to be a search engine, you'll see they get a completely different version of the website, with generated links, different than the JavaScript disabled version. It boils down to each end user type getting a different version, JavaScript is ideal, non-Javascript works, but is not ideal, which is something we continue to work on, and search engine robots which is completely different from the others, conforming to standards, etc., see http://dev.noloh.com/#/blog/2010/08/23/strict-output-and-other-seo-improvements/ http://dev.noloh.com/#/blog/2010/08/23/strict-output-and-oth....
rufugee 16y ago
Have you considered that you could potentially make a lot more by open sourcing NOLOH and building a support infrastructure around it? It seems like the closed source aspect of it might be holding you back. If NOLOH truly is the Rails of the future, it might be wise to unleash it. I've always thought this was part of what kept REBOL from catching on. Nice little language, but its closed nature hampered its adoption.
- asnyder 16y ago
  We have. The problem of course stems from the more established brands picking apart our tech and incorporating it into their own, thus making our tech obsolete. There's also the issue regarding our existing customers that paid for Professional and Enterprise licenses. We currently offer free licenses to open source projects, but we do understand that there are those that are turned off to any proprietary tech, even if they'll never actually go under the covers. We'll likely revisit this issue later in the year after we make a series of major product announcements. Those announcments may make it unnecessary for the tech to continue to be closed, until then, everything we do other than the core is open source and available on github, this includes numerous modules. I'll likely blog about this in the next month or so.

by asnyder 16y ago

klochner 16y ago

Your site doesn't work with javascript disabled.

asnyder 16y ago
It does, but it's not ideal. Remember, it's important to separate noloh.com, from NOLOH the tool's capabilities. The decisions we made regarding noloh.com, in no way reflects the capabilities of NOLOH. In a NOLOH application or website, you decide to what extent your content will display without JavaScript, granted we should enable more options, but without JavaScript the site and content still loads and those users can still peruse your content, but not perfectly. However, if you pretend to be a search engine, you'll see they get a completely different version of the website, with generated links, different than the JavaScript disabled version. It boils down to each end user type getting a different version, JavaScript is ideal, non-Javascript works, but is not ideal, which is something we continue to work on, and search engine robots which is completely different from the others, conforming to standards, etc., see http://dev.noloh.com/#/blog/2010/08/23/strict-output-and-other-seo-improvements/ http://dev.noloh.com/#/blog/2010/08/23/strict-output-and-oth....

rufugee 16y ago

Have you considered that you could potentially make a lot more by open sourcing NOLOH and building a support infrastructure around it? It seems like the closed source aspect of it might be holding you back. If NOLOH truly is the Rails of the future, it might be wise to unleash it. I've always thought this was part of what kept REBOL from catching on. Nice little language, but its closed nature hampered its adoption.

asnyder 16y ago
We have. The problem of course stems from the more established brands picking apart our tech and incorporating it into their own, thus making our tech obsolete. There's also the issue regarding our existing customers that paid for Professional and Enterprise licenses. We currently offer free licenses to open source projects, but we do understand that there are those that are turned off to any proprietary tech, even if they'll never actually go under the covers. We'll likely revisit this issue later in the year after we make a series of major product announcements. Those announcments may make it unnecessary for the tech to continue to be closed, until then, everything we do other than the core is open source and available on github, this includes numerous modules. I'll likely blog about this in the next month or so.