Ember.js woes part 2
-
Move to React... Quite liking it.
-
I'd rather leave MVC in the server-side part of my webapp, thanks. My View doesn't need its own MVC framework inside it as its not doing any business logic1.
1 Maybe some form validation, but that's also being done on the server side.
Sure, and that's good enough in the beginning. Everything is nicely separated and makes sense.
But then you realize you need to show modals and widgets both on backend and frontend. So you start gluing things together with jQuery and your js codebase spills over into multiple files (perhaps a few for a shared libraries and one for each page's custom code).
Then widgets come along. Each widget needs to draw its own DOM, so why not, let's have a little frontend template language, instead of
+-ing strings together using flakey javascript. Pretty soon you're copy-pasting template code around like crazy and translating it between back and frontend languages (with all the errors and inconsistencies that create).Then the boss asks you to add another widget with current alerts / top items / whatever, and you realize you need to synchronize its updates with a different widgets, both drawing from same data. So now you add functions that call other functions and trigger updates all over the page. At this point your once beautiful code is an unmaintainable mess of jQuery spaghetti, and new ajax-powered feature requests keep coming.
"Gee-whizz, wouldn't it be nice if there was some way to systematize all this mess into some structure."
There you are. THEY got you. See you in your own SPA update whine thread.
-
Move to React... Quite liking it.
Tinkering with it in a personal project. Nice but flawed, like every other thing.
-
Done for the day.
Indication of how well things are going.
-
Pretty soon you're copy-pasting template code around like crazy and translating it between back and frontend languages (with all the errors and inconsistencies that create).
For that exact reason. You lose some syntactic sugar from Handlebars / HTMLBars, but mustache is the engine they evolved from. And I can confirm that PHP and JS libraries are completely consistent.
The only thing you need to watch out for is client-side rendering, I found that I have to put mustache tags in HTML comments when inserting stuff inside tables, I buttume the DOM doesn't really like seeing tags there and just strips it all out. Not sure if Handlebars / HTMLBars solved that.
-
SPA frameworks are IMO a good idea.
It's maybe a good idea on top of a stupid one.
Let me get my cane and an onion for my belt while I gripe about how, since everything has to be a fucking web page today, we have to try to go to ridiculous lengths (SPA) to make the web browser look like a goddamn desktop application, which already had any number of libraries, many of which actually worked because they'd already had ten or twenty years of usage and bug fixes.
[phoned in rant here]
-
See? Told you so!
-
Indication of how well things are going.
Missed this post somehow: Was the commit message really in English? Because, in this case, I think the local vernacular would allow for something more colourful than "Fuck it!" and I'd be slightly disappointed if you didn't use it as intended :P
-
All product (code, commit messages, docs, tickets...) is in English. That's a firm rule of mine.
So as much fun as it would be otherwise, I'm afraid that's the actual commit message :-)
-
All product (code, commit messages, docs, tickets...) is in English. That's a firm rule of mine.
I agree with you there, tbqh.
But I don't know if I'd be able to resist the temptation.
-
Model: Responsible for getting data out of data store
Controller: responsible for manipulating dataReally don't have any understanding of the two do you? The model is so much more.
-
Really don't have any understanding of the two do you? The model is so much more.
The model can do anything!
-
Really sad that @bertrandom stopped keeping up html5zombo.com... At least it's not Lost Forever though.
GitHub - bertrandom/HTML5-Zombocom: HTML5 version of zombo.com
HTML5 version of zombo.com. Contribute to bertrandom/HTML5-Zombocom development by creating an account on GitHub.
-
You know, it was literally something ridiculous like last week when I happened to go to zombo.com on a computer with sound enabled for the first time ever...
-
Really don't have any understanding of the two do you? The model is so much more.
Explain it to me then.
If love to learn.
-
Just an off-handed comment on their language. "Deprecated" is a word that you use when something is no longer the preferred method of doing something...but it still works.
Producing approximately 9 x 1020 "warning: deprecated" messages into the user interface does not conform to any definition of "works" of which I am aware.
So what they really meant to say was "this is obsolete". Which means that "this is deprecated" is really a lie, and deprecation in JS is not really possible.
Should clarify that last: They meant to obsolete the method, not deprecate it; as their reporting methodology proves. And this method of so-called deprecation is not possible in JS--you can do compile-time messages in Java, but you can't issue user-time messages and call what you did "deprecation".
-
"Deprecated" is a word that you use when something is no longer the preferred method of doing something...but it still works, and probably not going to work in the future.
-
-
-
as it's always explained to me it's:
Model: Responsible for getting data out of data store
Controller: responsible for manipulating data
View: shows data to usereh... as it's always explained to me, by anyone, and any text that does it, it's:
Model: responsible for data transfer into/out of data store, and handling the business logic
Controller: responsible for handling UI and combining data into the form currently needed (or from the form input by user into the form used by model)
View: reposnsible for drawing UI and handling all the blinkenlights...and still, in practice, i find the boundaries are often unclear (in logic and concept even, not just implementation) and sometimes even superficial. but hey, at least you get lost in layered mess instead of just mess.
-
Well, yes, I should have included that something deprecated is probably not going to work eventually. But deprecated makes it a future thing. But still, if it no longer works now the proper word to describe the resulting breakage is "obsoleted".
-
But still, if it no longer works now the proper word to describe the resulting breakage is "obsoleted".
It could also be a JeffgressionTM.
-
Now to unleash this beast on my trusty teste- I mean users.
-
Users are the best testers. They use the app just like a user would. They have the knowledge and skill limitations of a typical user. They're accustomed to the same interface the users are...
-
Users are the best testers.
They're like monkeys on keyboards: sooner or later you can count on them to find every bug, yes. But the time-to-find of the last bug can be nearly infinite, because they're also spotty testers. They usually know just enough to use the product, but nothing more, and tend to be habit driven.
For example, we recently encountered a bug here that's been in the system since original writing in 1995. No user ever did the stupid thing that triggered it before now...twenty years later.
No, the best testers are people who are experts at testing.
(And, yes, we had testing experts in 1995, but we didn't use them...
)
-
But the time-to-find of the last bug can be nearly infinite, because they're also spotty testers.
Sure, but that's just built in expert prioritization.
