[javascript] Another „I just woke in the future” thread



  • A few years ago I was a developer, doing most of my programming on the server side, using mostly HTML with unobtrusive Javascript as output, and being generally happy with the results. Customers were happy, too.

    Now I'm trying to dive in again, mainly for personal projects (and probably a thing or two I would like eventually to sell), and I see that this approach is no longer hip. You have lots of JS frameworks (@cartman82, I feel your pain) to choose from, with different levels of activity and sanity, you are expected to write in CoffeeScript, ES6, TypeScript or whatnot, you use lots of transpilers and shitpilers, and tools with funny names (less, sass, grunt, gulp, yeoman) just to make something a browser would show you. Some fucking helloworld, I presume.

    I know there are a few people who do Javascript stuff on regular basis, can you point me at some intro to modern hipstery web development? Mind you, I'm still going to do server side in Python; I'm wondering how the hipstery stuff would actually help me with the front end part.

    Do I benefit from webpack, requirejs, and others, if all I need is still some jQuery and unobtrusively enriched DOM? What are the costs of running some Angular monstrosity if I want it to be still a website and not an app (ie: links work like they are supposed to, bots work)?



  • I'm not even 100% sure you need jQuery these days (unless some other framework you're using depends on it, i.e. Bootstrap). Most of the good bits of jQuery are now available (under different names) as part of the DOM in most modern browsers.

    Unless you're doing a project expressly for learning purposes, I'd just pick something sane and work with that...



  • @wft said:

    Do I benefit from webpack, requirejs, and others, if all I need is still some jQuery and unobtrusively enriched DOM?

    You definitely benefit writing LESS or SASS, instead of pure CSS. Learn those, they save you a lot of headache.

    You might benefit managing your jquery-ies and simular using bower.

    You don't benefit making an Angular / Ember / React Single Page Application, if all you need is a website.

    @wft said:

    What are the costs of running some Angular monstrosity if I want it to be still a website and not an app (ie: links work like they are supposed to, bots work)?

    Costs:

    • speed (especially if you can cache some stuff)
    • search engine rankings (bots can index you, but they still do it better with static sites)
    • future-proofing (your entire platform won't suddenly become deprecated under your feet, see angular)

    Benefits:

    • better managing complexity, if you need that
    • easier to make dynamic fancy pages, if you need that.

    Sounds like you really want to make a simple-ish site, with a few dynamic bits. Not really a real admin-panel-like application.

    With that in mind, I suggest you stick with server rendered pages and jQuery. Add some LESS bundling and bower if you really need to taste the hipster.

    If you really want to dip your toes, consider using react, but without the router parts. Unlike angular and ember, you can use react pretty much as you would a jQuery widget. Have it manage a little div or two, but still render your pages serverside.



  • @wft said:

    I know there are a few people who do Javascript stuff on regular basis, can you point me at some intro to modern hipstery web development?

    Here's a guide: don't do it.

    All the shit you've been doing all along still works.



  • I suspect there is some useful shit that allows me to offset the complexity, at least a bit.

    Like, writing modular javascript and then webpack/browserify it. That was what I thought would be good for jquery'ish stuff.



  • @cartman82 said:

    Add some LESS bundling and bower if you really need to taste the hipster.

    Why not SASS? ;-)



  • I think the main question is whether you projects would benefit from making a Single-Page App style site. The basic idea there is that most of the app logic happens in the browser in Javascript, and the server handles sending static files, and has some API calls that send JSON back and forth for database access, security, anything that has to happen on the server, etc.

    If you're building the kind of site that has a lot of business logic that makes sense to do in the browser - i.e. it doesn't depend heavily on querying third-party sites, doing database logic, using algorithms or data that you want to keep private - then you can get some cool benefits from going SPA style, like near-native responsiveness if done well, and your app thingy already has an API, so it's easier to make mobile or desktop apps to work with it.

    On the other hand, if your app has little to no logic or interaction to it or is heavily dependent on stuff that has to happen on the server, then most of the big Javascript stuff gets you lots of needless complexity for not much benefit.

    Using JQuery or native is a better option if you want very basic functionality with an interactivity level of maybe a few dancing monkeys or validating forms. There are some lightweight, single-purpose JS libraries for doing more limited things without bringing in a huge framework, like Parsley for form validation. I think the main advantage of using JQuery at all these days is compatibility with earlier browsers. If you can ignore before, say, IE 10 or so, you may be able to do without it.

    I would even go so far as to say that you can technically do anything you could want to do with vanilla JS. The biggest advantage to using a big framework like Angular is that it makes you organize your code in a semi-predictable way and in ways that make it easier to write unit tests for. If you are doing enough stuff in JS to make that sound like a good idea, then you should use one of the big frameworks. I'm most familiar with Angular, and I don't really know the others well enough to know the pros and cons.



  • @ufmace said:

    I think the main question is whether you projects would benefit from making a Single-Page App style site. The basic idea there is that most of the app logic happens in the browser in Javascript, and the server handles sending static files, and has some API calls that send JSON back and forth for database access, security, anything that has to happen on the server, etc.

    Is there a middle ground like "A few page app"? That is, there is a very limited number of views, they are quite rich, but they also are separate (a page reload happens). Think master-detail, login vs the rest.



  • I would suggest finding small libraries that do very specific things you need. Take Handlebars.js for example. Or maybe a library that does CSS tweens, if you want animation.

    Just don't use any of those mega-uber-libraries that are turning the web into bloated crap. Like the 57 Discourse uses.



  • @blakeyrat said:

    Here's a guide: don't do it.

    All the shit you've been doing all along still works.

    Horses still work.

    @wft said:

    Why not SASS? 😉

    LESS is based on node.js. Since all build systems are node based as well (grunt, gulp, webpack), you won't need anything else to get LESS working.

    SASS is based on ruby. So you need to set up that on top of node. If that wasn't icky enough, it usually comes with this bloated library written on top of it, called Compass. Most of the examples and FAQ-s you'll find presume you're making some kind of Rails site.

    It could be that I'm just more used to node/javascript, but SASS just feels kind of cumbersome and unwieldy.

    Also, the way LESS variable overloading works just makes more sense to me.



  • Rich in content, or in interactivity? Do you expect the users to be going between these views regularly, or to mostly stay on one of them?

    One of the big benefits of SPA is that you load everything you need right at the start, so you never need to do a full page refresh, which can be a big boost to your responsiveness if done well. It also makes it much easier to share pieces of logic between your pages. Of course, that could also seem to be a bloated mess if users mostly stay in a single view and they can't share much code.

    It might be worth checking out some of them actually. I've been working with Angular for a while, and I have found it pretty reasonable to get started with and work with - you can do basic things with it without writing a ton of boilerplate. There are legit worries about the future of it though - Angular 2 is supposed to have some breaking changes, and nobody is sure exactly when it will come out or how well existing sites will transition. React looks pretty interesting and seems to have the most hype right now. I haven't had a chance to look at it much, but it's probably worth at least trying out a demo of it if it's a direction that makes sense for you to go.



  • @cartman82 said:

    SASS is based on ruby.
    And there's libsass in C.


Log in to reply