|
Plorkyeran posted:Most databases are not at all designed to support untrusted users connecting to them, so you need some trusted code in the middle that does authentication and validation and such. That's really all that your server-side code strictly needs to handle. So like publishing data to certain users and subscribing based on certain criteria? Meteor does this and it's easy.
|
#
?
Aug 12, 2015 02:59
|
|
|
|
| # ? May 5, 2024 02:59 |
|
|
Meteor has some issues that'd make me hesitant to actually use it (e.g. being tied to Mongo), but it does stand out as one of the only JS frameworks that's actually trying to solve interesting problems rather than just endlessly reinventing wheels.
|
|
#
?
Aug 12, 2015 16:22
|
|
|
Plorkyeran posted:Meteor has some issues that'd make me hesitant to actually use it (e.g. being tied to Mongo), but it does stand out as one of the only JS frameworks that's actually trying to solve interesting problems rather than just endlessly reinventing wheels. It looks like they support Redis now, so it might be coming around.
|
|
#
?
Aug 12, 2015 17:30
|
|
|
Why do people love Webpack so much? I use Gulp and Grunt pretty regularly.
|
|
#
?
Aug 12, 2015 19:44
|
|
|
TildeATH posted:Why do people love Webpack so much? I use Gulp and Grunt pretty regularly. Because it does lots of things those tools don't, and it does the things those tools do with (at least in my opinion) less effort. Being able to do a vendor bundle easily and the hot reload dev server is worth the switch in and of themselves.
|
|
#
?
Aug 12, 2015 20:21
|
|
|
The reason I started using Webpack was because I saw a presentation that Instagram (oh what do you know here it is: https://www.youtube.com/watch?v=VkTCL6Nqm6Y) did about using it and the part where you can require in external files like CSS (or image files too if you want, etc.) in the files that are using them and Webpack just kind of resolves all these dependencies for you. Not sure how easily Grunt or Gulp could do it, but it's a nice use case separating out all of your different file dependencies based on what actually uses it, so you can have the JS file require the CSS and HTML templates, along with any image files it requires, and in the end Webpack will bundle it all together in to one file. Can even throw in other 'loaders' in there to do other things like compile Stylus/SASS/LESS, or do type checking with Flow or TypeScript.
|
|
#
?
Aug 12, 2015 20:44
|
|
|
Munkeymon posted:It looks like they support Redis now, so it might be coming around. That's... still not a great choice. Redis is awesome at what it's designed to do, but that doesn't include being the primary datastore of record.
|
|
#
?
Aug 13, 2015 00:49
|
|
|
Something like meteor that talks to a boring-old relational store would be pretty interesting though you'd probably need something akin to row-level security to make it useful, and that is not currently a well understood problem IMO. Even then I still basically think it's almost always a good idea to abstract shunting data around into an application-specific interface whose guts you are free to replace as needed. I know it's annoying early during the project when you do a lot of repetitive data fetching and the kinds of data you fetch change often, but that is pretty much the worst of it: it's a bit of annoying and repetitive overhead. Thing is, once that phase of the project is over, it either dies or starts growing and then you will find data fetching and storing falls into a handful of wildly different usage patterns that are impossible to optimize when you've tied your data access logic to your storage engine. Meteor is cute for real time things. I'm not sure real-time apps are common enough that they require this sort of "everything-in-the-box" general application platform, but hey.
|
|
#
?
Aug 13, 2015 01:04
|
|
|
It always feels like a false economy to have write once shared code. It essentially says coupling is okay cause it makes development easier, but then that's only true in a greenfield project. Once it's overgrown that coupling is the last thing you want, reminds me of that Simple made Easy (I think?) talk by Rich Hickey. Might be easier but results in development slowing to a crawl once it reaches a level of complexity.
|
|
#
?
Aug 13, 2015 01:58
|
|
|
Maluco Marinero posted:It always feels like a false economy to have write once shared code. It essentially says coupling is okay cause it makes development easier, but then that's only true in a greenfield project. Once it's overgrown that coupling is the last thing you want, reminds me of that Simple made Easy (I think?) talk by Rich Hickey. This is generally true, but let me offer a compelling counter-point: React components.
|
|
#
?
Aug 13, 2015 04:09
|
|
|
Close, but not quite the same, mainly because you're rendering UI on both fronts, client and server performing the same job. Data access does not enjoy that same equivalency. As an aside I'm doing React components front and back, and it absolutely rocks for UI, especially because I've abstracted the state away so I can do visual development on static react components and then just plug in the state later, works really well for breaking the work up into isolated components.
|
|
#
?
Aug 13, 2015 04:18
|
|
|
Plorkyeran posted:That's... still not a great choice. Redis is awesome at what it's designed to do, but that doesn't include being the primary datastore of record. OK, so I actually went and looked around and found third party support for Postgress (which I guess isn't maintained anymore?) and MSSQL, so it's apparently possible to use a grown up database as long as the package maintainer doesn't disappear.
|
|
#
?
Aug 13, 2015 15:51
|
|
|
Yes that definitely puts me at ease and makes me want to use this for important, production-environment projects.
|
|
#
?
Aug 13, 2015 16:22
|
|
|
Mr. Wynand posted:Yes that definitely puts me at ease and makes me want to use this for important, production-environment projects. It's as ready for production as anything else in Node-land  I'm just glad they stopped trying to use mongo as a public facing data API (and web?) server. They grow up so fast 
|
|
#
?
Aug 13, 2015 17:21
|
|
|
It has been my unerring experience that projects that do not see real-world use in live environments on products that drive direct revenue do not grow up. That's why React is growing up (and fast!) and Angular is not.  I'm not too optimistic with meteor. Frameworks in general do not seem to survive the revenue phase of a tech company.
|
|
#
?
Aug 13, 2015 17:32
|
|
|
Mr. Wynand posted:It has been my unerring experience that projects that do not see real-world use in live environments on products that drive direct revenue do not grow up. That's why React is growing up (and fast!) and Angular is not. I don't disagree with your assertions about battle trading software is the only way to make it grow, but I'm not sure about the assertion that Angular isn't growing. If anything, it's growing too much without enough direction. Maybe I'm misunderstanding?
|
|
#
?
Aug 16, 2015 03:35
|
|
|
Not growing, growing up. React has been implemented in critical front end applications for Facebook from before it was open sourced. It's been developed such that it's very amenable to gradual insertion to an existing production application, which means it's getting relied upon by serious applications, not just prototypey green fields work and hobbyists.
|
|
#
?
Aug 16, 2015 03:47
|
|
|
Maluco Marinero posted:Not growing, growing up. React has been implemented in critical front end applications for Facebook from before it was open sourced. It's been developed such that it's very amenable to gradual insertion to an existing production application, which means it's getting relied upon by serious applications, not just prototypey green fields work and hobbyists. Ahhh. I gotcha'. That makes sense.
|
|
#
?
Aug 16, 2015 03:52
|
|
|
DoubleClick's been using it for a few years, but AFAIK they're the only ones (at Google). Of course, they picked it up when relaunching with a new product...
|
|
#
?
Aug 16, 2015 03:53
|
|
|
So... I really wanted to start using some type checking with our JS code and since we're heavy React users I figured the natural approach would be to use Flow. I gotta say, I'm very disappointed with the tooling for it. The only IDE integration is with Facebook's weird Atom branch (Nuclide). For sublimetext all I get is a basic linter. Also still no windows binaries (yeah yeah, very unfashionable but I work at a PC game company which means we need to develop on windows or life gets difficult quickly). TypeScript OTOH has top-notch plugins for sublimetext and Eclipse and it's own stand-alone IDE and whatever else you want. And quality binaries for all platforms, of course. I'm very jelly. I know I can use JSX with TypeScript but I would rather stick with mostly-ES6 if I can.
|
|
#
?
Aug 17, 2015 19:38
|
|
|
Mr. Wynand posted:So... I really wanted to start using some type checking with our JS code and since we're heavy React users I figured the natural approach would be to use Flow. I gotta say, I'm very disappointed with the tooling for it. The only IDE integration is with Facebook's weird Atom branch (Nuclide). For sublimetext all I get is a basic linter. Also still no windows binaries (yeah yeah, very unfashionable but I work at a PC game company which means we need to develop on windows or life gets difficult quickly). http://blog.mgechev.com/2015/07/05/using-jsx-react-with-typescript/ Mr. Wynand posted:It has been my unerring experience that projects that do not see real-world use in live environments on products that drive direct revenue do not grow up. That's why React is growing up (and fast!) and Angular is not. Angular has alot of problems but the angular vs react debate is rather silly as they are not directly comparable and are often used together and in fact compliment each other quite nicely, react deals solely with the view and lends itself very well to integration with a myriad of larger frameworks that concern themselves with states and two way binding or whatever next years buzzword terms will be. I dislike the jsx syntax due to jsp page related ptsd from my years as a java dev but luckily you can use react without having to use jsx and you don't really lose anything. Now if you want to argue paradigms then you have to look at the flux concepts vs angularjs mvw and even that is a bit of a stretch since flux is a concept rather than a framework and there are even flux implementations using angular. I dont mean to single you out its just the react vs angular arguments annoy me since its like comparing a hammer to a toolbox i mean sure it's a sweet hammer but it's just a hammer and if i want i can use that hammer in my tool box negating any conflict. Zasze fucked around with this message at 19:53 on Aug 17, 2015 |
|
#
?
Aug 17, 2015 19:39
|
|
|
Zasze posted:Typescript is a superset much like es6 itself you can pick and choose which features you want and ignore the rest, personally I just use the type checking and es6 compiling as Ive only recently switched to it and im finding i much prefer it to babel for ease of use, tooling and the simplicity of the compiled code. Interesting. So TypeScript's compiler has built-in jsx support, am I reading this correctly? Also, do you still use something like webpack to run typescript or just some typescript specific toolchain (presumably with IDE integration)? I did like the non-JS aspects of webpack, though I suppose they are not strictly speaking necessary. quote:Angular has alot of problems but the angular vs react debate is rather silly as they are not directly comparable and are often used together and in fact compliment each other quite nicely, react deals solely with the view and lends itself very well to integration with a myriad of larger frameworks that concern themselves with states and two way binding or whatever next years buzzword terms will be. I dislike the jsx syntax due to jsp page related ptsd from my years as a java dev but luckily you can use react without having to use jsx and you don't really lose anything. In less abstract terms: The underlying concept is basically just unidirectional data flow - that is the most important and useful aspect of it all. You cannot mutate your own properties from within a component, only your private state, and your state should never be exposed externally. That's what makes it unidirectional, Flux doesn't come into it at all. If you you do expose your state via component methods (which React cannot prevent you from doing), you lose out a lot IMO - you're just marginally better off compared to using jQuery components or even POJS. Two two-way data binding is fundamentally incompatible with React and I see no value at all in trying to mix Angular and React that way. (The only Angular bits React could theoretically benefit from are DI and the unit test stuff, and neither are particularly worth the trouble IMO...) The only problem with using plain React (and it's a very minor problem) is that you end up needing a top-level page-wide-state-management component that handles your entire application state internally and knows what to pass to what components as props. This can work out just fine, but is a bit awkward because React components are designed to deal with rendering concerns and you've effectively re-purposed it for state-management concerns. Flux improved on this by providing some more appropriate constructs that are explicitly about state management. That really is it. Mrs. Wynand fucked around with this message at 00:17 on Aug 18, 2015 |
|
#
?
Aug 17, 2015 22:31
|
|
|
Mr. Wynand posted:Interesting. So TypeScript's compiler has built-in jsx support, am I reading this correctly? TypeScript comes with it's own compiler out of the box (tsc), all of the Webpack/Grunt/Gulp/Whatever-there-is-now are probably just calling it behind the scenes, so as long as your tool of choice can call it from a shell (or possibly using a JS runtime??) you can use TS.
|
|
#
?
Aug 18, 2015 00:13
|
|
|
piratepilates posted:TypeScript comes with it's own compiler out of the box (tsc), all of the Webpack/Grunt/Gulp/Whatever-there-is-now are probably just calling it behind the scenes, so as long as your tool of choice can call it from a shell (or possibly using a JS runtime??) you can use TS. Most of the major Task runners have a module for TS specifically now(Gulp Example: https://www.npmjs.com/package/gulp-typescript), but you are right the base TSC will work with just about any task system that can call it from a shell.
|
|
#
?
Aug 24, 2015 17:15
|
|
|
How common is it for companies to hire third parties for penetration tests for account systems that could potentially be large? I feel like mine will be secure, but anyone can make mistakes. I can't really do it online, because then I'd be giving away my code or sharing my site.
|
|
#
?
Sep 2, 2015 17:03
|
|
|
LP0 ON FIRE posted:How common is it for companies to hire third parties for penetration tests for account systems that could potentially be large? I feel like mine will be secure, but anyone can make mistakes. I can't really do it online, because then I'd be giving away my code or sharing my site. If the cost of getting your system broken into exceeds the cost of quality pen testing by a factor of 2 or so (and this really is almost always the case for any company that has data worth stealing, especially considering the PR fallout and the possibility of full business failure as a consequence), you should be doing pen testing. "Anyone can write a system they themselves cannot break into" has been a long standing IT security aphorism, and its very much true. You need 3rd party review from someone that specializes in doing this sort of thing - in-house alone is not sufficient IMO (though internal code review should be seen as necessary, for security purposes among many other good reasons). Automated scans are much cheaper than a more comprehensive pen-test, and many people say they aren't worth it because they only catch known problems (kinda like an anti-virus), but I actually disagree here because in the wild, automated bots will be scanning your systems all the time, and if you do have any known vulnerabilities open, they will be found 100% of the time no matter how low a profile you keep. Shelling out for non-automated pen testing on top of that depends on the aforementioned cost of a break-in. But the short answer is, if you collect emails or people's real names or anything like that, yes, you should do 3rd party security auditing.
|
|
#
?
Sep 8, 2015 17:27
|
|
|
Wynand is absolutely right. Just like backups and redundancy, it looks expensive to set up, but it's more expensive if something bad happens.LP0 ON FIRE posted:I can't really do it online, because then I'd be giving away my code or sharing my site. I don't know what you mean by this. You can always NDA a vendor and get them to review your code, and that's pretty standard practice. When we do pen tests we set up a segregated production site and let them go hog wild. Third party testing is always the way to go. Automated testing is also desirable if you're able to hook it up. I know Scott Arciszewski (@voodooKobra on Twitter) was looking for some security-review things to do. You might want to hit him up for advice, he might even take a crack at your system. I believe he's busy ripping the tits off popular Wordpress plugins.
|
|
#
?
Sep 9, 2015 00:05
|
|
|
Now, going back to the original confrontational tone of the thread, I have a confession to make: I've been living a lie. Semantic CSS is, and has always been, a massive waste of time. The more I think it about it, the less sense it makes. Even semantic markup seems to have capitulated to the idea that there's no avoiding binding elements to layout structure, they are just hiding them in the "shadow dom". And for what? A handful of elements do indeed have real semantic value with well defined meanings and actual useful applications (headings, links, quotes, main blocks, etc). Microformats never actually became a thing, but they too only refer to a handful of well specified cases. Outside of that, the idea of a machine being able to do something useful out of a content-derived class name that isn't part of an exacting specification is frankly insane. A machine smart enough to make sense of "semantic class names" pretty much has to be smart enough to make sense of the content directly, no class names needed. I realize the vast majority of you stopped caring about semantic anything long time ago, but I only now realized that i waste rather too much time doing CSS stuff in sass/less mix-ins rather than bootstrap-y presentational class names because... no good loving reason at all. It's basically a holdover from the fever-dream of XHTML where webpages are generic documents of structured content defined by rigid document type definitions and all that jazz. We got rid of all that for good, sound reasons. It's perfectly ok to use DIVs as nothing more than layout surfaces, because that's really all they are and all they ever were. By all means, use the other stuff for its obvious and intended use (headings, links, quotes, main blocks etc), and maybe even microformats if the mood strikes you, but other than that, go nuts with the DIVs if it helps - "divitis" is not actually a thing. Of course page size still matters and hard-coding theme colors into class names is still dumb, but <div class="outer-container stretch"> <div class="container centered"> <div class="inner-container"> <div class="spacer"> is basically fine.
|
|
#
?
Sep 9, 2015 02:58
|
|
|
Well, yeah. You're right that many of us already came to this conclusion. I use bootstrap a lot, and every time I think about using a mixin to apply styles on a whatever, I recoil in the knowledge that this would bloat the gently caress out of the CSS file when it's compiled out. I'll take semantically incorrect HTML and shotgunned CSS over something perfectly structured, provided it works for my clients and my developers (side note: I don't have to care about SEO). Ease of development, portability and functionality should dictate the structure of your underlying HTML and CSS. Idealism takes a back seat to all other concerns, unless you can show me how it improves my life and saves me time. Also anyone who says "divitis" with a straight face in this day and age is a fuckwit. (unless they're referring to anything touched by Microsoft Word)
|
|
#
?
Sep 9, 2015 04:56
|
|
|
While we're at it, anyone who still has a pathological fear of <table> in 2015 deserves to be shot.
|
|
#
?
Sep 9, 2015 14:09
|
|
|
v1nce posted:Well, yeah. You're right that many of us already came to this conclusion. I use bootstrap a lot, and every time I think about using a mixin to apply styles on a whatever, I recoil in the knowledge that this would bloat the gently caress out of the CSS file when it's compiled out. I don't think "divitis" is just having lots of DIV tags. I see it as "Gee, this isn't working... I'll put it in another DIV and add some rules... okay, closer. I guess I'll put that in another DIV and add more rules...." and you wind up with 5 wrapper divs and 47 CSS rules when the desired result could have been obtained with the original markup and the smallest bit of understanding of the box model. Adding DIVs because it makes sense: A-Okay! Adding DIVs because it's your hammer and every layout problem is a nail: 
|
|
#
?
Sep 9, 2015 14:28
|
|
|
SupSuper posted:While we're at it, anyone who still has a pathological fear of <table> in 2015 deserves to be shot. What about three levels deep nested tables? 
|
|
#
?
Sep 9, 2015 14:46
|
|
|
kloa posted:What about three levels deep nested tables? Well how ELSE am I supposed to make my website layout in 3 columns? UGH.
|
|
#
?
Sep 9, 2015 16:02
|
|
|
v1nce posted:I'll take semantically incorrect HTML and shotgunned CSS over something perfectly structured, provided it works for my clients and my developers (side note: I don't have to care about SEO). I went through a period where I drank the semantic HTML kool-aid hard, and my code from that era is retarded to look at. In addition to avoiding "divitis" I also eschewed "classitis" so I'd have HTML that was incredibly beautiful with maybe five or six classes scattered around, but my CSS was a huge mess filled with a billion nth-child and direct descendant selectors, along with positioning gone wild because I was like, "container div? Is it semantically correct? No? Then get fuuuuuucked!!!"  Of course with the advent of SASS and BEM naming conventions, things got a billion times easier to understand. I'd rather have too many classes and a few extra containers in the HTML if it makes the SCSS readable and easy to work with.
|
|
#
?
Sep 9, 2015 16:11
|
|
|
The most significant frontend hurdle our current project faces is refactoring our css to actually use default bootstrap instead of overriding everything, because holy poo poo we did some dumb things in overriding default bootstrap. I will argue that well organized HTML and CSS is important due to the differences in browser display. Being lazy with it is just stupid unless you can make certain your end users are running a particular browser. I ran into this all the time when I was refactoring Wordpress sites because x site looks y way on z browser. 
|
|
#
?
Sep 9, 2015 16:15
|
|
|
kedo posted:I went through a period where I drank the semantic HTML kool-aid hard, and my code from that era is retarded to look at. In addition to avoiding "divitis" I also eschewed "classitis" so I'd have HTML that was incredibly beautiful with maybe five or six classes scattered around, but my CSS was a huge mess filled with a billion nth-child and direct descendant selectors, along with positioning gone wild because I was like, "container div? Is it semantically correct? No? Then get fuuuuuucked!!!" I did the same thing. That was in the days of the sexy XHTML kool-aid as well. Now I'm mostly convinced that the web platform is spending most of its time doing poo poo I don't want it to, which I wish I could turn off. CSS layout is rear end, and I want it to get hosed.
|
|
#
?
Sep 9, 2015 17:09
|
|
|
Suspicious Dish posted:CSS layout is rear end, and I want it to get hosed. Flexbox is a nice step forward. Sure it has its issues, but at least it's better than trying to cobble together a stable, responsive layout using only positioning or, god forbid, floats. Granted I chuckle to myself when I realize that 99% of what most developers use flexboxes for are the exact same things people used tables for back in the early 2000s. We've come full circle.
|
|
#
?
Sep 9, 2015 17:26
|
|
|
Mr. Wynand posted:Now, going back to the original confrontational tone of the thread, My last web server was written with sockets in C so I can't speak to the technical issues but I wanted to note my sincere appreciation for this return to form.
|
|
#
?
Sep 9, 2015 17:31
|
|
|
Mr. Wynand posted:<div class="spacer"> is basically fine. Missed this on my first read. Why not just go back to <img src="spacer.gif" height="100" /> you goddamn caveman?! Also: 
|
|
#
?
Sep 9, 2015 17:43
|
|
|
|
| # ? May 5, 2024 02:59 |
|
|
kloa posted:What about three levels deep nested tables?
|
|
#
?
Sep 9, 2015 19:03
|
|