Coffeehouse Thread

75 posts

I can't believe how much web programming has changed

Back to Forum: Coffeehouse
  • Bass

    So the web isn't the largest interconnected computer network of human knowledge and culture in existence? Please.

  • Sven Groot

    @Bass: Sure, the web is a great thing and has transformed the world. But that doesn't automatically make HTML/JS the best programming environment ever made.

    The web has two advantages over traditional applications: reach (everyone can access it if they have the URL or can find it with a search engine) and ease of deployment (no need to distribute anything, everyone always sees the latest version). In all other respects, HTML/JS were and still are far behind almost every other type of application. But those two things alone were enough for it to take off and make it have such a huge impact.

    But that doesn't change my original point that it has gotten a lot better lately, and at the pace it's been going it might start to catch up in a few years or so.

  • kettch

    @Sven Groot: Probably one of the reasons that HTML/JS have done so well is that the barrier of entry is very low. All you need is a text editor. There's no compilers or any other tools needed.

    They're still crap, but just saying.

  • Bass

    I don't think anything about writing a web application is any harder, and it's certainly I would find it a lot easier to make a nice looking and functional website then making a nice looking and functional WinForm application. Yes, I've done both professionally..

    I agree with the idea that it can be hard to write certain classes of apps (your standard LoB app is not one of them), but part of it is trying to write web applications like you write desktop apps. There is a reason why Microsoft is pushing MVC these days. It's the correct abstraction for a RESTful system.

  • Ion Todirel

    , MasterPie wrote

    *snip*

    I think it's really HTML that holds JavaScript back. Are we still performing string manipulation on document.cookies to read an individual cookie?

    That's DOM, it's the DOM and poor browser performance that holds JavaScript back

  • MasterPi

    @Ion Todirel: Right, I thought I had written "HTML DOM." Still, HTML sucks on its own merit. Why did we abandon the strictness of XML? I absolutely hate seeing the "required" attribute alone without a value.

  • JoshRoss
  • codeDebate

    I have been writing web applications since ASP 3.0, yeah for a long time and as most would assume got stuck to Web Forms and doing things that way. I was involved in many projects and pushed for Web Forms as I was not a big fan of MVC etc. I have been doing this for too long that I cant really figure out a way to accept MVC or even SPA. Can anyone recommend a transition guide from doing Web Forms to MVC and MVVM? I understand the patterns, It just looks like too much work, I don't know maybe I am getting rusty loool Smiley

  • Proton2

    @SpaceCowboy: I cut my teeth on MVVM by following this guide on one aspect of it. YMMV :

    http://codingsolutions.blogspot.ca/2010/03/windows-phone-7-tdd-kata-using-mvvm-and.html

     

  • Sven Groot

    Well, the fruits of my modest labour are now online. I'm fairly pleased with the results, considering I'm anything but a designer. The best effect is gotten on Windows 7+, because it uses Segoe UI and Segoe UI Light (it still looks okay if those aren't available though).

    Only the home page and blog have been updated (I plan to do the other pages later).

    As I said before, it's all MVC4 and uses jQuery, Foundation, and a little bit of Knockout (though most of that is in the admin pages which you can't see, obviously). I've tested it in IE9 and 10, Firefox, Chrome, Opera, Safari on iOS, and IE10 on WP8. I'm pretty pleased with how nice the site works in the mobile browsers thanks to the responsive layout (a few warts notwithstanding, particularly recaptcha is just a bit too wide).

    On IE8 and older, it's not such a nice story. Foundation defaults to "mobile-first", which means they get a one column view regardless of screen resolution. That wouldn't be an issue, except that means the top bar menu defaults to collapsed and cannot be opened due to script errors. So while the content is reachable, it's a * to navigate without the menu. But frankly, I don't really care about those old browsers anyway. Just upgrade already. Wink

  • kettch

    @Sven Groot: Very nice. One of the nice things about these new frameworks is that they make it easy to get a decent look and feel out of the box that just needs a little tweaking.

  • MasterPi

    Looks awesome! Very clean, too. I love Knockout, even though you haven't really used it on that main page. I'll hav to take a look at Foundation...I've been mostly doing responsive layouts by hand pulling in and out CSS.

     

    Just out of curiosity, have you looked at WPF lately (the current state of desktop development)? I picked it up again after a few years and I'm just amazed at just how nice and simple (albeit, after a slight learning curve) it is to create a good user experience. Module injection through Prism is just wonderful. Trying WPF now gave me that same feeling I had when I recently dabbled with the modern web frameworks/paradigms. You really get that sense of "I can focus on the user experience independently from the logic"

  • Sven Groot

    @kettch: Definitely. My input into the design is mostly the header, the column layout, and changing the font. Smiley

    @MasterPie: Knockout was used in the public part only for the image viewer (e.g. here). It made it very easy to write the viewer (and way less code than the old version), which is nice since I don't really use my blog for images anymore (everyone who wants to see my pics is on Facebook now) so I didn't want to spend too much time to support a feature that I don't plan to really use anymore. Smiley

    I also used Knockout for a bunch of stuff in the admin pages, it was very useful there.

  • Sven Groot

    I've got a question about best practices for MVC. How would you convert the Software section of my site to MVC?

    Currently, they're all separate .aspx pages. Nothing here is data-driven, it's all static content. Each product has its own directory with one or more .aspx pages in it. Some of the pages do have code behind, so I can't move this stuff into the database. For some of them, the directory also contains full SDK documentation (generated by Sandcastle).

    The only thing I can think of is to have a separate view for each product page, and then have the controller select the appropriate view. Alternatively, I could use one view which renders partial views for each page. The SDK docs will have to change url because if I want a controller to handle /Software I can't also have a directory by that name on the server.

    This sounds incredibly hackish, though. Is there a better way to handle a scenario like this?

  • kettch

    @Sven Groot: For stuff you can't move into the database, there's nothing that says you can't have static views serve the content. It is a bit hackish because MVC is normally so data driven.

    You could store the list of software in a database and build the listing page on the fly. Use a "url" column to store either the action name to the sub page or the file name. Razor will be able to piece it together and give you a functional link without having absolute URLs actually stored anywhere.

  • MasterPi

    You could leave the pages as they are, but then have a /Software/{id} view, in addition to ketch's /Software/index view. Have the details view showing a lot of info about the software and have a link pointing to that software's static page.

    Your "hackish" suggestion would work too...I actually did something similar in a project recently. Instead of showing details, you just have a div on the page and javascript somewhere that does $("div").load("", "mysoftwarelink"); MVC will set mysoftwarelink based on the {id} parameter, and the client browser will pull the relevant pages on load.

  • Sven Groot

    , MasterPie wrote

    You could leave the pages as they are, but then have a /Software/{id} view, in addition to ketch's /Software/index view. Have the details view showing a lot of info about the software and have a link pointing to that software's static page.

    But if I do that, I would have to have the "lot of info" in the database, which I don't really want. I'm fine with having an index generated from the DB, but I don't want to move the details pages there, especially because some of them have code behind, and adding another intermediate "details" page adds nothing.

    And how do you do static pages with Razor? I want them to be able to use the global layout, so I do plan to convert the static pages to .cshtml. But it seems you can't just serve static .cshtml files without a controller serving them up as views.

  • kettch

    @Sven Groot: You wouldn't be moving the content of the pages, just holding relative paths to them.

    As for the question of static cshtml files, you could always just serve up plain html. As long as you strip out the styling from them, they should pick up the styles from the layout page.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.