[ebiester]

I am a "full stack" developer. I know the ins and outs of both my front and back end stacks (Groovy in my case), and I have a pretty good sense of the patterns required in this case.

However, one of the more frustrating pieces of this is that I never dive deep into one paradigm. I'm continually having to work bilingually. When I was working with node.js, I didn't feel nearly as much bilingual stress (even though I've written backends in python, ruby, java, groovy, and scala!)

As such, my single person one-off and side projects will be in node.js. It's about cognitive overhead in the moment. I agree that it's a mediocre solution for larger teams and enterprise is not its sweet spot, but it's great for projects in the small.

[thezilch]

I didn't, by any means, intend to say it is not a good setup or denigrate you. I don't think anyone is wrong for using, even big teams, and I might even use the setup myself for certain projects. Only that it is rare to find really good full-stack developers, and those developers willing to work equally on both ends of the stack. And that a majority of work is thinking about the architecture and product; only hand waving 5% of the time is going to be spent context switching languages. I'd lose most of that time not having a richer language than what JS 1.5 offers, and if backend JS ever gets 1.7+ features, I am certain the browsers are not in the same stride, at which point I lose again.

[ebiester]

With the new transpilers, I don't think that's as much of a problem so long as one stays to modern (IE9+) browsers. (Let's see if this really comes true, but I know a few node.js types are anticipating this.)

In the domain I'm in (internal enterprise cough) I find that most people are expected to be full stack. On the other hand, these tend to be more simple UIs in general, so the front end knowledge isn't as vital (cue 'good' full stack developer comments...)

[romaniv]

I solved the cognitive overhead problem by developing everything via progressive enhancement. This way JavaScript has a clearly defined role and place in the process and I don't have to think in multiple languages. Of course, a lot of developers these days don't want to do progressive enhancement and dismiss it as "impossible".

[thezilch]

Not impossible as much as not worth the effort on the dollar. Reddit is fairly simple -- just a threaded-comment engine, if you will. You want the up/down rave to be progressive? So now every up/down is a form; already, drastically increasing the page's weight but I digress. You hook the body for form submits and reduce out your up/down forms; we are done, despite having a bunch of forms marking up the page.

Don't forget your form needs to be comprised of up and down submit-buttons; wouldn't want the progressive-CSS lords coming down on us.

Those fearful of JS come along... Collapse comments? Refresh the page, but don't forget to pass previous state of comments previously collapsed! Submit an up arrow? Don't forget that blob of state! Loaded deep-nested replies? Push it into state! Careful; none of this matters to 99.9% of your users, because they are understanding they'll lose the statefulness on refresh, while everything stateful happens inline and without refreshing the page and bringing in sections of the page as dictated by our stateful blob.

[romaniv]

What you're describing is not progressive enhancement. It's a mental exercise in re-implementing a website with workflows designed for heavy JavaScript usage without using JavaScripts. Which is silly.

For example, if you ever tried PE for real you would know that there is no point in implementing collapsible comments in pure HTML. That's exactly the kind of functionality you "enhance" via JavaScript. Of course, like most modern developers you've never really tried the practice, so you don't have any experience with such things.

[ebiester]

So, with progressive enhancement...

I have a main screen with a query whose processing takes over a minute to perform it on all of the data, but seconds for incremental changes after that. Each row returned has a detail screen associated with it, and the users have a requirement to be able to move to a detail screen, update a record, and return to the main screen without continually incurring the heavy query penalty each time they return to the main screen. Business also has a requirement that the database of record is normalized. (Denormalizing and precomputing is good, but you run into problems when the feed updates.) Do you...

A. keep a Nosql (say... redis) cache, precompute, and perform two commits? This adds a non-trivial amount of complexity keeping them in sync, not including watching for jobs from outside feeds that can update at any time. This isn't bad for a simple system, or a system with a lot of engineers, but it's non-trivial to get right and easy to find out a bug after the fact.

B. Keep it all in the session? This has its own problems: if using an ORM, you're going to be increasing your memory load per user substantially. Otherwise, you're having to keep a separate data structure around and marshal/unmarshal, creating an additional complexity layer, and I haven't seen a great way to do this.

C. Keep a single page application and implement a polling mechanism behind the scenes to keep the information fresh? With a system like Ember or Angular, this may not be trivial but it's not terrible either, and I'd argue it's superior to a redis cache.

I know that I can provide a better user experience by prefetching. I don't know how to do this with progressive enhancement.

[romaniv]

No one stops you from doing polling as an enhancement to a working HTML-only version. However, "single-page" has absolutely nothing to do with this, and neither do client-side MVC frameworks. I mean, there are not a prerequisite to do polling, merely your choice.

[ebiester]

Perhaps I misunderstand you. How would you implement the requirements above? How would you move to a detail screen and back in an HTML only solution that, most importantly, does not require rerunning the query each time?

And most importantly, you've now created two code paths, both of which need testing, both of which require maintenance, and one of which (in a web application) will never be used. What's the ROI?

Now, for some domains (say, e-commerce), progressive enhancement is the right way to go. I've done it. For web applications, which are the extension of client-server applications designed for a limited captive audience (employees), I don't see the ROI.