If we're not allowed to have rich client applications anymore, JavaScript is pretty much the only tool to make a browser act like a rich client...
The browser has become a rich/fat-client, it just sucks at it because it wasn't originally designed for it, and hacked up over time to fake it.
For "productivity" applications (brochure-ware excluded), desktop UI idioms are still preferred. But we have to bend over backward to get HTML-browser/DOM to act like a (non-fucked-up) desktop, with lots of blood, sweat, tears. It's ugly compared to desktop/CRUD development in say Delphi, Powerbuilder, etc.
What's needed is a new GUI-friendly standard that works decently over HTTP/HTTPS. We should take the best lessons from Java applets, Flash, X-Windows etc., discard the worse parts, and try to get a real GUI standard for once.
Some suggestions:
* Do most of the positioning calculations on the server side to avoid complex "flow" calculations on the client (which end up varying too much per browser brand/version). Perhaps put the "flow engine" on the server and have the client merely render "dumb" vectors as coordinates (pixels or panel percents). The client sends its screen size preferences to the server rather than let the client-side do the "fit" calcs on the browser (client).
* Allow font sizing with a maximum containment box such that fonts are rendered smaller if necessary (at least on the X axis) in order to guarantee a fit in a designated containment box. Overlapping element errors are common in CSS/JS-centric frameworks, largely because testers don't test in a wide enough variety of clients/versions/OS-DPI settings.
* Don't make the client an OS or OS-like thing. This is largely Java's mistake: they bit off more than they could chew. Focus on GUI's and KISS. Most the app activity should be on the server.
* Allow flexible "skinning" to keep up with style Joneses. You have to keep up with the look styles to not get ignored, unfortunately. (I have some ideas for graphic (image) background skinning that are flexible but relatively simple that allow changing the visual styles without breaking the complexity bank.)
* Allow optional client-side scripting, but try not to over-do reliance on it. If a UI pattern(s) emerges, then build that pattern into the standard.
Actually it shouldn't matter much except at the validation stage. Much of typical CRUD programming is just marshaling around rows and fields rather than computations on those fields. If each marshaling stage has to know the type, then you violate DRY by replicating schema info to check at each stage.
I suspect the real killer feature of Node.js for people coming from Java and C# is the development cycle. Edit, save, hit F5 in the browser. Despite everything ugly about Javascript, that's handy.
So it's like PHP, Perl, and ASP-Classic: interpreted. New is old again and old is new again. I'm getting my bell-bottom jeans out...or did they already come-and-go again, I forgot.
MVC was "invented" for client/server systems, if I'm not mistaking, or at least used heavily for client/server before moving to web. Thus, its association with web-ness is weak at best.
It is about DB access, and automatic mapping of an OO language's objects into a relational data base.
And when they don't fit each other, it often creates a mess in performance and/or code. Relational is mostly set-based, and objects are mostly hierarchy-based: these two philosophies don't always jive well.
Sure, if you are skilled enough, you can manage the work-arounds well, but that's true of anything: If you know assembler well enough, you can potentially program circles around the high-level-language people. And I've seen some really productive COBOLers, for example because they knew the language and shop conventions like the back of their hands.
ALL the telecom oligopolies suck puss-filled maggots. Jail all the f#cking bastards! As far as AT&T, they have telespammed me approximately 50 times in the last 2 years. They only stopped when I started answering with Trump impressions. And I won't even start on their screwy billing practices. We were forced to use some of their services because the other choice sucks more. We are in a relatively big town, but our choices are strangely limited.
Didn't Apple try to trademark rounded corners? Thus if you made a yellow box with rounded corners, you'd get sued by two conglomerates. Put one button on it and Amazon would also join the party.
Re unreliable flesh drivers: rationally I agree with you, but part of me wants to see it road tested by actual riders for a couple of years. There are people who cannot drive for various reasons who want to be able to get around and will accept some risk to do so. These will be the "pioneers" or "guinea-pigs", depending on your perspective. They are doing us all a favor by helping the bot-car co's get the kinks out.
As far as being outright stuck when the software gets confused or crashes, I would hope the car co. will make it easy to fetch a taxi or Uber ride on their dime. Bleep happens. Even with regular cars, I've been 90 minutes or more late to work several times when there were nasty accidents (clogging routes), bad weather, flat tires, dead batteries, etc. If your career depends on arriving on time all the time, then bot-cars are not for you, but many job are not quite that tight. And retirees don't have such worries.
By the same argument, butt sex is better because everybody can participate...Javascript is a shitty language...
+5 analogy for "one language for entire stack" argument! Kudos & LOL.
While I do have many qualms about JavaScript (JS), a bigger problem is that different kinds of languages better fit different needs. JS is okay as a light-weight glue language, but should NOT be used to write lower-level API's and services that need a compiled/strong-typed (CST) language for performance and the safety of type-checking.
Low-level components/layers that higher levels such as app-specific logic rely on should generally be CST. If you think of applications as an onion with OS, compiler/interpreter and databases being the core, middle-ware libraries the middle layers, and application business logic the outer layers, then the closer to the core you are, the more "anal" the language you need for speed and reliability, thus CST. JS is best for the outer layers where too bureaucratic of a language slows progress, especially in-house apps for non-key tasks that wont kill anybody if they break. I doubt there will ever be a one-size-fits-all language.
(Although, others and I have kicked around the idea of a language that can be strong and weak typed based on configuration switches that can be applied to the entire application or a specific module, and specific parameters can be still be verified as requested. It's almost comparable to using the type "object" in C# by default if weak mode is on, but without the need to actually state "object". Another approach is "soft compilation", but that would take a long time to explain. Also, I realize there are existing interpreted strong-typed languages, but for various reasons that combo has not been successful.)
Ruby was in the same position not that long ago, I wonder how many now legacy ruby apps people regret writing.
Fad sniffers, that's why. I'm going into my get-off-my-lawn mode here, if you don't mind.
Tech companies and consultants profit off of change, and so encourage it, whether it's the right decision or not for a particular project. When technology stagnates (becomes stable), people figure everything out, and fixing and changing becomes routine and commoditized such that orgs no longer buy expensive new stuff and don't rent consultants for $100 an hour.
The vast majority of companies don't need "web scale", but many end up copying big-co stacks anyhow in fear of being left behind. They end up acquiring NFL-level equipment for little-league.
Sometimes these fads do actually either pay off or trigger similar good ideas elsewhere such that they do have a use in aggregate, but it's usually not good for a typical company to be the guinea-pig. Let some somebody else be the guinea-pig and benefit from THEIR lessons. You won't be hip, but you also won't be burned.
Slashdot Mirror
The browser has become a rich/fat-client, it just sucks at it because it wasn't originally designed for it, and hacked up over time to fake it.
For "productivity" applications (brochure-ware excluded), desktop UI idioms are still preferred. But we have to bend over backward to get HTML-browser/DOM to act like a (non-fucked-up) desktop, with lots of blood, sweat, tears. It's ugly compared to desktop/CRUD development in say Delphi, Powerbuilder, etc.
What's needed is a new GUI-friendly standard that works decently over HTTP/HTTPS. We should take the best lessons from Java applets, Flash, X-Windows etc., discard the worse parts, and try to get a real GUI standard for once.
Some suggestions:
* Do most of the positioning calculations on the server side to avoid complex "flow" calculations on the client (which end up varying too much per browser brand/version). Perhaps put the "flow engine" on the server and have the client merely render "dumb" vectors as coordinates (pixels or panel percents). The client sends its screen size preferences to the server rather than let the client-side do the "fit" calcs on the browser (client).
* Allow font sizing with a maximum containment box such that fonts are rendered smaller if necessary (at least on the X axis) in order to guarantee a fit in a designated containment box. Overlapping element errors are common in CSS/JS-centric frameworks, largely because testers don't test in a wide enough variety of clients/versions/OS-DPI settings.
* Don't make the client an OS or OS-like thing. This is largely Java's mistake: they bit off more than they could chew. Focus on GUI's and KISS. Most the app activity should be on the server.
* Allow flexible "skinning" to keep up with style Joneses. You have to keep up with the look styles to not get ignored, unfortunately. (I have some ideas for graphic (image) background skinning that are flexible but relatively simple that allow changing the visual styles without breaking the complexity bank.)
* Allow optional client-side scripting, but try not to over-do reliance on it. If a UI pattern(s) emerges, then build that pattern into the standard.
Actually it shouldn't matter much except at the validation stage. Much of typical CRUD programming is just marshaling around rows and fields rather than computations on those fields. If each marshaling stage has to know the type, then you violate DRY by replicating schema info to check at each stage.
So it's like PHP, Perl, and ASP-Classic: interpreted. New is old again and old is new again. I'm getting my bell-bottom jeans out...or did they already come-and-go again, I forgot.
MVC was "invented" for client/server systems, if I'm not mistaking, or at least used heavily for client/server before moving to web. Thus, its association with web-ness is weak at best.
And when they don't fit each other, it often creates a mess in performance and/or code. Relational is mostly set-based, and objects are mostly hierarchy-based: these two philosophies don't always jive well.
Sure, if you are skilled enough, you can manage the work-arounds well, but that's true of anything: If you know assembler well enough, you can potentially program circles around the high-level-language people. And I've seen some really productive COBOLers, for example because they knew the language and shop conventions like the back of their hands.
It's a genetic algorithm where YOU are the population being flushed out each cycle.
Election night: "Sorry, we've received too many orders, the earliest is Friday."
ALL the telecom oligopolies suck puss-filled maggots. Jail all the f#cking bastards! As far as AT&T, they have telespammed me approximately 50 times in the last 2 years. They only stopped when I started answering with Trump impressions. And I won't even start on their screwy billing practices. We were forced to use some of their services because the other choice sucks more. We are in a relatively big town, but our choices are strangely limited.
Fake messages from bad hombres discovered by Russians? Where have I heard that before?
Sorry, if it's a jury trial, they'll go, "Hex what? It's yellow to me."
Didn't Apple try to trademark rounded corners? Thus if you made a yellow box with rounded corners, you'd get sued by two conglomerates. Put one button on it and Amazon would also join the party.
Maybe it's mostly HD videos.
Re unreliable flesh drivers: rationally I agree with you, but part of me wants to see it road tested by actual riders for a couple of years. There are people who cannot drive for various reasons who want to be able to get around and will accept some risk to do so. These will be the "pioneers" or "guinea-pigs", depending on your perspective. They are doing us all a favor by helping the bot-car co's get the kinks out.
As far as being outright stuck when the software gets confused or crashes, I would hope the car co. will make it easy to fetch a taxi or Uber ride on their dime. Bleep happens. Even with regular cars, I've been 90 minutes or more late to work several times when there were nasty accidents (clogging routes), bad weather, flat tires, dead batteries, etc. If your career depends on arriving on time all the time, then bot-cars are not for you, but many job are not quite that tight. And retirees don't have such worries.
+5 analogy for "one language for entire stack" argument! Kudos & LOL.
While I do have many qualms about JavaScript (JS), a bigger problem is that different kinds of languages better fit different needs. JS is okay as a light-weight glue language, but should NOT be used to write lower-level API's and services that need a compiled/strong-typed (CST) language for performance and the safety of type-checking.
Low-level components/layers that higher levels such as app-specific logic rely on should generally be CST. If you think of applications as an onion with OS, compiler/interpreter and databases being the core, middle-ware libraries the middle layers, and application business logic the outer layers, then the closer to the core you are, the more "anal" the language you need for speed and reliability, thus CST. JS is best for the outer layers where too bureaucratic of a language slows progress, especially in-house apps for non-key tasks that wont kill anybody if they break. I doubt there will ever be a one-size-fits-all language.
(Although, others and I have kicked around the idea of a language that can be strong and weak typed based on configuration switches that can be applied to the entire application or a specific module, and specific parameters can be still be verified as requested. It's almost comparable to using the type "object" in C# by default if weak mode is on, but without the need to actually state "object". Another approach is "soft compilation", but that would take a long time to explain. Also, I realize there are existing interpreted strong-typed languages, but for various reasons that combo has not been successful.)
So they need duck-wire and chicken-tape to patch the duck-tape and chicken-wire. I'm a vendor for Duck-Wire++ Cloud Premium, so I'll make a killing!
Fad sniffers, that's why. I'm going into my get-off-my-lawn mode here, if you don't mind.
Tech companies and consultants profit off of change, and so encourage it, whether it's the right decision or not for a particular project. When technology stagnates (becomes stable), people figure everything out, and fixing and changing becomes routine and commoditized such that orgs no longer buy expensive new stuff and don't rent consultants for $100 an hour.
The vast majority of companies don't need "web scale", but many end up copying big-co stacks anyhow in fear of being left behind. They end up acquiring NFL-level equipment for little-league.
Sometimes these fads do actually either pay off or trigger similar good ideas elsewhere such that they do have a use in aggregate, but it's usually not good for a typical company to be the guinea-pig. Let some somebody else be the guinea-pig and benefit from THEIR lessons. You won't be hip, but you also won't be burned.
If Bill Gates is involved, it will at least be Microsoft-ish.
"Microsoft meat" sounds about as appetizing as cockroach pie.
Does it include an EULA? It might really end the user.
She admitted she made poor decisions with regard to email. What more do you want?
She admitted she made poor decisions with regard to email.
The laws are vague and the verification systems fucked up. Hillary is only partly to blame.
We saw how well that technique worked in Titanic.
Some in the chain of command have been staring into the sun.
It's a bur-rocket-cy of galactic proportions.
It's more like brain surgery: the patient keeps squirming.