|
MononcQc posted:"fixed" yeah i think we're just at a lull in the browser wars.
|
#
?
Nov 28, 2013 20:01
|
|
|
|
| # ? May 5, 2024 09:12 |
|
|
MononcQc posted:Basically, you push your code to Heroku, and a file called a buildpack that contains instructions about how to set up the runtime environment (language dependencies, how to build your app). After that, each buildpack can pretty much do whatever the hell it wants if you feel like modifying it and using your own, and have it fetch dependencies statically from a trusted host, or whatever. o i c, that makes me feel better still tho, i think the bulk of people are likely not fetching static dependencies. I feel like this whole idea of build-to-deploy is weird and i dont like it, but that may just be me being old fashioned. I feel like a tested artifact is the proper thing to be pushing around as opposed to instructions on how to recreate the tested artifact.
|
|
#
?
Nov 28, 2013 20:10
|
|
|
Suspicious Dish posted:I've recently built a web app that uses all of this new stuff (raw DOM, not jQuery/Angular), and it feels like fresh air. Do you mind elaborating on this? I'm not sure what you mean by 'raw DOM', which I assume means non-HTML webpages. This is new to me.
|
|
#
?
Nov 28, 2013 20:49
|
|
|
Pollyanna posted:Do you mind elaborating on this? I'm not sure what you mean by 'raw DOM', which I assume means non-HTML webpages. This is new to me. He means not using the jquery element wrappers - just using the proper DOM methods (which sure are nice as well lately, I'm actually considering dumping jq in my angular project)
|
|
#
?
Nov 28, 2013 21:06
|
|
|
yeah i think the big use case of jquery was to rationalize browsers. now that they've largely converged, I'm not really sure how much utility jquery has.
|
|
#
?
Nov 28, 2013 21:25
|
|
|
Mr. Wynand posted:He means not using the jquery element wrappers - just using the proper DOM methods (which sure are nice as well lately, I'm actually considering dumping jq in my angular project) Huh, I guess I must've learned incorrectly when I was studying JS/JQ. What are the right methods, then, and what alternatives to JQ are there? (And I thought Angular was dependent on JQ?)
|
|
#
?
Nov 28, 2013 22:02
|
|
|
Pollyanna posted:Huh, I guess I must've learned incorrectly when I was studying JS/JQ. What are the right methods, then, and what alternatives to JQ are there? (And I thought Angular was dependent on JQ?)
|
|
#
?
Nov 28, 2013 22:14
|
|
|
Angular does not depend on jQuery at all. Actually, you should not be using jQuery at all inside Angular: if you are, it's guaranteed you'll do things the wrong way... jQuery's big initial feature was a CSS selector engine, so you could write $(".foo .bar > li.thing"). That is now in browsers as document.querySelectorAll(".foo .bar > li.thing"). It also used to be that you had to do foo.className = foo.className + ' baz' to add a class to an element, and jQuery tightened that up to foo.addClass('baz');. Now you can do foo.classList.add('baz');. There's other things like this as well. foo.innerHTML = 'fart'; is now standardized, so you can depend on it instead of having to use foo.html('fart');. foo.text('fart'); is now foo.textContent = 'fart';. There's still a few annoyances here and there, but overall most of my itches that make me use jQuery have been fixed.
|
|
#
?
Nov 28, 2013 23:02
|
|
|
For modern browser you can use Zepto to get simple wrappers around the new native stuff, since the jQuery API is still quite a bit nicer.
|
|
#
?
Nov 28, 2013 23:53
|
|
|
Pollyanna posted:Huh, I guess I must've learned incorrectly when I was studying JS/JQ. What are the right methods, then, and what alternatives to JQ are there? (And I thought Angular was dependent on JQ?) You can do pretty much everything JQ can in a consistent way using standard DOM methods found on MDN (and W3C specs of course, but MDN is nicer to read). Angular does not depend on JQ but has its own wrapper called jQuery Lite that gives you some basic niceties. If it detects jQuery being present when it initializes however, it will use it for element wrapping instead (the jQL wrapper's api is intentionally identical to jQ proper so this is always safe). My Rhythmic Crotch posted:I'm not a big front-end guy so I'm probably butchering this, but the DOM selectors follow the pattern of document.getElementById("something") while JQuery's follow $("#something").method_name(). jQuery typically gives you functionality that is not present in the plain old javascript DOM methods, like .each(), .hide(), .show() etc, and you can add nifty effects with those methods. Actually DOM also has querySelector so you can do things jQuery style if you wish. The main difference at this point is probably just how jQ can operate on lists of elements simultaneously (and the niceties you mention). Suspicious Dish posted:Angular does not depend on jQuery at all. Actually, you should not be using jQuery at all inside Angular: if you are, it's guaranteed you'll do things the wrong way... Inside custom directives I think there are lots and lots of legit uses for jQuery. But only there...
|
|
#
?
Nov 29, 2013 00:19
|
|
|
People make insane things on a lark, and then somebody decides to actually use it in production, and 6 months later other people working on the codebase want to kill themselves. http://pgre.st/ quote:In short, PgRest - is a JSON document store. - runing inside PostgreSql - working with existing relational data - capable of loading Node.js modules - compatible with MongoLab’s REST API - = LiveScript + Plv8 + Plv8x + Express
|
|
#
?
Nov 29, 2013 11:30
|
|
|
I had to try and install a web app on my local machine for dev integration work. The web dev had written some clear instructions and remembered some of the dependencies. The steps I had to engage involved:
It still doesn't work. Seriously web devs, get your poo poo together and learn to write dpkgs, or at least learn what cryptographic signatures are.
|
|
#
?
Dec 2, 2013 13:20
|
|
|
Zombywuf posted:I had to try and install a web app on my local machine for dev integration work. The web dev had written some clear instructions and remembered some of the dependencies. The steps I had to engage involved: You should be using vagrant for working on stuff locally, even though you shouldn't have to. It won't solve all your problems, but having a clean slate + virtualenvwrapper + a system you can trash without (too much) worry might help you come to terms with it and accept that Stockholm syndrome is helping me more than it hurts.
|
|
#
?
Dec 2, 2013 14:14
|
|
|
salisbury shake posted:You should be using vagrant for working on stuff locally, even though you shouldn't have to. It won't solve all your problems, but having a clean slate + virtualenvwrapper + a system you can trash without (too much) worry might help you come to terms with it and accept that Stockholm syndrome is helping me more than it hurts. Yeah, I had to setup Vagrant as well.
|
|
#
?
Dec 2, 2013 14:21
|
|
|
My web-dev story I've been away from front end stuff for most of the last decade, mostly writing cgi-bin scripts, or things that speak http but not html. I've inherited a ruby/rails/custom cms stack for the website, running off mongo — Mongo is terrible. Instead of the schema being in the database, it's now both in ruby and in javascript. There is essentially two applications, one in javascript, served by another in ruby. — Every time I go to update a single thing, I have to reinstall all my packages. — I can't grep for poo poo, and there is no real mapping between global objects and the package that introduces them — Every package name is a pox upon mankind. Nothing is boringly named, and everything uses funny words because 'urllib' isn't rockstar enough — We have tests, but they're defined in a pseudo english which is then translated into code by a series of regular expressions — If ruby is such a great language, how come everyone writes a DSL in it and then you have to define your application inside of it. I know this isn't representative of ruby/rails/webdev but oh god what is this cruft. Startup time is slow, tests are defined through mini languages, schemas are redundantly defined elsewhere, and to top it off, we're using a 'persistentish' hash table as a backend. Similarly, I had to merge another rails app and a php app together. (Don't ask) —The php app has ~2 meg of dependencies, but with a cache buster, so a page load ended up taking ~800 requests for shared resources. —Nginx doesn't like having more than one application at a url so I had to use aufs to get it to play nicely. —Nginx will occasionally lock hard when you restart it. I imagine for all node.js's horrors it is probably still faster to boot than rails
|
|
#
?
Dec 2, 2013 14:30
|
|
|
aside, I saw a talk by two people learning to use html/css/ruby to make a website, it was cool. they prototyped it using jquery, but their mentor told them to use the vanilla.js framework instead. their dependencies went from ~7000 lines of code to about ~120. in another project I inherited, they used middleman and sass to generate static html from markdown. the generated css was ~2000+ lines long for no good reason. it seems webdev as it stands is sending megs of data to clients to allow the developer to write one line of code to do a thing, and then using thousands of lines of code to make it happen. and don't get me started about the asset pipeline.
|
|
#
?
Dec 2, 2013 14:32
|
|
|
Web development: We've written a product, ripped out the business logic, left in the assumptions, and written 10+ domain specific languages for configuration. Please reinsert your own logic atop, built on fast moving libraries, and hope that when it breaks there is a stackoverflow answer waiting. Let's rewrite half the browser inside of javascript, send it down the wire, and use json over websockets to fetch content, and use localstorage to cache it. For what is ultimately a skin around a database. First we spent our time trying to rewrite desktop applications in the webbrowser, with modal dialogues, and sites which would break if you opened up a new tab. Then we spent our time writing native applications which are just a custom web browser, and now we're trying to send a browser over the wire to be rendered using javascript, to build a website. It's not that webdev is a crock of poo poo, it's just that we don't make websites any more. tef fucked around with this message at 14:40 on Dec 2, 2013 |
|
#
?
Dec 2, 2013 14:37
|
|
|
I think my favourite thing now is waiting for webfonts to load and looking at a blank page, hoping the two paragraphs of text will render after the four megs of dependencies load.
|
|
#
?
Dec 2, 2013 14:41
|
|
|
Obligatory link to http://motherfuckingwebsite.com/
|
|
#
?
Dec 2, 2013 14:43
|
|
|
Pollyanna posted:Reminder that Java still exists and therefore embedded/compiled programmers don't get to disparage other languages. Reminder: If you spent more time writing terrible code than terrible posts, you might have actually learned something about programming. Don't let your naïvety hold you back from having an uninformed opinion though.
|
|
#
?
Dec 2, 2013 15:10
|
|
|
tef posted:We have tests, but they're defined in a pseudo english which is then translated into code by a series of regular expressions This sounds like Cucumber. Such an awesome looking idea but such a terrible experience once you use it. Rails lets developers go absolutely crazy with how they put their applications together, which was a big feature they pushed on the 2.x->3.x rewrite. I think it is bad. Things should be done 'the Rails way' and if you start breaking out crazy poo poo like mongo and angular.js and 1 page apps then you're using the wrong tool. CRUD app with some business logic behind it where speed doesn't matter too much? Rails is still great for that, and its OK to keep it only great at that. tef posted:in another project I inherited, they used middleman and sass to generate static html from markdown. the generated css was ~2000+ lines long for no good reason. middleman/sass has nothing to do with producing that css but I understand your frustration VVVVVV I guess I'm saying that a bad developer causes code like that, not the tool. It would be nice if Sass had some log output during a build/watch when deeply nested selectors are found and tell the user not to code like that. hmm yes fucked around with this message at 17:07 on Dec 2, 2013 |
|
#
?
Dec 2, 2013 16:55
|
|
|
atastypie posted:middleman/sass has nothing to do with producing that css but I understand your frustration a lot of people tend to write sass (or less or scss) in a style that produces verbose CSS that's also tightly coupled to markup structure. for example: CSS code:edit: I inherited a SCSS codebase like this once, but with the child selector > used instead of the general descendent. Making even trivial changes to the markup was the worst thing ever. Deus Rex fucked around with this message at 17:05 on Dec 2, 2013 |
|
#
?
Dec 2, 2013 17:02
|
|
|
Yeah, people are gung-ho to work in one language and compile to another. SCSS makes sense because CSS is terrible, most of the others seem pretty yak-shavey.Deus Rex posted:SASS/SCSS/LESS users tend to think that the nesting semantics they get in the language come for free. I don't doubt that happens, but if someone writes SCSS or LESS that poorly they probably wouldn't write CSS any better. jony neuemonic fucked around with this message at 17:05 on Dec 2, 2013 |
|
#
?
Dec 2, 2013 17:03
|
|
|
fidel sarcastro posted:I don't doubt that happens, but if someone writes SCSS or LESS that poorly they probably wouldn't write CSS any better. I disagree. In CSS it isn't nearly as convenient to write selectors nested that deeply, so people will choose to not do it. atastypie posted:VVVVVV I guess I'm saying that a bad developer causes code like that, not the tool. It would be nice if Sass had some log output during a build/watch when deeply nested selectors are found and tell the user not to code like that. There are sass/scss linters I think. The problem is that a linter doesn't really help that much when inheriting an existing codebase. It's also very hard to refactor SCSS like the example I gave, partly because automated regression testing of CSS is a hard problem that practically nobody seems interested in solving. Deus Rex fucked around with this message at 17:12 on Dec 2, 2013 |
|
#
?
Dec 2, 2013 17:07
|
|
|
SASS (and all of the other CSS preprocessors) makes it so easy to generate an absolutely absurd amount of CSS that I think everyone who writes more than a trivial amount of it runs into issues with that at least once. The problem is that sometimes you actually do need absurd amounts of CSS, because CSS is sort of bad.
|
|
#
?
Dec 2, 2013 17:14
|
|
|
Deus Rex posted:I disagree. In CSS it isn't nearly as convenient to write selectors nested that deeply, so people will choose to not do it. Sure, but if they're only following that best practice because it's hard to get around it (and not because, you know, best practice) then they're almost certainly breaking others.
|
|
#
?
Dec 2, 2013 17:23
|
|
|
So I'm trying to get clear on this, HTML should be written in Javascript. CSS should be written in a Ruby DSL. Javascript should be written in anything but Javascript. I should manage my package dependencies using Node.js, distribution using Bash and make build scripts in Python. Server side code should be a bunch of static files served up by a Django app and the Database should be programmed in Javascript. Is this webdev current best practice?
|
|
#
?
Dec 2, 2013 19:31
|
|
|
Zombywuf posted:So I'm trying to get clear on this, HTML should be written in Javascript. CSS should be written in a Ruby DSL. Javascript should be written in anything but Javascript. I should manage my package dependencies using Node.js, distribution using Bash and make build scripts in Python. Server side code should be a bunch of static files served up by a Django app and the Database should be programmed in Javascript. Is this webdev current best practice? Nah, web dev is a totally mixed bag. There is no standard web dev stack; it'd be like saying you need to do all desktop development with C# and XAML or whatever. Sometimes your HTML should be rendered by the server. Sometimes it should be statically precompiled. Sometimes it should be rendered in JavaScript from client-side templates. Sometimes CSS is fine, sometimes you want LESS or SASS to give you more structure; JS is really always fine, but sometimes you might want to try something like CoffeeScript, TypeScript, or ClojureScript depending on what the developers like. Your backend is whatever you want; use Postgres in like 99% of cases.
|
|
#
?
Dec 2, 2013 19:54
|
|
|
Zombywuf posted:Server side code should be a bunch of static files served up by a Django app This part is 100% correct.
|
|
#
?
Dec 2, 2013 19:59
|
|
|
tef posted:
What's wrong with the asset pipeline? It solves a lot of problems that normally aren't worth managing independently.
|
|
#
?
Dec 2, 2013 21:12
|
|
|
Zombywuf posted:So I'm trying to get clear on this, HTML should be written in Javascript. CSS should be written in a Ruby DSL. Javascript should be written in anything but Javascript. I should manage my package dependencies using Node.js, distribution using Bash and make build scripts in Python. Server side code should be a bunch of static files served up by a Django app and the Database should be programmed in Javascript. Is this webdev current best practice? literally the only zombywuf post I've ever laughed at
|
|
#
?
Dec 2, 2013 21:28
|
|
|
rotor posted:literally the only zombywuf post I've ever laughed at I was crying when I wrote it.
|
|
#
?
Dec 2, 2013 21:30
|
|
|
Zombywuf posted:I was crying when I wrote it. that's why it's funny
|
|
#
?
Dec 2, 2013 21:34
|
|
|
Zombywuf posted:So I'm trying to get clear on this, HTML should be written in Javascript. CSS should be written in a Ruby DSL. Javascript should be written in anything but Javascript. I should manage my package dependencies using Node.js, distribution using Bash and make build scripts in Python. Server side code should be a bunch of static files served up by a Django app and the Database should be programmed in Javascript. Is this webdev current best practice? hn.txt in a paragraph
|
|
#
?
Dec 2, 2013 23:18
|
|
|
salisbury shake posted:You should be using vagrant for working on stuff locally, even though you shouldn't have to. It won't solve all your problems, but having a clean slate + virtualenvwrapper + a system you can trash without (too much) worry might help you come to terms with it and accept that Stockholm syndrome is helping me more than it hurts. I'm starting to think the VM approach is not actually avoidable for web services or apps. Well it is but it would require a change of heart that spans the whole distribution ecosystem, so don't hold your breath for that. The major problems are (among others):
So we have virtualenvs and burning major versions into packages (python25 vs python27 etc). In a perfect world people would just keep their poo poo up to date and everything would always run against the latest version of everything, and every distribution would actually publish those latest versions in a prompt and reliable manner. Of course in that world we wouldn't need computers as we would all be too busy being fed bon-bons by the magic elf people.
|
|
#
?
Dec 3, 2013 00:34
|
|
|
Mr. Wynand posted:So we have virtualenvs and burning major versions into packages (python25 vs python27 etc). In a perfect world people would just keep their poo poo up to date and everything would always run against the latest version of everything, and every distribution would actually publish those latest versions in a prompt and reliable manner. Of course in that world we wouldn't need computers as we would all be too busy being fed bon-bons by the magic elf people. In your perfect world* nothing would ever be deployed because we would all be too busy updating our dependencies. Maybe if there was a real build system that did the big boy stuff and an equivalent deployment system web dev wouldn't be so bad. *In my perfect world people wouldn't write "packages" which pulled code from arbitrary urls.
|
|
#
?
Dec 3, 2013 00:45
|
|
|
writing web apps in the traditional, same (and sane imo) manner in which we used to write regular apps is 100% possible and doable and not even really that hard but boy is it ever not fashionable
|
|
#
?
Dec 3, 2013 01:14
|
|
|
FamDav posted:In your perfect world* nothing would ever be deployed because we would all be too busy updating our dependencies. What like the build system updates everything from under you and runs test that bury the project owner in alerts if they fail until they fix it?
|
|
#
?
Dec 3, 2013 01:16
|
|
|
rotor posted:writing web apps in the traditional, same (and sane imo) manner in which we used to write regular apps is 100% possible and doable and not even really that hard but boy is it ever not fashionable Well do elaborate. I am genuinely curious.
|
|
#
?
Dec 3, 2013 01:19
|
|
|
|
| # ? May 5, 2024 09:12 |
|
|
Writing CGI scripts in Perl is good enough for the majority of sites out there. Perl has a good package manager.
|
|
#
?
Dec 3, 2013 01:31
|
|