>[reordered]
>>I would love to see something new come along that replaces at least the nasty JavaScript stack. I guess for now we need to settle with the welcome improvements in ES 6 and 7 which are a big step in the right direction. As I said at the start of this discussion I think we are in the midst of a huge changeover in client side technologies and I think in a year from now we're going to be looking at a very different landscape of frameworks and tools that take advantage of all of this new stuff in a much more streamlined development environment scenario.
>>
>I second Thierrys wish on some insight on your thoughts about JS fwks you tested or worked on. You already answered him, but IMO such an answer here is not the best way to spread your POV, esp when you encounter new fwks. If you had a [regurlarly updated] comment site on west wind along the lines of "Ricks very personal take on web fwks / JS stacks" such info would be easier to find if one is not following this thread.

LOL! If you read my blog regularily you'll get a feel for what I use on a regular basis :-)

I don't feel so self-important that I need to post 'lists' of this or that that I use. And I'm as guilty as the next guy for making the wrong choice and jumping ship to the next thing :-)

I'm mostly using:

AngularJs
Bootstrap (heavily modified usually)
.NET on the back end (Web API mostly and MVC for what little UI stuff is server driven)

I'm also looking at Aurelia now, but it's not anywhere near ready. It looks very nice, but I'm hesitant to move from Angular (as it moves towards 2.0) because there's such huge momentum. I think in the end we will end up with one dominant framework and if I had to make a choice I'd say it'll be Angular 2.0 even if others might be nicer in some respects. Again that wait and see where we land in about 4-5 months when all the 2.x revs of major frameworks are set to be released.

As it is the current stack has made me very productive for building a variety of Web applications. For smaller stuff I might skip Angular and just use raw JS and jQuery but I'm starting to lean on Angular even there. It just makes things easier. To my surprise I'm also finding that a lot of old school devs I've been working with are able to pick up Angular a lot faster than the traditional servers side MVC style Web development model which surprised me but I'm delighted to see.

I think a framework is really what has been the missing piece in JavaScript - the thing that ties together all the different things that a Web app needs to do (module management, databinding, loading of data, form validation, smart event management and a general structure to projects) in one place. It's the things that we used to take for granted in tools like VFP. So to me a framework feels kind of like the baseline that HTML/JavaScript never really had.

>
>>I used to actually be a big proponent of building desktop apps that use services from the Web to pull their data, rather than local data. However, recently with the advent of decent frameworks in JavaScript that allow you build abstractions and use proper code separation more easily, I think we can build effective front ends in the Web that are just as nice as native UI. In fact in a lot of ways I think it's much easier to build nice looking UIs using HTML/CSS. Heck there are now many desktop frameworks that use browser containers to essentially let you wrap a Web UI into desktop apps using the PhoneGap/Cordova model. (Atom UI, Chrome Apps are a couple of examples).
>
>Personally I hope abstraction [goes more to / includes] the other side, allowing you to build / generate JS UIs closer to the "OS-metal" like the ideas in React.Js / React Native or Nativescript.
>
>As I do not have the extensive web expirience to draw upon, I tend to go for the ideas behind the fwks, but lack the gut knowledge on how brittle the implementation is or if using this fwk ties you too closely to the use cases in operation when the fwk was conceived.

The only way to know is to get your hands dirty and play with it. That's a bit of a problem because there's a lot of choice, but pick what sounds best to you and start there. In my experience all of the frameworks I've played with (Angular, Ember and React) works for the majority of use cases you have and you can always fallback on hand coding those cases that just don't fit. Personally I've not run into serious show stoppers with any of these.

>"One of the things I'm trying to do with Mithril is encourage people to go back to the basics and realize that a lot of the assumptions and cloudiness surrounding MVC is actually wrong: the view layer isn't HTML-only, the model layer isn't supposed to be solely about ORM classes, controllers aren't supposed to be a pool where we dump things that we don't know how to fit into the rest of the framework."
>
>made me grin very wide ;-)))

Well we do need to dump code somewhere. And as always, most of the frameworks leave code management up to you. How you structure your code is up to you and that's as it should be. I'm probably stuck in my old mindset of using 'business' objects (or services in client side apps) that represent my business/app logic with small bits of front end code updating models and driving views. It's not rocket science nor are there are ton of different ways to do this. You can name it differently but in the end that's still what you end up doing.

>>It's not like a don't understand the limitations and tribulations of using JavaScript and it's funky language heuristics, or the difficulty in building Forms based UIs with HTML/CSS, but I've come to realize that this is simply not going to change anytime soon. This is the most ubiquous platform and the Web is the best way to deliver applications.
>
>Full ACK on "deliver" in embolded part above. What I aim for is to be able to sometimes use the smarts of endpoint devices, from caching some result sets drawn {Pox on Oracle for killing SQLite-based WebSQL in HTML5 draft}, using the procesing power of endpoint devices or enable partly disconnected operation. The security benefit of the browser has to be balanced with possible UX benefits from both more direct access to the device GUI layer than through DOM and usage of storage/processing ability utilizing more than that cripple left after murdering WebSQL.

If you're on the client side you already have local storage which is essentially a NoSql store (minus querying). I simply don't see having to have huge amounts of data on the client, but rather having many small chunks of data on the client that are managed in the business objects/services themselves. Why does there have to be a database when you can just have the in memory data structures holding that data for you. It's easier and more light weight at that. And again if the data is so complex that you need a query engine on the client I'd argue you're doing it wrong - you pull your data from the server when you need to do more complex filtering or number crunching and then 'cache' the data in your application's data structures.


As to Web Development and HTML etc.:

Well there a big part of Web development is to understand and be able to build (or separate out in a project) between the client side and server side pieces. There's so much that can be done on the server to opimize performance with caching and offloading and using multiple datastores etc.

But to be honest a lot of discussion of this to me seems overkill. While there are a companies that need this in my experience working with medium to some largish companies the horse power requirements of actual apps tend to be much lower than people estimate. Today's hardware is capable of running an incredible amount of processing and the vast majority of applications don't need the very high end features to deliver more than adequeate performance.

Premature optimization :-)


+++ Rick ---



>
>And we will go through the same growing pains when IoD will reach critical mass ;-)
>
>regards
>
>thomas