Am I the only one that kind of thinks most websites should just be static pages? Like, I get pretty irritated when I go to read a blog post on Medium or wherever and it loads a header and a blank page, and then loads a bunch of javascript (mostly tracking and analytics frameworks), and finally goes out and gets the actual content. And then if I scroll down, it has to load some more garbage from Disqus or something. P…
The internet isn't all blogs. The use cases for React are kind of for the interesting web applications. Or even unity games with coherent ui.
Am I the only one that kind of thinks most websites should just be static pages? Like, I get pretty irritated when I go to read a blog post on Medium or wherever and it loads a header and a blank page, and then loads a bunch of javascript (mostly tracking and analytics frameworks), and finally goes out and gets the actual content. And then if I scroll down, it has to load some more garbage from Disqus or something. P…
>Am I the only one that kind of thinks most websites should just be static pages? No, the majority of people agree. And contrary to what javascript happy dumbasses keep repeating, the majority of new development is absolutely not doing everything client side. It is sad that the web is so fad driven, but this stupid fad will pass just like flash intros and spinning under construction animated gifs.
As long as enterprise continues to shift to a no-install web application based IT infrastructure, fad driven client based "web dev" will continue to increase in frequency and prominence. If (when?) people realize that the browser actually can't do everything this might change, but I wouldn't hold my breath. It's too easy to save a buck now by minimizing application development and support costs (browser-based web app…
This is ridiculous. Building business applications as web applications have many advantages such as portability, network accessibility, speed of development, ease of development, speed. Over native apps. The sheer fact that you can hand off processing to the server and not block your entire ui makes the majority of web apps far better than the majority of poorly coded win forms garbage I've used.
I get your gripe, but there's a good use case for this stuff in building dynamic web applications . Just because a technology is misused doesn't mean the technology is to blame.
Browsers aren't general purpose applications. They can't fill every application role on the computer. The more "web dev" tries to push them in that direction, the slower, more difficult to develop and maintain, and generally poor they will be, and then the "dynamic web applications" that run on them will suffer.
What, for instance? Your comments seem heavy on condemnation but light on substance. Sure there are certain donation specific tools such as Photoshop or 3dsmax or ableton etc that wouldn't work in the browser, but for your day to day business 99% application, the user generally does not need to do anything that the browser cannot.
The fact is, the web world is evolving at an extremely fast rate, and leaving the native world in the dust.
Not all use cases are equal. Static pages might work great for static content, but what about something like GitHub? Wouldn't it be nice to see the issues list refresh live when somebody else closes one?
What are the cases for that feed role? Why not deliver an RSS/Atom feed with the page and a standard feed reader within HTML that could present the content, polling at specified intervals. In the same way that HTML finally standardized on HTML5 semantic page markup (not that HTML1.0 was grossly inadequate), and we're finally getting integrated video / multimedia support (though lacking the ever crucial "off" switch),…
With the amount of inane FUD you're spreading I can't work out if you're genuine or a troll. Your text only/image minimal feed reader is using less RAM than a browser designed to load hundreds of images and get the most out of the RAM available to it? Shock and horror! And this "train wreck" you're referring to... I don't see it. I see happy clients that can pay once and get an application that is useable on any platform, from anywhere in the world, is as fast as a native application, and can be seamlessly scaled up to meet demand. Where is the downside in that? Game over, purely native apps, you lost the war (except for specific things that need to operate locally). Sure there are native phone applications, but they are essentially thin clients for web applications anyway.
I would be interested to know what exactly React solves when we already have so many options - Ember, Angular, Backbone to do the same thing. Why would one want to increase the complexity of the application by introducing "yet another new thing" on an already complex architecture. I am just not sold on React. If someone could show a demo of why should we use React instead of, Backbone.View for example, then we can ta…
I'm just reading about React now, but it seems it might be appropriate when you have a lot of stuff that needs to be reused Then again, Knockout would also be pretty good at this, so I dunno. There are a lot of criteria for evaluating a framework... development speed, maintainability, simplicity, functionality. And a lot of it is better evaluated experientially rather than theoretically.
Knockout.js is slow. React seems fast thanks to their virtual DOM. It matters when you want to develop a web app that caters for mobile clients too.
Am I the only one that kind of thinks most websites should just be static pages? Like, I get pretty irritated when I go to read a blog post on Medium or wherever and it loads a header and a blank page, and then loads a bunch of javascript (mostly tracking and analytics frameworks), and finally goes out and gets the actual content. And then if I scroll down, it has to load some more garbage from Disqus or something. P…
IMHO this is a bacon-salad problem:
Add some bacon (js) to your salad and you have a healthy and balanced meal.
make a "salad" out of bacon and and mayo dressing and you have a problem.
I still don't get it that you would like to write in an inferior language such as js on the server side. Cm'on its broken by design. There are a lot of better alternatives.
The only reason to use .js on the serverside is that you don't know better.
Am I the only one that kind of thinks most websites should just be static pages? Like, I get pretty irritated when I go to read a blog post on Medium or wherever and it loads a header and a blank page, and then loads a bunch of javascript (mostly tracking and analytics frameworks), and finally goes out and gets the actual content. And then if I scroll down, it has to load some more garbage from Disqus or something. P…
>Am I the only one that kind of thinks most websites should just be static pages? No, the majority of people agree. And contrary to what javascript happy dumbasses keep repeating, the majority of new development is absolutely not doing everything client side. It is sad that the web is so fad driven, but this stupid fad will pass just like flash intros and spinning under construction animated gifs.
Building an application by rendering static webpages is just a horrible cludge. How did we even get here? How are we still even considering that the godawful turd that is string concatenation of DOM descriptors polished by a layer of templating languages is actually a decent way of writing applications?
Do you seriously believe this?
The virtual DOM is probably the biggest elephant in the room. It begs the question: why the hell isn't the REAL DOM like that?