|
ModeSix posted:To be fair this is the front-end thread so he's likely never touched the backend beyond express (which honestly should be the absolute last choice for a backend if you ask me) or some other JS flavour of the week. Because anyone that says that hasn't really done backend work. Plus you have several choices across the entire stack as to where you stick the complexity. I have done apps which relied on a lot of complicated stored procedures to return data, so the Express service was SUPER simple. Pretty sure my longest route handler was maybe 10 lines. Then I've written ones where the node piece is doing the bulk of the work (in this case Hapi). Both of those look equal as far as the front-end is concerned, since they both just return JSON in a format the front-end understands.
|
#
?
Oct 5, 2017 15:41
|
|
|
|
| # ? Apr 28, 2024 07:51 |
|
|
How complicated your frontend or your backend is going to be is almost entirely contingent on the nature of your app.
|
|
#
?
Oct 5, 2017 15:57
|
|
|
ModeSix posted:To be fair this is the front-end thread so he's likely never touched the backend beyond express (which honestly should be the absolute last choice for a backend if you ask me) or some other JS flavour of the week. Because anyone that says that hasn't really done backend work. When I make that statement I am ignoring devops, which thanks to lots of really smart people isn't as complicated as it used to be. Load balancing and sharding and stuff like that is still pretty complicated. I'm talking about just the code. There are so many complex well tested frameworks/modules/etc out there it's all relatively straight forward, I mean, largely... if you need to process data from a satellite or something like that then to me we're talking about something else. You'd likely abstract that into a separate microservice or at least a module. Then you just piece it together. It's all encapsulated in a reliable environment. It's like lego at that point. Client side development on the other hand is the drat wild west.
|
|
#
?
Oct 5, 2017 16:57
|
|
|
Nolgthorn posted:When I make that statement I am ignoring devops, which thanks to lots of really smart people isn't as complicated as it used to be. Load balancing and sharding and stuff like that is still pretty complicated. Yep, just keep digging that hole bud.
|
|
#
?
Oct 5, 2017 17:11
|
|
|
Nolgthorn posted:When I make that statement I am ignoring devops, which thanks to lots of really smart people isn't as complicated as it used to be. Load balancing and sharding and stuff like that is still pretty complicated. Sure some of the technologies are mature, but that doesn't mean they're easy. Go build a .NET backend and then tell me how easy it is.  Just because the data comes out of the API looking simple does not mean there isn't a lot of actual code behind it making it look nice. Even a properly built Express server is a complicated jungle of code, because a lot of data gets reformatted, processed, chewed, spit out, reprocessed again and a lot of other things happen before it's presented to the consumer. If you're talking about a simple RESTful server, sure that's easy, but even there you also have to consider how to get the data from the datasource and formatting for consumption. On my projects I do both front-end and back-end work. I'm no professional, but there's really not anything simple about either. tldr; backend isn't simple, straightforward or easy, even with tried and tested frameworks. ModeSix fucked around with this message at 17:24 on Oct 5, 2017 |
|
#
?
Oct 5, 2017 17:20
|
|
|
If all you're doing is a simple CRUD server than the backend is easy...but than again so is the frontend in that case. If your backend is doing a lot of ... stuff ... then it can be complicated, but that has little bearing on whether the frontend is complicated or not. If your frontend is complicated that has no bearing on whether the backend is complicated or not. There are lots of mature frontend frameworks that you can build with like legos just like on the backend. The framework and library situation on the frontend only makes the frontend more complicated than the backend if you're chasing the bleeding edge. Of course, the same also holds true for the backend. TLDR: Backend and frontend can both be complicated or simple and calling out either for being easy or hard is simplistic.
|
|
#
?
Oct 5, 2017 17:28
|
|
|
Thermopyle posted:If all you're doing is a simple CRUD server than the backend is easy...but than again so is the frontend in that case. Agreed. I think that's what I was trying to say, but you put it much more succinctly.
|
|
#
?
Oct 5, 2017 17:32
|
|
|
prom candy posted:I asked about using type safe languages on the server a couple days ago and was directed towards C#, which looks interesting. Is anyone just using Typescript with Express or another Node framework to build their APIs and auth endpoints and stuff? I've used Typescript with Express, Koa, Hapi, and a web framework that we built in house and would still strongly recommended it for the backend. Unless it was a POC or something super small, I would never want to work without Typescript on a JS project. Nolgthorn posted:Server code is also in my experience not all that complex, compared to a client side app so value is reduced. Client side app complexity is highly based on the things complained about in this thread - the lack of a cohesive framework on the React side of things (CRA doesn't count), and the myriad of ways to create tons of boilerplate, designers being anal about things, etc. Whole different set of complexity for building APIs where good design and contracts are critical up front, scaling issues, infrastructure issues, etc. Things like routing in a framework like .NET MVC are dead simple, where it can get complicated with React apps.
|
|
#
?
Oct 5, 2017 17:40
|
|
|
https://twitter.com/mathowie/status/837735473745289218/photo/1
|
|
#
?
Oct 5, 2017 18:43
|
|
|
And it's still not complicated enough because I can't turn off loving toast popups without giving up the taskbar-entry-flashing functionality.
|
|
#
?
Oct 5, 2017 21:06
|
|
|
Nolgthorn posted:Client side development on the other hand is the drat wild west. Front end stuff is the "wild west" because it's full of poo poo built by idiots based off blog posts by other idiots based off 5 minutes with the previous framework of the week, not because of any inherent greater difficulty than server-side stuff.
|
|
#
?
Oct 6, 2017 00:16
|
|
|
It's the Wild West because we also have to keep up with UI/UX trends in order to be as user friendly AND unique as possible. I loving love it though.
|
|
#
?
Oct 6, 2017 06:01
|
|
|
prom candy posted:It's the Wild West because we also have to keep up with UI/UX trends in order to be as user friendly AND unique as possible. I loving love it though. It not even trends per se. If you're building frontend, it isn't completely reducible to a logical input -> output, it is part aesthetic and you can't really remove that part without making poo poo, that's when you get the "clearly built by a backender" style interfaces. Some poor shmuck has to actually use the interface, rather than a computer. Smoothness, animation, timing of responses and indicators, a million and one other tiny things; they're pretty irrelevant to how a computer would deal with things, and they're hard to get right. Not harder than anything else, just different problems (maybe sometimes perceived as all just horrible untestable messy side effects?)
|
|
#
?
Oct 6, 2017 11:11
|
|
|
prom candy posted:It's the Wild West because we also have to keep up with UI/UX trends in order to be as user friendly AND unique as possible. I loving love it though. Just keep in mind, there are plenty of other "front-end"s that need to keep up with UI/UX trends that aren't being rendered on browsers and whose tooling ecosystem isn't a complete dumpster fire! (yes, I know this thread is front end web-dev).
|
|
#
?
Oct 6, 2017 15:09
|
|
|
Having to support browsers is probably a large part of the reason that the ecosystem is so difficult though. Remember when you needed javascript libraries for rounded corners and drop shadows? We're always a couple steps back. I spent two hours yesterday tweaking code to make a modal that, when opened on mobile safari, didn't allow the user to scroll the body and didn't jump the scroll position back to the top of the page. On every other browser it's just "overflow: hidden" on the body. On Mobile Safari it's capturing the current scroll position, setting the body's position to fixed and the top to that scroll position * -1, and then on closing the modal, re-scrolling the window back down to the stored scroll position. Things like that make codebases messier, code harder to reason about, and are a big part of the reason that lots of back-end people just don't want to deal with this poo poo.
|
|
#
?
Oct 6, 2017 16:52
|
|
|
The DOM API is hot garbage - you needed jQuery just to standardize between the browsers, you need transpilation to use any current features that make dev easier while still supporting idiots using IE 10/11, and you need things like Angular and React just to deal with how incredibly inefficient it is the update the DOM. It's made worse by Mozilla being altruistic, Google chasing web/ad domination, and Apple hoping the web dies in favor of walled garden apps for consuming content. If people didn't flip their poo poo about Microsoft in the 90s we might all be using a standardized browser with deep .NET integration and sane DRM solutions. We stopped Microsoft from taking over the world, but now we have Google, Apple, and Facebook doing the same poo poo they did. It's an interesting "what if" to consider.
|
|
#
?
Oct 6, 2017 17:25
|
|
|
prom candy posted:Having to support browsers is probably a large part of the reason that the ecosystem is so difficult though. Remember when you needed javascript libraries for rounded corners and drop shadows? We're always a couple steps back. I spent two hours yesterday tweaking code to make a modal that, when opened on mobile safari, didn't allow the user to scroll the body and didn't jump the scroll position back to the top of the page. On every other browser it's just "overflow: hidden" on the body. On Mobile Safari it's capturing the current scroll position, setting the body's position to fixed and the top to that scroll position * -1, and then on closing the modal, re-scrolling the window back down to the stored scroll position. Things like that make codebases messier, code harder to reason about, and are a big part of the reason that lots of back-end people just don't want to deal with this poo poo. Mobile Safari is the Hitler of web browsers.
|
|
#
?
Oct 6, 2017 19:41
|
|
|
Only if Hitler had been more successful in his world takeover
|
|
#
?
Oct 6, 2017 20:00
|
|
|
Safari is supposed to be WebKit same as chrome so how the gently caress you get specific flickering issues on it and not on any other browser
|
|
#
?
Oct 6, 2017 21:20
|
|
|
Honest Thief posted:Safari is supposed to be WebKit same as chrome so how the gently caress you get specific flickering issues on it and not on any other browser Nah they forked Chrome to Blink a good while ago now. And Mobile Safari, while a pain in the rear end to dev for, is far more concerned with an optimised mobile experience than Mobile Chrome is on Android. It doesn't make it any nicer to work on, but it is what it is. No one is really invested in web as a first class citizen, so it isn't, even though literally every web presence is supported by at least one website, it's never all apps all the time.
|
|
#
?
Oct 6, 2017 21:29
|
|
|
Helicity posted:The DOM API is hot garbage - you needed jQuery just to standardize between the browsers, you need transpilation to use any current features that make dev easier while still supporting idiots using IE 10/11, and you need things like Angular and React just to deal with how incredibly inefficient it is the update the DOM. jQuery is an example of some of the litter on the floor of any website shop. You did need it, a really long time ago, and people are still using it. Combining it even, with React Redux and every other monolithic piece of technology under the sun. So you end up with websites using MBs of javascript that runs slow and is a nightmare to maintain. Updating the dom isn't inefficient it's super. If you update a whole bunch of things the browser is smart enough to optimise, to a fault. Where you have to build in hacks so that your ui details aren't optimised out of the rendering queue. React/Redux isn't really smooth. Every update to the store runs every single mapStateToProps in the entire application. So then you end up caching selectors, not helpful for performance. Spent a bunch of money on .Net courses and as soon as I was done never touched any of those things again. Everything in .Net land was closed source, you had to either pay for things as simple as a dropdown with timezones in it, or you had to build the component yourself which wasn't really easy. It was licensing out the butt. I like client side coding but something has to be done about every developer in the world having a completely different vantage on it.
|
|
#
?
Oct 6, 2017 21:47
|
|
|
To be pedantic, the DOM isn't slow...it's layout that is slow. Adding/removing nodes is just a few pointer swaps. However, when you modify the DOM tree in any way via JS, when JS passes control back to the browser, the layout is recalculated. Layout is also recalculated when you access certain properties like offsetWidth/offsetHeight. How React can* make things faster than some other options is by not touching DOM or triggering a layout operation more than one time when you update state. * It's actually not uncommon for React to be slower than jQuery or vanilla JS...particulary for initial rendering time. Of course, Being Fast is not the most compelling reason to use React. Thermopyle fucked around with this message at 22:04 on Oct 6, 2017 |
|
#
?
Oct 6, 2017 21:58
|
|
|
Nolgthorn posted:jQuery is an example of some of the litter on the floor of any website shop. Not quite. While I try to avoid JQuery, for most small client sites it's preferable, because the minimal JQuery implementations like cash and others still miss 'something' that's incompatible with some obscure browser. Those obscure browsers still exist, and people still use them. The proliferation of cheap smartphones mean that there are plenty of people who don't even realise they're browsing with a Samsung browser, not a stock Android. Web developers often have a blinkered view of the full compatibility picture whilst devving almost exclusively on Chrome + Mobile Safari, but the reality is much more complex. JQuery still has its place because it's one of the few libraries that has aimed for near ubiquitous compatibility in the face of this hosed up ecosystem. While you can go 'not supported' and move on, this is often an unacceptable response for a smaller client who cares about every user. Sometimes it pays to just keep close to the baseline of all you need is a server render plus some aesthetic/light interactivity JavaScript.
|
|
#
?
Oct 6, 2017 22:15
|
|
|
It would be neat if jquery was as modular as lodash where you can just pull in the specific functions you use in your code (maybe this exists, I've never looked in to it). Though, there might not be much saving depending on how much common code there is between all the things jquery does...
|
|
#
?
Oct 6, 2017 22:18
|
|
|
ynohtna posted:I know it's the awkward, ignored outsider kid on the JS playground but SystemJS sounds like an option for this situation in that all of its module importing, transpilation, bundling, hot loading, etc behaviours are available dynamically in the browser on top of the command line (via jspm). I ended up throwing a separate tsconfig file in my Turtle development folder and 'manually' kicking off that build inside of VSCode whenever I was working on the file. My index.html is fetching the built d.ts file with an XMLHttpRequest and adding it to the editor. Not a very graceful solution, but it's working for the moment.
|
|
#
?
Oct 8, 2017 06:28
|
|
) bundled off my drive as well as dynamically edited & hot-reloaded in the browser.
|
Do you guys run all your build/dev scripts and stuff inside VS Code? Should I be configuring launch.json? I still just run everything in the terminal.
|
|
#
?
Oct 8, 2017 15:55
|
|
|
prom candy posted:Do you guys run all your build/dev scripts and stuff inside VS Code? Should I be configuring launch.json? I still just run everything in the terminal. I run mine in command windows or the integrated command window in VS Code.
|
|
#
?
Oct 8, 2017 16:34
|
|
|
I don't use VS Code nowadays, but whatever editor or IDE I'm using I pretty much always run a terminal in separate windows running my build scripts, webpack server, etc.
|
|
#
?
Oct 8, 2017 16:53
|
|
|
I like to have a bunch of iTerm instances running on another screen. I never use the console in VS Code. Although, I'd love to be able to run a specific test or test file from the editor that would be nice.
|
|
#
?
Oct 8, 2017 17:33
|
|
|
prom candy posted:Do you guys run all your build/dev scripts and stuff inside VS Code? Should I be configuring launch.json? I still just run everything in the terminal. Unless I'm mistaken, you need to have a launch.json configured in order to do in-editor debugging, setting break points, etc. I've found debugging in the editor to be pretty luxurious compared to the browser, and it does a lot to bridge the 'developer ergonomics' gap that exists between web dev and normal dev. I do use an external shell to run the watch build scripts though, and use the VSCode shell to do, eg, npm installs, or git commands that are beyond the VSCode git interface.
|
|
#
?
Oct 8, 2017 18:06
|
|
|
Nolgthorn posted:Although, I'd love to be able to run a specific test or test file from the editor that would be nice. PyCharm/WebStorm.
|
|
#
?
Oct 8, 2017 19:20
|
|
|
I am building a Vue/Vuex app and have reached the stage where I need; clicking on some things trigger popovers that have all kinds of different stuff in them. For example, clicking the trash can on a row of a list of items should trigger a popover with "Are you sure blah blah blah deleted and and xyz other related stuff?" with Delete and Cancel buttons. Some other popovers would have more complicated content. How can I set something like that up, so that preferably near the App route I can render it? code:I'm thinking I would put it into the store such as... code:
|
|
#
?
Oct 9, 2017 01:38
|
|
|
Nolgthorn posted:I am building a Vue/Vuex app and have reached the stage where I need; clicking on some things trigger popovers that have all kinds of different stuff in them. While I am not familiar enough with Vue to speak to it specifically, but this is basically just having a global variable being used as function parameters, and is generally a bad thing to do.
|
|
#
?
Oct 9, 2017 01:50
|
|
|
The documentation advises that I use the store if I want to do something in a parent or a sibling. I could render the popovers in the dom directly where the button is that opens them, I suppose and I can use position fixed. But that doesn't feel right either.
|
|
#
?
Oct 9, 2017 02:01
|
|
|
Nolgthorn posted:Spent a bunch of money on .Net courses and as soon as I was done never touched any of those things again. Everything in .Net land was closed source, you had to either pay for things as simple as a dropdown with timezones in it, or you had to build the component yourself which wasn't really easy. It was licensing out the butt. I think what Helicity was getting at is imagining a world where we had (probably fewer) browsers that could run client side code written in a well-designed language like C#, not embedding WinForms into every browser. Might have gotten that if Microsoft had open sourced .Net 15 years ago to compete with Java more directly but oh well. Anyway, those .net course will pay off if you ever write a non-trivial server 
|
|
#
?
Oct 9, 2017 17:16
|
|
|
C# is super useful because it's a good language in general. I think my perception of C# in the browser was that it was essentially just another layer of abstraction on top of what everybody else was doing. It being closed source didn't help their case but it wasn't the biggest problem that I had.
|
|
#
?
Oct 9, 2017 17:59
|
|
|
Nolgthorn posted:C# is super useful because it's a good language in general. Sounds like you're talking about razor templates rather than actually executing C# in the browser VM. If so, it's just server side rendering. Companies like Telerik make a money by saving you time. There's nothing preventing you from writing your own templates or writing a SPA and having your backend output JSON.
|
|
#
?
Oct 9, 2017 19:37
|
|
|
Best practice question about Vue js. When I have a list of users, and I want to pass a bunch of props at once, is it better to pass a single prop as an object, a single prop as an id, all of the props using `v-bind`, or each prop I need individually. code:If all I pass is the `id` then inside the `user-item` component I'd select each attribute I need from the store. e: Going with the `:user="user"` option, with `props: { user: { type: Object, required: true } }` and although I'm not sure about long term it is working for me well right now. Nolgthorn fucked around with this message at 17:26 on Oct 10, 2017 |
|
#
?
Oct 10, 2017 16:17
|
|
|
Blinkz0rz posted:Sounds like you're talking about razor templates rather than actually executing C# in the browser VM.
|
|
#
?
Oct 11, 2017 11:17
|
|
|
|
| # ? Apr 28, 2024 07:51 |
|
|
Honest Thief posted:Has no bearing on the discussion, just an anecdote, I have some bad memories of working with some Telerik related product, I think it was Kendo, Kentico? But in general I never much liked working with CMS My Telerik anecdote is from a few jobs ago when our .NET guy went to a Telerik training thing and was all excited about using their stuff and was loving life for a couple weeks then wanted to do something slightly different / display data in a way not provided for by the default setup, spent the next few weeks cursing Telerik, then the next few weeks after that re-doing everything to not use their stuff any more.
|
|
#
?
Oct 11, 2017 16:47
|
|
