I can not sort by prize on the airbnb listings?
Also I do not want to see the map, but can not find a way to disable the map.
Isomorphic JavaScript: The Future of Web Apps
101–110 of 123 posts
Re: Isomorphic JavaScript: The Future of Web Apps
#102You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!
I wish I could filter out totally uninteresting threads in HN website that are disturbing my reading experience - is there any CSS hack / tool that adds a "don´t show this thread" button to HN discussion threads?
Re: Isomorphic JavaScript: The Future of Web Apps
#103You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!
I think it might be some kind of parody on "angular".
Re: Isomorphic JavaScript: The Future of Web Apps
#104A great thing about the web is that a multitude of server side languages can be used. While I don't ever want to have to write the same template twice, having everything converge on nothing but Javascript doesn't seem like a very inspiring future to me.
If you are building a service or API, then you can do that in whatever language you like. The natural language for writing client side apps is JS (ok, the only language, for now).
A couple alternatives are there:
Re: Isomorphic JavaScript: The Future of Web Apps
#105Earlier quoted context omitted.
(author) Cool! What's the JavaScript runtime on the server? Something JVM-based?
The server code is still Java, but our template language ( https://developers.google.com/closure/templates/ ) compiles to both JS and Java.
The benefits of sharing the templates on both client and server, but with a more robust backend technology. This sounds interesting to me.
Re: Isomorphic JavaScript: The Future of Web Apps
#106You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!
Agreed. I like "Nomadic JavaScript" better! Or "Unbound JavaScript". Or "Bicoastal JavaScript". Or maybe "Freebased JavaScript". Anything else.
Freewheelin' JavaScript
Re: Isomorphic JavaScript: The Future of Web Apps
#107Wasn't this the idea with GWT so many years ago? In GWT's case, it was Java on both sides. I don't believe that it solves the problem and I don't believe Javascript on both sides will solve the problem. This is a classic "impedance mismatch" like O/R mapping. At the end of the day, there may be no good, i.e. simple, solution. It is inherently difficult and messy.
GWT is not Java on both sides. Its Java on the server, Javascript on the client. The Java client side code compiles to Javascript...the abstraction is way greater than what OP is presenting. (JS & JS) GWT is/was a terrible amount of overhead baggage, but had some brilliant event systems and DOM tricks for its day.
'For its day'? GWT lives in many forms, most notably Vaadin:
Vaadin is consistently rated one of the best web app frameworks. Why its not more widely known is beyond me.
Re: Isomorphic JavaScript: The Future of Web Apps
#108I've considered doing exactly this (using Node.js) based on the same paradigm as the Unreal Engine. Epic devised a very effective way to code for both a client and server at once within the same class(es), where server->client, client->server, and other types of replication are as easy and intuitive as anything else. I think it would be perfect for real-time web applications where multiple users interact with each other at the same time. I'd advise anyone interested in these ideas to check out how the Unreal Engine does it.
Edit - A couple of unofficial but useful links:
http://wiki.beyondunreal.com/Introduction_to_replication
http://wiki.beyondunreal.com/Legacy:Replication_De-Obfuscati...
Re: Isomorphic JavaScript: The Future of Web Apps
#109Earlier quoted context omitted.
but who writes clientside logic before serverside logic ?
Front-end developers. Frankly, Node is a way for front-end developers to write server-side code without having to learn too much new stuff.
No. Any thick client architecture has to deal with this problem. The current resource-oriented models (by which I mean they're focused on serving http resources) are severely limiting those of us who want to develop a web application.
Some people are side-stepping the issue by saying that the whole presentation layer must be moved to the front-end, but that approach is really incompatible with the web.
If anything, the current state of the front-end is thanks to server-side developers who want to bring their world view to the browser. (Think: MVC -> Backbone / Ruby -> Coffeescript -- apologies to the authors of those tools)
Re: Isomorphic JavaScript: The Future of Web Apps
#110Wasn't this the idea with GWT so many years ago? In GWT's case, it was Java on both sides. I don't believe that it solves the problem and I don't believe Javascript on both sides will solve the problem. This is a classic "impedance mismatch" like O/R mapping. At the end of the day, there may be no good, i.e. simple, solution. It is inherently difficult and messy.
GWT is not Java on both sides. Its Java on the server, Javascript on the client. The Java client side code compiles to Javascript...the abstraction is way greater than what OP is presenting. (JS & JS) GWT is/was a terrible amount of overhead baggage, but had some brilliant event systems and DOM tricks for its day.
> GWT is/was a terrible amount of overhead baggage
GWT is very much alive and kicking, but it's primarily used on internal business applications with large and complex code bases. And what overhead baggage are you talking about? GWT is designed to reduce overhead though cross-compiled, browser-spesific builds, dead-code removal, and js-optimizing.