I remember reading javascript for the first time some years ago. It was hate at first sight. Why are there so many ways to write the same thing? Why is this forsaken language so horrible to read? Compiler support? Type system? Debugging tools? Someone needs to clean up this mess. As long as javascript is the dominant web client programming language, the browser will continue to be the platform of the future, but never the present.
Rich client side web apps gone too far (2014)
31–40 of 58 posts
Re: Rich client side web apps gone too far (2014)
#32I have complained about similar things way too much on twitter as well. A VAST majority of websites on the web serve CONTENT. Why is JavaScript needed to serve content is really beyond me. You don't need to make your blog look and feel more webapp-y. It's a blog post. I want to read content. I don't use other features on your blog. Please just serve me the content and don't try to SPA that shit. Heck, I'd be willing…
Airbnb has tons of things that would be impossible (or annoying to use) without JS: search by map, sliders, availability calendars, price calculation, credit card tokenization, etc. Here is a recent talk where they explain how they solved some tricky UX problem by using a "modern" JS framework such as React.js http://www.infoq.com/presentations/airbnb-resolution-center In this other talk they also explain how (and wh…
Fair enough. Those features do indeed warrant the use JavaScript. Not quite convinced that it needs to be super bloated JS, but since I've somehow managed to miss all those features, I must be missing something. Thanks for educating :)
Re: Rich client side web apps gone too far (2014)
#33His criticisms of Javascript are, of course, correct. It's a huge mark of shame for the technical community that we've allowed this language to "win". Bafflingly, people who even suggest that the hacks-upon-hacks we've had to use for even basic software engineering techniques like namespacing are just that, hacks, routinely get shouted down. The whole thing will make an interesting sociological study at some point. F…
> I know I've been asked to cool it on the pimping, but this is exactly what intercooler.js is designed for: you don't need to write much javascript for the dynamic behavior you want 99% of the time.
JavaScript is a clusterfuck. More Javascript is not the answer.
Re: Rich client side web apps gone too far (2014)
#34His criticisms of Javascript are, of course, correct. It's a huge mark of shame for the technical community that we've allowed this language to "win". Bafflingly, people who even suggest that the hacks-upon-hacks we've had to use for even basic software engineering techniques like namespacing are just that, hacks, routinely get shouted down. The whole thing will make an interesting sociological study at some point. F…
> I know I've been asked to cool it on the pimping, but this is exactly what intercooler.js is designed for: you don't need to write much javascript for the dynamic behavior you want 99% of the time. JavaScript is a clusterfuck. More Javascript is not the answer.
Which is exactly why intercooler.js uses plain HTML attributes, rather than javascript:
Re: Rich client side web apps gone too far (2014)
#35> The basic idea is that your app should be fully functional even if Javascript is disabled.
Honest question, is this really possible? I write webapps and Javascript + Jquery makes a lot of stuff easy, hooking into button clicks, getting text from an input box and sending AJAX requests back to my server.
Does anyone have an example of a web application with no Javascript? My next project will most likely use Golang as the server side, and I'm having a really hard time imagining how to send AJAX requests back to the server on user events (such as the user typing into a box in a real time search application) without using Javascript.
Apparently I've missed a whole area of web development if this is all possible with no Javascript. Isn't this like saying your Windows game should be fully functional without a graphics card?
I mean, on most web applications, they are that, applications. Maybe I just don't know enough, but I feel like I need a programming language in the browser to create the client side of the application, how do I fire off AJAX events when a user types something without Javascript?
I'm honestly trying to learn more here, I need examples of web apps with no Javascript, I need a book or something. Just being told I can replicate my application in html and css isn't helping.
Re: Rich client side web apps gone too far (2014)
#36I have complained about similar things way too much on twitter as well. A VAST majority of websites on the web serve CONTENT. Why is JavaScript needed to serve content is really beyond me. You don't need to make your blog look and feel more webapp-y. It's a blog post. I want to read content. I don't use other features on your blog. Please just serve me the content and don't try to SPA that shit. Heck, I'd be willing…
The game played on web development is that javascript is used to make for deficiencies in the basic functionality of browsers - both bad implementation of web standards as well as functionality missing from the standards. Developers would be much better of if web browsers provided a high-quality, full featured experience to create web applications/sites. Of course, this is not easy to do, especially when there are several browsers competing for the same market. As long as this happens, javascript will be aways be used to provide the extra functionality that is needed, even on content-only web sites.
Re: Rich client side web apps gone too far (2014)
#37There's so much frontend jobs now that as much as I hate it and no it's wrong, I am forced to learn it to keep up.
There's just no choice. The stakeholders have decided suddenly JS is the new way to write apps, these type of people won't know how to code if you put a gun to their heads, even worse are developers refusing to use conventional tools like PHP or Python or Ruby for writing server backends.
I've never forced JS or SPA on someone that had no place for it but unfortunately they are willing to pay more to have it rewritten in JS.
Re: Rich client side web apps gone too far (2014)
#38Earlier quoted context omitted.
> I know I've been asked to cool it on the pimping, but this is exactly what intercooler.js is designed for: you don't need to write much javascript for the dynamic behavior you want 99% of the time. JavaScript is a clusterfuck. More Javascript is not the answer.
Which is exactly why intercooler.js uses plain HTML attributes, rather than javascript: http://intercoolerjs.org/
very cool! although I feel more comfortable with using jQuery for posting.
Re: Rich client side web apps gone too far (2014)
#39> The basic idea is that your app should be fully functional even if Javascript is disabled. Honest question, is this really possible? I write webapps and Javascript + Jquery makes a lot of stuff easy, hooking into button clicks, getting text from an input box and sending AJAX requests back to my server. Does anyone have an example of a web application with no Javascript? My next project will most likely use Golang a…
> Honest question, is this really possible?
Yes, loads of things work without JS. You can use Wikipedia, even to edit articles, with JS disabled – it's all simple HTML forms. JS just makes the experience smoother (adding buttons to help with WikiText formatting, etc).
Most content and shopping websites work fine without JS. You asked how do you fire off AJAX requests without JS? You don't. You just design your app so it basically works as a set of HTML pages connected by hyperlinks and form submissions. Then you add JS to enhance things.
> Apparently I've missed a whole area of web development if this is all possible with no Javascript.
Yes you have. When I started (~12 years ago), JS was only used for little whizzy effects here and there, not much else. Then JS started becoming more viable due to prototype and jQuery, but it was always the most flakey part of web development, and we learned to use it cautiously as an optional layer of enhancement. You couldn't rely on it always working. It was a way to 'differentiate' your site, not a serious building block.
Now, everything has changed, JS is everywhere and we tend to call things 'apps' more than 'sites'. I spend 70% of my day writing JS. I'm not sure if I agree with the JS-bashing sentiment of the article. But I do think it's still good practice to design your app so it delivers your core content/functionality without JS. Most stuff (blogs, e-commerce, forums, etc) can be built like this. (Admittedly some things like p2p streaming apps just can't.) Then you can use JS to enhance things, like enhancing your basic search form with as-you-type suggestions. This approach makes your codebase more structurally sound and less entangled, and makes your app more resilient.
Re: Rich client side web apps gone too far (2014)
#40> The basic idea is that your app should be fully functional even if Javascript is disabled. Honest question, is this really possible? I write webapps and Javascript + Jquery makes a lot of stuff easy, hooking into button clicks, getting text from an input box and sending AJAX requests back to my server. Does anyone have an example of a web application with no Javascript? My next project will most likely use Golang a…
"is this really possible?"
Well, sure.. of course it is possible, just a lot more work because the divide between having logic on the client and no logic on the client is quite big thus you often end up needing to solve problems in two ways (and these differences can permeate various layers of the app) and then commit to maintaining both.
"such as the user typing into a box in a real time search application"
Well you could always just not support real-time search if JavaScript is not enabled. The argument that JavaScript should be optional for all sites sort of pre-assumes that the experience when running sans JavaScript will be different, but you'll be able to get the same things done. In this one specific situation the difference being that you won't get any search feedback until you actually submit the form, old-school web style.