• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Web Design and Development |OT| Pixel perfect is dead, long live responsive design

On the scale of things the projects we do at work are very small and simple, they are just your normal run of the mill websites for 99% of the work.

Can someone explain to me node.js/react/angular etc, are they just things that I shouldn't worry too much about for this type of thing (obviously learning them in my own time to keep up to date with what's going on and it is always good to know things like this, and following on from this where do you go to keep up to date on what is the hottest flavour of the month?)

All these other things are a little overwhelming. I understand the question may be very broad but I'm looking for a starting point/springboard.

With node.js you can run javascript on your server, this would be useful if you have a bunch of forms with some business logic on them. You'd run this in the browser so the users can quickly see what they need to enter, and also on the server to validate the form input. You don't really want to write this stuff twice.

React was made for (websites like) Facebook and Instagram. If the sites you make are basically a digital flyer with a contact from it would be totally overkill. It's still very cool and rewarding to learn so yeah check it out for a hobby project.
 

Somnid

Member
On the scale of things the projects we do at work are very small and simple, they are just your normal run of the mill websites for 99% of the work.

Can someone explain to me node.js/react/angular etc, are they just things that I shouldn't worry too much about for this type of thing (obviously learning them in my own time to keep up to date with what's going on and it is always good to know things like this, and following on from this where do you go to keep up to date on what is the hottest flavour of the month?)

All these other things are a little overwhelming. I understand the question may be very broad but I'm looking for a starting point/springboard.

Node.js is javascript without a browser so you can write general applications with it. It's very popular to use a server technology because of the closeness it has with the rest of the web. The other thing it's used heavily for is build and automation tools (compiling and processing css/js/html and other related languages, running tests, etc). For the most part, it's easy to pickup if you know javascript.

React is a view layer for javascript that is supposed to make data-binding in one direction easy. With flux it's currently javascript's flavor of the month framework. It also has this language extension called JSX which let's you put XML tags in javascript, I have yet to figure out why this is a good idea over templating.

Angular is a large, monolithic framework that's an assortment of polyfills, dependency injection, web components mimicry, 2-way data-binding etc. If you use angular it makes all the choices for you, unlike React. It used to be the hotness before React and recently released version 2 which has lots of breaking changes from v1. v2 leverages typescript as the preferred means to do things.
 
I have yet to figure out why this is a good idea over templating.

"Bu-bu-but separation of concerns" *proceeds to write contrived as hell expressions couple with billions of helpers to get anything more complex than hello world in a template*

Especially with something like React, which is like you said, used for presentation, JSX makes tons of sense. There's no separation of concerns needed when it's all about presentation (and event delegation).

(Nor is JSX needed for React, and it can be used outside of React anyway)
 

Daffy Duck

Member
With node.js you can run javascript on your server, this would be useful if you have a bunch of forms with some business logic on them. You'd run this in the browser so the users can quickly see what they need to enter, and also on the server to validate the form input. You don't really want to write this stuff twice.

React was made for (websites like) Facebook and Instagram. If the sites you make are basically a digital flyer with a contact from it would be totally overkill. It's still very cool and rewarding to learn so yeah check it out for a hobby project.

Node.js is javascript without a browser so you can write general applications with it. It's very popular to use a server technology because of the closeness it has with the rest of the web. The other thing it's used heavily for is build and automation tools (compiling and processing css/js/html and other related languages, running tests, etc). For the most part, it's easy to pickup if you know javascript.

React is a view layer for javascript that is supposed to make data-binding in one direction easy. With flux it's currently javascript's flavor of the month framework. It also has this language extension called JSX which let's you put XML tags in javascript, I have yet to figure out why this is a good idea over templating.

Angular is a large, monolithic framework that's an assortment of polyfills, dependency injection, web components mimicry, 2-way data-binding etc. If you use angular it makes all the choices for you, unlike React. It used to be the hotness before React and recently released version 2 which has lots of breaking changes from v1. v2 leverages typescript as the preferred means to do things.

Cool, cheers guys.
 

Somnid

Member
"Bu-bu-but separation of concerns" *proceeds to write contrived as hell expressions couple with billions of helpers to get anything more complex than hello world in a template*

Especially with something like React, which is like you said, used for presentation, JSX makes tons of sense. There's no separation of concerns needed when it's all about presentation (and event delegation).

(Nor is JSX needed for React, and it can be used outside of React anyway)

Code:
document.importNode(template.content, true);

Seems pretty easy to me. You don't even need a helper, that's 1 line of vanilla js in all modern browsers, though certainly you can create a helper to fetch on demand but that type of thing would exist regardless of if you were using React or not. The point is it's much easier to find, edit, compile and bundle when these things are separated by type and usage. Granted jsx is in improvement over string templating and manual node building but those were anti-patterns to begin with.
 
edit: let me rephrase this in more constructive way

Code:
document.importNode(template.content, true);

Seems pretty easy to me. You don't even need a helper, that's 1 line of vanilla js in all modern browsers, though certainly you can create a helper to fetch on demand but that type of thing would exist regardless of if you were using React or not. The point is it's much easier to find, edit, compile and bundle when these things are separated by type and usage. Granted jsx is in improvement over string templating and manual node building but those were anti-patterns to begin with.

There's much more to JSX in React than just a way to insert XML like markup in a document. JSX is not a templating language. It's syntax extension for JavaScript, used for expressing virtual DOM elements. It's not HTML extension, but can be used to present DOM elements.

I am trying to parse the "easier to find, edit, compile and bundle when these things are separated by type and usage" part, but I know that you aren't actually talking about JSX there. It's super easy to find, edit compile, bundle (and test) components, when they are logically separated by type and usage: usually in one file.

Let's take the stupid "this is JSX in React Hello World hurr durr example" and create some components

Code:
// hello-world.jsx
import React from "react";
import ReactDOM from "react-dom";

class HelloWorld extends React.Component {
  render() {
    return <div>Hello world</div>
  }
}

React.render(<HelloWorld />, document.getElementById("foo"))

Lets compare that with a <template> element:

Code:
// hello-world.html
<template id="helloworld">
  <div>Hello world</div>
</template>

// hello-world.js
var newNode = document.importNode(document.querySelector("#hello-world"), true);
document.getElementById("foo").appendChild(newNode);

Nice, I guess? Now let's apply Virtual DOM approach to bot... actually lets not because other does it instantly and other just doesn't. I left out fetching the document and whatever. Neither of these are hardly real world examples anyway. You would have written the React example as an stateless component too:

Code:
  const HelloWorld = () => <div>Hello world</div>

More that I write this, more I realize that none of this actually matters. The point is that the separation of concerns bullshit doesn't apply to JSX, because it's spurs from deep misunderstanding of what JSX really is about and why it's there.

Sorry if this once again sounds somewhat rude, it's not my intention at all, I promise. I just suggest that you try out building standalone components with React for a while and see what you think about JSX then.
 

Somnid

Member
The problem is nobody uses XML syntax for anything other than XML-like markup templates and nobody really likes XML, especially not when you have a ultra popular serialized language already derived from and naturally compatible with JS. But even if you go down the other uses route, using it to template HTML still has all the same concerns. Even as an abstract tool it's not the right tool for the job.

What if you wanted to minify? What if you wanted to bundle things into a single HTML import? Do context-aware refactors? What if I got really fancy and wanted to stream my HTML? I can't cleanly separate the embedded XML out of the js without a heavy duty parser.
 
What if you wanted to minify? What if you wanted to bundle things into a single HTML import? Do context-aware refactors? What if I got really fancy and wanted to stream my HTML? I can't cleanly separate the embedded XML out of the js without a heavy duty parser.

That's the thing. JSX compiles to pure JavaScript. Any JS minified will do. Want to bundle them to one file? Just concat them to one file. Do context aware refactors? There's tons of tools that can parse JSX just fine. It's not embedded XML. It's JSX. Want to stream the JSX? Sasha Aikin got you covered with react-dom-stream, which would be a great addition to the core too. The structures might look like XML, but in the end it will be just plain JavaScript that you can use anywhere, with any tool.
 

Somnid

Member
That's the thing. JSX compiles to pure JavaScript. Any JS minified will do. Want to bundle them to one file? Just concat them to one file. Do context aware refactors? There's tons of tools that can parse JSX just fine. It's not embedded XML. It's JSX. Want to stream the JSX? Sasha Aikin got you covered with react-dom-stream, which would be a great addition to the core too. The structures might look like XML, but in the end it will be just plain JavaScript that you can use anywhere, with any tool.

JS minification isn't the same thing as HTML minification, by grouping similar patterns you increase repetition and get higher compression ratios. That and you know more about the context, like for example strings are case-insensitive and you can normalize them, JS minification cannot do that and by combining the types it will be less effective.

It is embedded XML. What it becomes in the end is not important, but rather why this representational form was chosen (otherwise why use anything but JS). The data was easier to represent in XML than JS functions because it was doing something JS isn't good at but XML is (semantically structured data). But that whole problem is why you'd split it anyway keeping good separation between static (but structured and semantic) presentational "views" and logical dynamic MVC-conceptual "views".

Also, that streaming wasn't quite what I was thinking, in fact I'm not sure why you'd want that at all. If you are building server-side, and shoving into HTML, unless it was a static page you'd just wind up touching it again with React (or more strangely some other DOM manipulation means) so you might as well just serve the JSX view and let the client handle it. I was more thinking taking the raw HTML and piping it over a fetch stream, maybe even in the near future using a DOM worker to stamp it out.

The best reason I'd see to use JSX is for smaller projects, especially prototyping. At that point such gains I describe are insignificant and the organization cost is small. But at the same time, introducing a transpiler (and thus a build and all it's dependencies) is quite a huge dependency cost that will likely lock you in to using it forever. In a larger project where you're going to have much of that already you probably do have enough templates and a large enough surface to refactor that those are things to more seriously consider.

If you really want to talk separation of concerns idealism I think the entire web stack is poorly designed. They eventually got style (css) and logic (inline js/handlers) out of HTML (well until angular missed the memo and put it back in) but HTML still has way too many functions: data (text), layout, accessibility (aria) and data semantics (tags). If I had my way you'd have a layer for data (JSON), a layer for data semantics (HTML), a layer for accessibility semantics, a layer for layout (pulled from both CSS and HTML), a layer for style (CSS) and a layer for logic (JS). That's my purist dream.
 
Okay, I'll bite once more:


JS minification isn't the same thing as HTML minification, by grouping similar patterns you increase repetition and get higher compression ratios. That and you know more about the context, like for example strings are case-insensitive and you can normalize them, JS minification cannot do that and by combining the types it will be less effective.

You are (hopefully) minifying the precompiled output that's all javascript. JavaScript minimizers are really good at minimizing javascript. You aren't combining types. Minimizers are context aware. They can group similar patterns. Compression rates are rather high.

It is embedded XML. What it becomes in the end is not important, but rather why this representational form was chosen (otherwise why use anything but JS). The data was easier to represent in XML than JS functions because it was doing something JS isn't good at but XML is (semantically structured data). But that whole problem is why you'd split it anyway keeping good separation between static (but structured and semantic) presentational "views" and logical dynamic MVC-conceptual "views".

Again, this is separation of concerns fallacy I have repeated multiple times now. Go back, rethink, come back.

Also, that streaming wasn't quite what I was thinking, in fact I'm not sure why you'd want that at all. If you are building server-side, and shoving into HTML, unless it was a static page you'd just wind up touching it again with React (or more strangely some other DOM manipulation means) so you might as well just serve the JSX view and let the client handle it. I was more thinking taking the raw HTML and piping it over a fetch stream, maybe even in the near future using a DOM worker to stamp it out.

Go back, read what the description of react-dom-stream says and come back. Why would you want it? For great benefits of user getting the first bytes instantly making the the first page view near instant. If you are creating static pages, that's it. Or you can just serve the first page and let clientside React handle the rest. For the last paragraph, you can already do that. See what ReadableStream renderToStaticMarkup does.

The best reason I'd see to use JSX is for smaller projects, especially prototyping. At that point such gains I describe are insignificant and the organization cost is small. But at the same time, introducing a transpiler (and thus a build and all it's dependencies) is quite a huge dependency cost that will likely lock you in to using it forever. In a larger project where you're going to have much of that already you probably do have enough templates and a large enough surface to refactor that those are things to more seriously consider.

If I'd stab myself everytime I hear the "smaller projects, for prototyping" fallacy I wouldn't have places to stab myself left. Best reason to use JSX is that it's a really good fucking expressive way to build reusable components. If you are doing "large projects" you most likely have a build step, because why the crap wouldn't you have? Obviously you can go all vanilla and do all the things by hand, but good luck with that. You are as locked into it as you would be on anything else, be it your homegrown templates, HTML5 templates, anything.

If you really want to talk separation of concerns idealism I think the entire web stack is poorly designed. They eventually got style (css) and logic (inline js/handlers) out of HTML (well until angular missed the memo and put it back in) but HTML still has way too many functions: data (text), layout, accessibility (aria) and data semantics (tags). If I had my way you'd have a layer for data (JSON), a layer for data semantics (HTML), a layer for accessibility semantics, a layer for layout (pulled from both CSS and HTML), a layer for style (CSS) and a layer for logic (JS). That's my purist dream.

I know you think you want that, but most likely in the end you don't. Why? Because coupling them together is a pain in the fucking ass. You'll spend hours and hours and hours of busting out code that does nothing but ensures that your 9 layers of hell can produce a single working example. I have worked on huge projects that do exactly that and I would never want to go back, but there's no reason why you couldn't do it with any modern technologies. Even with React, or Angular,, or Ember or Vanilla everything.

I know this sounds like a rant, but really, before you make such statements you should go back, do a small TO-DO list example, really think what you are doing and what you could be doing differently, maybe watch this small getting started on Redux if you are worried about separating your data in React (https://egghead.io/series/getting-started-with-redux) to get a handle of the Flux pattern, see if you can see the benefits of using JSX in general.

(Once again note that you can use JSX without React and React without JSX. The reason I am talking about both of those together above is because React is a really good way to build reusable components and JSX is a really good way to represent the markup for them, which is why it's the defacto way of building the markup for React components)
 

Copons

Member
Speaking of, how would one use JSX without React?

I'd love to use it in a ES6/webpack environment, but how, that totally escapes me.
I mean, every compiled/transformed JSX example I found return something like React.createElement(), and well, bringing in React only for JSX seems quite overkill for a vanilla ES6 app (that I'm doing for fun and to learn more about ES6, not React).
 
Speaking of, how would one use JSX without React?

I'd love to use it in a ES6/webpack environment, but how, that totally escapes me.
I mean, every compiled/transformed JSX example I found return something like React.createElement(), and well, bringing in React only for JSX seems quite overkill for a vanilla ES6 app (that I'm doing for fun and to learn more about ES6, not React).

You can use things like https://github.com/alexmingoia/jsx-transform (you might need some kind of Virtual DOM renderer though.)



This module aims to be a standard and configurable implementation of JSX decoupled from React for use with Mercury or other modules.

JSX is a JavaScript syntax for composing virtual DOM elements. See React's documentation for an explanation.

For linting files containing JSX see JSXHint.
 

Copons

Member
You should give React a try

And Redux



:D

And...

and...

and...

For now I'm gonna complete the app in vanilla ES6, then I'm gonna try rewriting it in React.

The whole point of what I'm doing is that I got too comfy with Angular and I want to start learning JS "from scratch" while doing something concrete, fun and as far as possible from what I do for a living (in this case: a boardgame).
Then, iterate over it and eventually get to the motherfucking React, that should be a perfect fit for what I'm doing.

But, before I get there, I still need to finish the game and improve the server with some proper data storage (as I don't need a full fledged database, I was thinking of Redis, which is yet another technology I've never used or even learned :D ).
 

Chris R

Member
Well, here is my personal site.

I have some HTML, CSS, Bootstrap, and jQuery in this. I would very much appreciate some feedback.

http://www.ericpsmith.dreamhosters.com/

Major Issue: Clicking the menu items doesn't seem to do anything visually in my browser window. I see the scroll bar changing sizes, so I know that content is actually changing under the photo, but other users might not see that and think that either nothing changed or that your site is broken.

Minor Issues: Font color of the menu items can be hard to read. Also, compress your image to save ~400kb with no visible difference.
 
Major Issue: Clicking the menu items doesn't seem to do anything visually in my browser window. I see the scroll bar changing sizes, so I know that content is actually changing under the photo, but other users might not see that and think that either nothing changed or that your site is broken.

Minor Issues: Font color of the menu items can be hard to read. Also, compress your image to save ~400kb with no visible difference.

Your Major issue was something I was looking over just now. I totally understand. I am working on that.

This was my first attempt at a site, so I have a lot to learn.
 

jokkir

Member
Why is React so confusing. I still don't understand how to pass values down to a child component. And even passing that same value to the child's child.
 

Sourcerer

Member
Why is React so confusing. I still don't understand how to pass values down to a child component. And even passing that same value to the child's child.

Pass it down in a prop. Someone can correct me if I'm wrong, but pretty much the only way you should pass data into a component is through a prop or when listening to a flux event.
 
Why is React so confusing. I still don't understand how to pass values down to a child component. And even passing that same value to the child's child.

Like Sourcerer said, in React the rule number one is: pass down the props (and treat them as immutable)

Say you have three components

Code:
class Parent extends React.Component {
  render() {
     return <Child />
   }
}

class Child extends React.Component {
  render() {
      return <StatelessChild />
   }
}

const StatelessChild = () => {

}

You have a variable you want to pass down to stateless child, you use props. The "props" are available as the components "this.props" or as the first argument in a stateless component

Code:
class Parent extends React.Component {
  render() {
     var hello = "World"
     return <Child hello={hello} />
   }
}

class Child extends React.Component {
  render() {
      return <StatelessChild hello={this.props.hello} />
   }
}

const StatelessChild = (props) => {
   return <div>Hello {props.hello}</div>
}

In the end your component prints "Hello World".

Obviously when you want to pass down many props typing them all gets tedious

Code:
class Parent extends React.Component {
  render() {
     var hello = "World"
     var goodbye = "Real life";
     var fooBarBiz = "foobarbiz";
     return <Child hello={hello} goodbye={goodbye} fooBarBiz={fooBarBiz}/>
   }
}

You can use the ES6 spread operator instead!

Code:
class Parent extends React.Component {
  render() {
     const parentProps = {
       hello: "World"
       goodbye: "Real life";
       fooBarBiz: "foobarbiz";
     }
     return <Child {...parentProps} />
   }
}

class Child extends React.Component {
  render() {
      return <StatelessChild {...this.props} />
   }
}

const StatelessChild = (props) => {
   console.log(props); // prints out an object containing {hello: "World" goodbye: "Real life"; fooBarBiz: "foobarbiz";}
   return <div>Hello {props.hello}</div>
}

You can change the keys if you want to, but you should never change the props and pass them down with the same key

Code:
class Child extends React.Component {
  render() {
      this.props.fooBarBiz = "Don't change me ever because it's a bad idea DON'T PLEASE"; // throws an error
      return <StatelessChild {...this.props} />
   }
}
 
Got a strange error for mobile.

ericpsmith.dreamhosters.com

So, when browsing on mobile, I can click the other HTML pages on the drop down menu (My Work and Contact) but when I go to those particular pages, the menu becomes unclickable.

Any advice?

Also, I updated the page so let me know if it's looking better.
 

jokkir

Member
How would I do this

Code:
var NotesContainer = React.createClass({
	eachNote: function(noteContent, i){
		return(
			<Note noteContent={noteContent} key={i} index={i}/>
		);
	},
	render: function(){
		return(
			<div className='notes-container mdl-grid container'>
				{this.props.noteContent.map(this.eachNote)}
			</div>
		);
	}
});

var Note = React.createClass({
	getInitialState: function(){
		return{
			noteTitle: 'Empty Title',
			noteContent: 'Empty Note'
		}
	},
	renderDisplay: function(){
		console.log(this.props.noteContent);
		return(
			<div className='note mdl-cell mdl-cell--6-col mdl-cell--4-col-tablet mdl-cell--2-col-phone mdl-card mdl-shadow--2dp'>
				<p>{this.props.noteContent}</p>
			</div>
		);
	},
	render: function(){
		return this.renderDisplay();
	}
});

var AddNoteContainer = React.createClass({
	render: function(){
		return(
			<div className='add-note-container mdl-shadow--16dp'>
				<AddNoteInput noteContent={this.props.noteContent}/>
			</div>
		);
	}
});

var AddNoteInput = React.createClass({
	getInitialState: function(){
		return{
			newNoteContent: ''
		}
	},
	addNote: function(){
		console.log('adding a note');
		//console.log(this.state.newNoteContent);
		var arrContent = this.props.noteContent;
		//console.log(arrContent);
		//arrContent.push(this.state.newNoteContent);
		this.props.noteContent.push(this.state.newNoteContent);
		console.log(arrContent);
	},
	handleOnChange: function(e){
		this.setState({
			newNoteContent: e.target.value
		});
	},
	render: function(){
		return(
			<div>
				<div className="add-note-input mdl-textfield mdl-js-textfield">
					<input ref='textstuff' 
							className="mdl-textfield__input" 
							type="text" 
							value={this.state.newNoteContent}
							onChange={this.handleOnChange}/>
					<label className="mdl-textfield__label" >Add note...</label>
			 	</div>
			 	<button onClick={this.addNote.bind(this, this.props.noteContent)} 
			 			className="mdl-button mdl-js-button mdl-button--fab mdl-js-ripple-effect mdl-button--colored">
  					<i className="material-icons">add</i>
				</button>
			</div>
		);
	}
});

var Container = React.createClass({
	getInitialState: function(){
		return{
			noteTitle:[
				'A Title',
				'Stinky clothes',
				'What do today',
				'Later at 9pm',
				'What to eat',
				'Bucket list',
				'Midnight stuff',
				'Need coffee'
			],
			noteContent:[
				'Call Bill',
				'Do the laundry',
				'Buy Car',
				'Watch show',
				'Eat banana',
				'Punch shark',
				'Go to bed',
				'Get milk'
			]
		};
	},
	handleOnChange: function(e){
		this.setState({
			noteContent: e.target.value
		});
	},
	render: function(){
		console.log(this.state.noteContent);
		return (
			<div className='mdl-layout mdl-js-layout'>
				<div className='mdl-layout__content'>
					<NotesContainer noteContent={this.state.noteContent} 
									noteTitle={this.state.noteTitle} />
					<AddNoteContainer 
									noteContent={this.state.noteContent}
									handleOnChange={this.handleOnChange}/>
				</div>
			</div>
		);
	}
});
ReactDOM.render(
	<div>
		<Container/>
	</div>,
	document.querySelector('#content')
);

I want it so that AddNoteInput would push a new item to the noteContent in the parent and then NoteList would automatically re-render with the new note. Is this possible?
 

Ikuu

Had his dog run over by Blizzard's CEO
Use Redux to handle data flow, I'd also recommend using ES6 when working with React.
 
Will definitely use ES6 after I get the basics down.



Any examples for this? Been having a really hard time understanding the parent/child thing with React :(

You might want to have a search field somewhere, when the user enters something, the parent needs to know the result (most likely to filter a list)

The child has an onChange function, the function is passed down from the parent:

Code:
const SearchField = ({ searchQuery, setSearch }) => (
  <input
    type="text"
    value={ searchQuery }
    onChange={ setSearch }
  />
);

class TodoList extends Component {

  setSearch(event) {
    this.setState({
      searchQuery: event.target.value
    });
  }

  render() {
    return (
      <div>
        <SearchField searchQuery={ this.state.searchQuery } setSearch={ this.setSearch } />
      </div>
    );
  }
}
 

jokkir

Member
You might want to have a search field somewhere, when the user enters something, the parent needs to know the result (most likely to filter a list)

The child has an onChange function, the function is passed down from the parent:

Code:
const SearchField = ({ searchQuery, setSearch }) => (
  <input
    type="text"
    value={ searchQuery }
    onChange={ setSearch }
  />
);

class TodoList extends Component {

  setSearch(event) {
    this.setState({
      searchQuery: event.target.value
    });
  }

  render() {
    return (
      <div>
        <SearchField searchQuery={ this.state.searchQuery } setSearch={ this.setSearch } />
      </div>
    );
  }
}

Thanks! That helped me a lot lol. I finally got it working and I think I'm understanding this better ;(
 

Nelo Ice

Banned
So I've completely stalled again on my learning. I don't know what to build or how to even start a project again. I've been helping out with my friend's course but aside from that I'm having issues being productive with the rest of my day. Feeling like a complete fraud again since now I feel like I can't code anything without being handed a tutorial that holds my hand the whole way.

And to top it all off I still haven't gotten a response from the company I did a coding challenge for after nearly 2 weeks of waiting. Def feels like I won't get to the onsite interview but it would be nice if I heard something by now :(.

edit: Well just found some tutorials on making clones of say reddit and slack in angular. Think I may attempt that but rewrite the code the way I learned how to style it. Is that a good idea or should I feel stupid again that I can't come up with any of the code on my own lol.

edit2: And I guess I should also be adding onto the 1st web app I learned how to build. So far I'm thinking add password reset authentication with firebase.
 

kodecraft

Member
So I've completely stalled again on my learning. I don't know what to build or how to even start a project again. I've been helping out with my friend's course but aside from that I'm having issues being productive with the rest of my day. Feeling like a complete fraud again since now I feel like I can't code anything without being handed a tutorial that holds my hand the whole way.

Are you me?
 

WanderingWind

Mecklemore Is My Favorite Wrapper
I am also in the valley. I hear it gets better. Just got to keep it moving. You're one of like, millions. Just don't quit and one day, you'll be an expert at interneting!

Is there a really good wireframing site that can be used to share ideas with colleagues? I see a lot of suggestions with the Googling, but is there a good standard one?
 
After a little bit of advice if that's alright.

Got a client requesting a bit of an interactive map as part of a project - basically map of the country, broken up in to bits, hover a bit and it'll change colour, label shows, click it to go to a page for that region.

My initial thought is right, that's gonna be SVG, not sure if canvas, probably not, and found this tutorial: http://www.creativebloq.com/netmag/create-responsive-svg-image-maps-51411831

Basically - am I going down the right direction with that, are there any useful SVG tools/libraries/JS that might be good to know about when doing this? It's a relatively small element for a one-off thing, but if there's anything for future SVG use that I can pick up from this little thing.
 
After a little bit of advice if that's alright.

Got a client requesting a bit of an interactive map as part of a project - basically map of the country, broken up in to bits, hover a bit and it'll change colour, label shows, click it to go to a page for that region.

My initial thought is right, that's gonna be SVG, not sure if canvas, probably not, and found this tutorial: http://www.creativebloq.com/netmag/create-responsive-svg-image-maps-51411831

Basically - am I going down the right direction with that, are there any useful SVG tools/libraries/JS that might be good to know about when doing this? It's a relatively small element for a one-off thing, but if there's anything for future SVG use that I can pick up from this little thing.

As your situation is quite simple, you can follow the steps on the tutorial. But if you are planning to do anything more complex, D3 is the way to go.

Hell, the datamaps plugin for it basically does what you need out of the box: http://datamaps.github.io/ (not to mention showing up labels on top of SVGs can be a pain)
 

Somnid

Member
Ugh, .tsconfig can't use globs for file matches. You already have a file list and an exclude list, just combine the two, if you don't want an "alternate build" system then don't even provide the file chooser options in the config at all. Documentation is still very poor around all typescript build plugins, all I want is a simple 1:1 compile of .ts files. Using typescript doesn't feel very production ready.
 
Ugh, .tsconfig can't use globs for file matches. You already have a file list and an exclude list, just combine the two, if you don't want an "alternate build" system then don't even provide the file chooser options in the config at all. Documentation is still very poor around all typescript build plugins, all I want is a simple 1:1 compile of .ts files. Using typescript doesn't feel very production ready.

There's this https://www.npmjs.com/package/tsconfig-glob which lets you specify glob patterns for your files: as filesGlob:
 

Zakalwe

Banned
Hey thread.

Two things:

1. I've spent the last month exploring CSS as deeply as i can, and while I still have a lot to learn (pseudo classes, condensing my code, etc...), I feel I should be moving on to something else.

I've dabbled with JQuery and JS, but only installing/modifying scripts. I've yet to write anything myself.

I have a JQuery course, and some JS tutorials to work through. Should I start with one of these, or is there anywhere else you'd recommend?

I'm a front-end developer/designer to make it clearer.

----

2. My friend asked me to build him a profile site similar to my own for his 3D work. I built this. It's currently a shell, it needs pages for each of his projects, About text, etc...

But the layout is all there, it's fully responsive (I think it looks quite pretty on mobile).

Is there anything that stands out as a problem to anyone? I'm thinking it may be a little drab, should I use a little more colour or does it work as it is?

Not sure about the blue on the About image hover either, I've tried using schemes related to the yellow in the links, but I can't find anything that looks right. Any advice here would be great.

Thanks everyone.
 
Top Bottom