-
Am I the only one that found this somewhat weird to read because it frames what many (definitely I) consider the most sensible default way to build web applications as a novel experiment?
Relatively few user needs actually require the interactions that single page apps offer, and SPAs are, in my experience, far more costly to build and, especially, to maintain.
-
Why is no JavaScript a sensible default? 99% of users have JavaScript enabled, including mobile.
Sure, if you don’t need JS don’t use it. But the purist way of saying “I will NOT use JS, I will find difficult workarounds for things that would be easy in JS.” is ridiculous. It’s like designing a car with tank treads because you don’t like tires.
-
I avoided where possible for security, efficiency, and portability. Sandboxing a renderer doing HTML and CSS is so much easier than a Turing Complete language running malicious or inefficient code. All this extra complexity in web browsers has also reduced the market to mostly two or three of them. The simpler stuff can be handled by the budget browsers. Increases diversity of codebases and number of odd platforms that can use site/service. Finally, making the stuff simpler increases efficiency as you’re handling both less capabilities and less combinations of them. Easier to optimize.
So, the above are all the reasons I opposed the rise of JavaScript in favor of old-school DHTML where possible. Also, there were alternatives like Juice (Oberon) that were better. Worse is Better won out again, though. Now I limit the stuff mainly for security, predictability, and performance on cheap hardware.
-
the above are all the reasons I opposed the rise of JavaScript in favor of old-school DHTML where possible
Huh. Please correct me if I’m wrong, but my impression was that “DHTML” was a term created by Microsoft to describe websites that used HTML markup with a scripting language (like JavaScript or VBScript) to manipulate the DOM. They used it to market the capabilities of Internet Explorer.
-
I ran into it on sites that either used JavaScript mainly to enhance but not replace presentation layer or used CSS tricks. I know nothing of it term itsslf past that.
-
Ah, okay. I think I misunderstood what you meant by “the rise of JavaScript” - not its mere usage, but its increasing responsibilities in contemporary web development.
-
-
-
Isn’t css turing complete by now? :)
It is disappointing that if you make a browser from scratch as a hobby you have to add a javascript engine to be able to use the big 3 or 4 most popular social media sites.
Soon adding an SSL library will be a requirement for most sites. For serious browsers none of this is a real issue, it’s just kind of sad that a useful browser has a much larger minimum complexity now days.-
For serious browsers none of this is a real issue, it’s just kind of sad that a useful browser has a much larger minimum complexity now days.
That’s a big part of the reason I pushed for the simpler standards. Too much money and complexity going into stuff always ends up as an oligopoly. Those usually get corrupted by money at some point. So, the simpler browser engines would be easier to code up. Secure, extensible, cool browsers on language and platform combo of one’s choosing would be possible. Much diversity and competition would show up like the old days. This didn’t happen.
An example was the Lobo browser that was done in Java. Browsers were getting hit by memory-safety bugs all the time. One in Java dodges that while benefiting from its growing ecosystem. It supported a lot, too, but missing some key features as the complexity went up over time. (sighs) Heck, even a browser company with a new, safe language is currently building a prototype for learning instead of production. Even the domain experts can’t do a real one with small teams in reasonable time at this complexity level. That’s saying something.
-
-
-
It is profoundly easier to write useful acceptance tests for a static HTML versus a page with any amount of JavaScript. The former is a simple text-based protocol and the latter is a fractal API with a complex runtime and local state. That’s why no JS is a sensible default.
That doesn’t mean finding difficult workarounds to avoid JS at all costs. It means being clear about the downsides and coming up with the simplest strategy to mitigate them for your application.
-
-
-
I’ve taken little bits of this course over a few of its iterations (one when I was at Berkeley myself), and have to say I find it quite good.
Prof. Fox is a compelling lecturer — who, like me, speaks like he’s mainlining coffee — and the material strikes a great balance of practical Rails knowledge and (more importantly) the agile practices (TDD, BDD, legacy refactoring) that Rails simply makes easy to do, and which are incredibly valuable agnostic on the particular web framework one is using.
-
Trying to wrangle Selenium as my integration point for a service serving low-income clients. Boy, can web driving be flaky.
I also found this further discussion of the root issue by Laurie Voss compelling: https://lobste.rs/s/crhr7d/web_development_has_two_flavors_graceful